HR ABAP Technical Overview | http://sapdocs.info/
•
59 recomendaciones•14,531 vistas
You can get this HR ABAP Material from http://sapdocs.info/sap/hr-abap/download-hr-abap-ppt-tutorial-material-technical-overview/ get more SAP Materials from http://sapdocs.info
![List of Topics ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (18)
Similar a HR ABAP Technical Overview | http://sapdocs.info/
Similar a HR ABAP Technical Overview | http://sapdocs.info/ (20)
Más de sapdocs. info
Más de sapdocs. info (20)
Último
Último (20)
HR ABAP Technical Overview | http://sapdocs.info/
- 1. HR ABAP Technical Overview
- 5. Functions of the Logical Database PNP
- 9. Linking a Logical Database to an Executable Program
- 10. Logical Structures and DB Tables in PA
- 11. LDB : Infotype Data Structure
- 12. LDB - Screening
- 13. LDB – Data Retrieval
- 15. Processing Infotypes in Logical Database
- 16. LDB – Processing Master Data Using Provide
- 17. LDB - Loop Nesting
- 18. LDB – Period Based Data - 1
- 19. LDB – Period Based Data - 2
- 20. LDB – Screening Criteria
- 21. LDB – Sort Order
- 22. LDB – Flow Control of Logical Database
- 23. Join and Projection
- 25. Joins in PROVIDE
- 26. Join / Subtypes
- 27. Joins and Projection / Coding
- 28. Reading Time-Dependent Table Entries
- 31. Macro Modules
- 32. Processing a Specific Infotype Record
- 33. Reading Infotype without using LDB (1)
- 34. Reading Infotype Without Using LDB (2)
- 36. Reading Planning Infotypes with Function Module
- 37. Determining The Entry Date
- 38. Dynamic Actions
- 41. Calling Reports Using Dynamic Actions
- 42. Reports / Repetitive Structures
- 43. Infotype with repetitive Structure
- 44. Repetitive Structure / Evaluation (1)
- 45. Repetitive Structure / Evaluation (2)
- 48. AVL Interface
- 49. Clusters
- 53. Importing Data
- 54. Importing / Exporting with Macros
- 55. Importing/Exporting using a Buffer
- 56. Importing Using a Buffer
- 57. Data flow in Payroll
- 58. Payroll Results
- 59. Reading the Cluster Directory
- 60. Determining Current Payroll Result (1)
- 61. Determining Current Payroll Result (2)
- 62. Clusters – Data Structure for Payroll Result
- 63. Table Types for Payroll Results (1)
- 64. Table Types for Payroll Results (2)
- 65. Table Types for Payroll Results (1)
- 66. Clusters - Display of Payroll Result(PC00_M40_CLSTR)
- 67. Clusters - Display of Cluster data – Payroll Result
- 68. Clusters - Display of Cluster data – Payroll Result
- 71. Time Data
- 72. Time Data
- 73. Time data and Validity Period
- 74. Importing Time Data (1)
- 75. Importing Time Data (2)
- 76. Importing Time Data to Internal Tables
- 77. Processing Time Data with Internal Tables
- 78. Infosets and Infoset Query
- 79. Infosets and User Groups
- 80. Assign Infosets to User Groups ( Transaction SQ03 )
- 82. Procedure for Creating and Changing Infosets (SQ02)
- 83. Initial Maintenance Screen for Reporting on Person/Applicants
- 84. Ad Hoc Query
- 86. Ad Hoc Query: Overview
- 88. Creating Queries
- 89. Infotypes
- 92. Personnel Administration Transparent Tables Key Fields Administration Fields Custom Fields
- 93. Database Table For Applicant Infotypes
- 94. Components of an Infotype
- 98. Initial Screen - Preview
- 99. Single Screen - Preview
- 100. List Screen - Preview
- 104. Creating Personnel Administration Infotypes – Step 1
- 105. Creating Personnel Administration Infotypes – Step 2
- 106. Creating Personnel Administration Infotypes – Step 3
- 107. Created Objects
- 108. Enhancing Personnel Administration Infotypes – Overview
- 109. Enhancing Personnel Administration Infotypes – Procedure
- 110. Enhancing Infotypes – Created Objects
- 113. Creating HRP info types
- 115. Creating HRP info types
- 116. Creating HRP info types
- 118. Creating HRP info types
- 119. Creating HRP info types
- 121. Creating HRP info types
- 124. Data Model
- 125. Relationship Between Basic Object Type
- 126. Table Infotype
- 129. Evaluation Path
- 133. Structure Parameters
- 135. Filling Fields in the Selection Screen
- 136. Evaluating Additional Data on Relationship
- 138. Evaluating the Infotype Index
Notas del editor
- To replace the title / subtitle with your own: Click on the title block -> select all the text by pressing Ctrl+A -> press Delete key -> type your own text
- The Pnnnn structure contains an infotype's key fields and data fields. The data fields in structure PSnnnn are grouped together to ensure that definitions contain as few redundancies as possible. If more structures and tables are defined in the ABAP Dictionary, structure PSnnnn can be used as a substructure. Structure Qnnnn contains special screen fields for the respective infotype. Structure PERNR contains the standard selections for the logical database PNP. Database tables PAnnnn (Personnel Administration) and PBnnnn (Recruitment) are used to store the data records for infotype nnnn. The PCLn database tables are used to store data clusters (for example, results from Time Management, Travel Management, and Payroll) Database tables PAnnnn and PBnnnn are transparent, which means that: Each infotype has its own database. Each infotype has an individual length, so that you are not required to keep additional space on the database. Information can be found more quickly (using an index search). Infotypes can be evaluated using any SQL tools. The Pnnnn structure contains an infotype's key fields and data fields. The data fields in structure PSnnnn are grouped together to ensure that definitions contain as few redundancies as possible. If more structures and tables are defined in the ABAP Dictionary, structure PSnnnn can be used as a substructure. Structure Qnnnn contains special screen fields for the respective infotype. Structure PERNR contains the standard selections for the logical database PNP. Database tables PAnnnn (Personnel Administration) and PBnnnn (Recruitment) are used to store the data records for infotype nnnn. The PCLn database tables are used to store data clusters (for example, results from Time Management, Travel Management, and Payroll) Database tables PAnnnn and PBnnnn are transparent, which means that: Each infotype has its own database. Each infotype has an individual length, so that you are not required to keep additional space on the database. Information can be found more quickly (using an index search). Infotypes can be evaluated using any SQL tools.
- In Reporting, structure Pnnnn is used as an interface between the program and the database. It contains the data fields of structure PSnnnn, and data fields that occur in every infotype (PSHD1). Key PSKEY contains the fields of structure PAKEY, and an additional field for infotype number nnnn. The client field is not required in the structure.
- Structure PERNR contains standard selections for HR master data reporting. They consist of the personnel number, the fields of infotypes 0000 and 0001, and a number of additional fields. When the GET event occurs, the data structures of declared infotypes are filled with all of the records that exist for a personnel number. The PERNR structure is fílled with the data from the above infotypes. You can access the data in this structure for processing.
- ZHR_READINFO
- Filled infotype structures are stored in the main memory for the GET PERNR event keyword. The infotype records are imported to internal tables Pnnnn (for example, P0006 for infotype 0006). These tables are then processed in a PROVIDE-ENDPROVIDE loop. The infotype records whose validity period overlaps the period selected in the selection screen (PN-BEGDA and PN-ENDDA) by at least one day are placed one after the other in the header of the respective infotype table Pnnnn. For example, if you choose the current year in the selection screen, PN-BEGDA contains the first day of the year and PN-ENDDA contains the last day of the year. If you do not enter any data for the period in the selection screen, PN-BEGDA contains the low date (01/01/1800) amd PN-ENDDA contains the high date (31/12/9999). Note: If you have entered period date in the selection screen, the contents of fields Pnnnn-BEGDA and Pnnnn-ENDDA are also reset in the header of the infotype table Pnnnn. For example, if the date in Pnnnn-ENDDA is afte the date in PN-ENDDA, Pnnnn-ENDDA is given the value from PN-ENDDA.
- HR data is processed in two nested loops: A GET PERNR loop for all of the personnel numbers selected. It is concluded implicitly by the next event, for example, END-OF-SELECTION. Subordinate loops per infotype, for the processing of all infotype records for the selected personnel number. With this form of processing, you should note that the data for the Personal Data (0002) and Address (0006) infotypes is listed sequentially and is not linked.
- Infotype data is period-based, in other words, it is only valid for specific periods. For this reason, each record has a start date and an end date. This example shows the jobs that an employee has performed over the course of a year. The decision on how to retrieve data is made for each individual infotype.
- Both types of data selection are based on the data selection period entered in the selection screen. The PROVIDE command retrieves data for specific periods, that is, on the basis of the data selection period. It is often the case that the most recent or oldest infotype record is all that is required from the selected period, rather than all of the infotype records. The RP_PROVIDE_FROM_LAST and RP_PROVIDE_FROM_FRST macros can be used in such situations.
- The standard sort sequence is in ascending order by personnel number. The sort function enables you to sort an evaluation in accordance with organizational criteria. For example, you can use the sort function to create a hierarchical list according to personnel subarea and administrator, or to list employees in alphabetical order. The sort function can be used for all of the fields in the Organizational Assignment infotype. You can also determine the sort sequence. Different types of sort are available for evaluations of specific periods. If data is selected by search help, personnel numbers are sorted by search help sequence. If you assign a report category, for example, ___X2001, to your report using the attributes, and if the report class allows data to be accessed via the organizational structure, then HR data is displayed in accordance with the organizational structure selected.
- You can determine the type of data selection used for your own reports in the Implementation Guide (IMG). The following access options are available for online and background processing: The selection fields of the logical database are forwarded directly to the database, with the exception of concatenated fields. An array fetch enables you to access large amounts of data on the database. This reduces the number of times that the database is physically accessed, therefore improving system performance. A combination of 1 and 2 results in the best possible improvement in performance. If you use options 1 and 3, ensure that your system requirements (database, database profiles) are suitable. If you use options 2 and 3, note that the report requires more main memory because larger internal tables are used.
- Evaluations can either be coded for specific infotypes, which means that each infotype is processed in its own PROVIDE loop, or for all infotypes, which means that a single PROVIDE loop retrieves and processes data from two or more infotypes at the same time. The infotypes to be processed are counted as a data source. All HR data changes over time. For this reason, time-dependencies must be taken into account when infotype data is linked by a JOIN. The validity of HR data is not absolute. Instead, HR data is valid for specific periods only. For this reason, a join creates one or more validity intervals in which the data for both periods is valid. If an evaluation is run for key dates, the data that is currently valid is retrieved in a data record for both infotypes. In principle, a join is a logical database operation performed on the time axis. New periods are created with the valid data using the specified validity periods of the infotypes to be linked. In other words, new infotype records are created. This enables you to see the time-based interrelationships between the infotypes in question.
- Any number of infotypes can be linked by a JOIN. Note that changing data in any one of the infotypes linked by a join causes a split in the selection period.
- If infotypes linked by a JOIN have subtypes, processing must be restricted to one subtype using a WHERE condition, in which a subtype is queried. In this example, the first partial interval only contains personal data. The record is not meaningful because the join's task of retrieving data from all of the infotypes in question has not been performed. Using variable Pnnnn_VALID, the system recognizes that one partial interval only contains incomplete data. When the report is run, this variable is created for each Pnnnn infotype included in a join. If a partial interval for infotype Pnnnn contains data, its Pnnnn_VALID variable is filled with X.
- JOIN and PROJECTION can be combined in a PROVIDE statement. The field P0001-ENAME contains the formatted name of the employee or applicant.
- To accelerate data entry and save memory, infotype data is usually coded to form a key (for example, infotype P0001, job key). When infotypes are processed, the texts or attributes of keys are read from control tables during runtime. Data is stored for specific validity periods in a series of control tables. If data from time-dependent control tables must be read for a key in an infotype field, the record that is valid for the validity period of the infotype must be determined on the basis of the table. The system usually reads the table record that is valid on the start date of the accessed infotype.
- Like subroutines and function modules, macro modules can be used to modularize programs. Macro modules are frequently used in HR. These macros are defined in program SAPDBPNP (include DBPNPMAC) with the keyword DEFINE. They can be used in any program that uses the logical database PNP. If you want to use these macros in reports that do not use the logical database PNP, you must include program DBPNPMAC with the keyword INCLUDE. You can also define your own macros. In accordance with the naming convention, the first two letters stand for the application. Some macros are also stored in the Macros in ABAP Programs table (TRMAC)
- The RP_PROVIDE_FROM_LAST macro retrieves the last valid data record in the data selection period. The parameters for RP_PROVIDE_FROM_LAST are: infotype, subtype, start date, and end date. If you do not want to specify a particular subtype, enter SPACE. You can process not only the last valid data record in the data selection period, but also the first valid data record using the RP_PROVIDE_FROM_FRST macro. The macro return code PNP-SW-FOUND has the value 1 if a suitable entry exists in the infotype table for the specified period. If no entry is found, the value is 0.
- The function module reads the HR infotype records for a person (employee or applicant) according to the specified selection criteria. Values are returned in an internal table, the structure of which corresponds to the appropriate infotype table. In the calling program, such tables can be declared with the INFOTYPES statement, for example. If the validity period of the infotype record overlaps with the specified period, the record is selected. The function module performs an authorization check. The following specifications are possible for the return code: 0: The return table contains all required records 4: The return table contains all records, however, it is incomplete due to missing authorization 8: The return table is empty because no records were found with the specified criteria 12: The return table is empty due to missing authorization
- In this example, the field P0002-NATIO (nationality) in DB table PA0002 is updated directly. The field contents is changed from ‘DE’ to ‘D’. The system field SY-DBCNT contains the number of changed records. Note that the system does not check the correctness of the new field contents when a direct DB update takes place. Authorization checks are not supported by the UPDATE statement and should be carried out on the program level.
- On some infotype entry screens, data is entered in tables. All of the fields in this table structure are named and defined in the infotype structure on which they are based. In the Dictionary, repetitive structures can be recognized by the number at the end of the field name (Pnnnn-XYZnn).
- You can define the work area for the processing of repetitive structures as a field string with a structure that corresponds exactly to set of repeat fields in the relevant infotype table. If some of the fields are not required for your evaluation, you can leave them out of a the defined structure. However, you cannot omit fields within the repetitive structure.
- A macro is used to write a record from the Date Specifications infotype with a repetitive structure to work area P0041. The DO loop divides the repetitive structure into segments, and then retrieves it on a block-by-block basis into the defined work area. FROM <field name> is used to flag the starting point of the increment fields. NEXT <field name> specifies the increment to the next group of repeat fields. Alternative syntax: WHILE... <condition> VARY SPECIFICATION FROM P0041-DAR01 NEXT P0041-DAR02. ENDWHILE. If unpacked data is contained in work area fields defined as packed, the evaluation is canceled. This can happen if the number of loop passes exceeds the number of repeat lines, or if the distance is not defined correctly.
- The data types required for the ABAP List Viewer are defined in the type pool SLIS . For this reason, this type pool must be included in the calling report with the statement TYPE-POOLS. The field catalog to be given to the function module REUSE_ALV_LIST_DISPLAY in the form of an internal table must have the type slis_t_fieldcat_alv. You transfer the layout information for the creation of the list to the function module by using a structure with type slis_layout_alv . For the data to be displayed, you need an internal table with any type of structure. This table can contain more fields than are relevant for the list display. Only the fields that are specified in the field structure and, if applicable, in the layout structure are used for the list display. Other fields in the internal table are ignored.
- The field catalog belonging to the output table is created in the program from which it is called. The creation of the field catalog and the explicit transfer can only be omitted if the structure of the internal table to be printed corresponds to a structure stored in the Dictionary, if all fields in this structure are printed on the list, and if the structure name is transferred to the function module using the parameter I_STRUCTURE_NAME. fieldname : Name of field from internal output table that is desctibed by the field catalog entry (mandatory parameter). ref_tabname : Structure or table name of referenced field from Dictionary. This parameter is only filled if the internal output table field described by the current entry in the field catalog refers to the Dictionary (no program field). ref_fieldname : Name of referenced field in Dictionary. This parameter is only filled if the internal output table field described by the current entry in the field catalog refers to the Dictionary (LIKE) and the field name in the internal output table differs from the name of the field in the Dictionary. If this field names are identical, it is sufficient to specify the Dictionary structure or table in the parameter ref_tabname. key : Marks columns as a key column. Range of values: SPACE or 'X' displaying the key fields in color. For information on additional parameters in the field catalog, see the documentation for the function module REUSE_ALV_LIST_DISPLA.
- The function module REUSE_ALV_LIST_DISPLAY is called at the END-OF-SELECTION event. Before this, you must create the field catalog and, if necessary, enter layout information. Structure slis_layout_alv contains parameters for the display options, exceptions, cumulation, interaction, detail screen, color, and so on. For descriptions of the parameters, see the documentation on the function module. The parameter colwidth_optimize , which is used in the example, has the value area SPACE or 'X'. 'X' = optimizes the column width so that the contents are displayed completely.
- The PAnnnn database tables contain all HR data sorted by infotype. They constitute the database for infotype entry screens and are evaluated by the HR logical database. The PCL1, PCL2, and PCL3 database tables constitute either the database for subsequent programs, such as payroll runs or evaluations, or the database for subareas within Human Resources, such as Travel Expenses and Recruitment. The PCLn database tables are a type of import/export database table.
- The IMPORT command reads data objects with the specified key values from the import/export database table. If a record is read successfully, the return code is 0. If a record is not read successfully, the return code is 4.
- To ensure consistency when data is exported and imported, the IMPORT/EXPORT commands are defined as macros. It is possible to import only a portion of the data objects in a cluster. The naming conventions for the macros are RP-IMP-Cn-xy and RP-EXP-Cn-xy, where n is the file name and xy is the cluster name. The macros for the import of payroll results are defined in include programs for the payroll driver with the name H ic PAYMACRO ( ic = ISO code, for example, H US PAYMACRO for the USA) using the DEFINE keyword. These include programs are generated and must not be changed manually. The macro for importing infotype texts to cluster TX is contained in the table Macros in ABAP Programs. The macros use routines that carry out two tasks: Data buffering Cluster authorization check
- To minimize the number of times that the database is accessed, import and export data is buffered in the main memory. If a test run is performed, the database is not updated. However, the payroll results of the previous period form the basis of the calculation used to determine the results of the subsequent period. For this reason, a difference arises between the results of a live payroll run and the results of a test run if test runs are performed for several periods. Using the buffer enables you to access the required results from the previous period
- If data is imported using macros, the data records are not read directly from table PCLn. Instead, the buffer directory is checked to determine whether the main memory already contains a record with the same key. If this is not the case, the record is read from PCLn to the buffer, and retrieved from the buffer by the report. If data is read using a buffer, the system checks the cluster authorization. The standard import programs follow the RPCLSTxy naming convention, where xy = cluster name.
- The payroll driver, RPCALCn0, uses HR data (stored in the database tables PAnnnn) and the last payroll result (stored in the database table PCL2) to run the payroll for the specified period The program (payroll driver) imports the processing logic in the form of a schema. The schema contains functions that call the subroutines contained in the payroll driver. In many cases, the function is enhanced by rules for specific control of the subroutines. The payroll result generated by the payroll driver is stored in cluster xy of the database table PCL2. Report RPCLSTxy lists the complete payroll result, report RPCEDTn0, for example, lists the formatted result as a payroll form (n = HR country indicator from table T500L).
- Payroll results are displayed using standard RPCLSTxy reports. Payroll results are stored as structures and internal tables on the database. Each payroll result has a status indicator: A = Current result P = Previous result O = All other results
- Table RGDIR contains the directory (cluster directory) for all of an employee's payroll results and is contained in cluster CU. A directory entry with the payroll area, for-period, in-period, status indicator, and the five-digit sequence number is required, together with the personnel number, to construct the key for each payroll result for an employee. The function module CU_READ_RGDIR reads table RGDIR from cluster CU. The personnel number whose payroll directory is to be read is transferred to the function module. If the MOLGA parameter is active, the function module returns the HR country indicator.
- The function module CD_READ_LAST determines the current payroll result for a for-period to be evaluated. To determine the correct start date and end date of the for-period, you specify the period by entering the payroll period in the selection screen. If you specify report class XXM00004 in the attributes of your report, the payroll period is entered and the start date (PN-BEGDA) and the end date (PN-ENDDA) are determined using the Payroll Periods table (T549Q). You enter the start and end date of the for-period for the evaluation as well as table RGDIR. The function module then gives you the sequential number (OUT_SEQNR) for the current (A) result of the for-period. You can also use the following function modules: CD_READ_PREVIOUS (reads the record that precedes the payroll record) CD_READ_PREVIOUS_ORIGINAL (reads the last original result that precedes the original payroll result)
- With the function module PYXX_READ_PAYROLL_RESULT, you can read a complete payroll result from the database table PCL2 or from the buffer. The payroll result is then transferred to parameter PAYROLL_RESULT. This mmust be declared in the calling report as a complex structure that corresponds to structure PAY ic _RESULT ( ic = ISO code). With the READ ONLY INTERNATIONAL parameter, you can specify that only the international part is imported. The READ_ONLY_BUFFER means that the database is not accessed. If the parameter CHECK_READ_AUTHORITY is active and set to blank, the cluster authorization check is deactivated. Anonymous evaluations can then be carried out by users without cluster authorizations
- The data structures for the international payroll results (RX) are described in the Dictionary in structure PAY99_RESULT. The structure contains the components EVP (directory information), INTER (international), and NAT (country-specific part). The components INTER and NAT also contain the tables (for example, RT, CRT, and so on) and field strings (for example, VERSC) for the payroll results as substructures. In cluster RX, NAT consists of a dummy field. The structures PAY ic _RESULT ( ic = ISO code, for example, PAY US _RESULT for the USA) exist for the country-specific results. Here, the component NAT contains the substructures for the country-specific results. If you want to evaluate payroll results, you need a data structure with the type PAY ic _RESULT. For each table in the payroll results to be processed, you need a header with the type HRPAY ic _ table name (for example, HRPAY99_RT for the results table RT).
- As of Release 4.5A, the payroll results (field strings and tables) have a table in the Dictionary. The line type for this table is a deep structure (deep table). A structure is a sequence of any elementary (type C, N, D, T, X, I, F, or P) or aggregated data types. Tables consist of a sequence of lines of the same data type which can be described by any line type. The line type is any data type from the Dictionary, in other words, a data element, a structure, a table type and so on. In ABAP programs you can link directly to the table type using the TYPE addition. A table type is a construction rule for internal tables that is stored in the Dictionary. It describes the structure and the functional characteristics of internal tables in ABAP. When a table type is created, the line type, access type, and key are defined.
- In this example, a table of payroll results is created with the name RESULT_TAB and the table type HRPAY99_TAB_OF_RESULTS . The work area has the line type PAY99_RESULT . The header line of the results table RT is created as a data object RT_HEADER with the line type H99PAY99_RT . Table RGDIR, for the directory of all payroll results for an employee, is defined as an internal table with a header. The function module PYXX_GET_EVALUATION_PERIODS fills the table result_tab with the payroll results for the selected period. If a retroactive run was carried out in the period, the current (A) and past (P) results are retrieved for processing.
- The payroll results are processed in nested loops: in the first loop, all lines in the internal table RESULT_TAB are placed in the work area RESULT_HEADER along with the accompanying payroll results. The tables with the payroll results can then be processed in the work area in subsequent loops.
- A characteristic of the PROVIDE statement is that the validity period of infotype records for list display is restricted to the data selection period specified on the selection screen. Time data processing has a number of special characteristics because of the time constaints assigned to infotypes. Time data views are of little use because time infotype data is determined on the basis of the validity period. For example, the number of absence days is calculated for an absence record on the basis of the absence period. Partial periods are recreated for views without infotype data being changed. This leads to incorrect results for time infotypes since the data depends on the validity period. For this reason, the PROVIDE statement is not used for time infotypes.
- If you want to evaluate absence data according to organizational units, it is a good idea to use an internal table to group together the information from different database tables (PA0001 and PA2005).
- LOOP/ENDLOOP is the simplest way to process an internal table. It functions in the same way as SQL-SELECT for database tables. If an internal table is processed with control levels, control header processing and control footer processing are both possible. Totals can be calculated at the start and at the end of control breaks using the (SUM) statement. When internal tables are processed, the group header must be processed first, then the individual records, then finally the group footer. You must watch the order in which control levels are processed. When the headers are processed, the order is first, second, third, and so on. When the footers are processed, the order of the key fields is reversed; last, next to last, and so on. However, this does not mean that you must use control level processing for each key field.
- Organizational Management is based on the idea of representing each element within an organization as a separate object with its own characteristics. These objects are created and maintained separately. Relationships are used to link one to the other (see graphic). This gives rise to a network that is flexible enough to facilitate personnel planning, projections, and evaluations. The cost center is an external object type because it is not maintained in Organizational Management. Customizing enables you to enhance the existing data model by defining new object types, for example, and establishing new relationships between the various object types. Each standard object type consists of two letters, whereas the customer namespace is 00 to 99. This data model (object types and relationships) also constitutes the basis of other applications within Personnel Planning, such as Training and Event Management (business event hierarchies) and Personnel Development (for example, qualification catalog).
- The relationships between basic object types are defined in the standard system and should not be changed. Each standard relationship has a three-digit code. The customer namespace is from AAA to ZZZ. Relationships between objects are reciprocal. If a job describes a position, for example, then the position is described by the job. When you assign a relationship, the system automatically creates its inverse relationship. This enables you to carry out reporting from either perspective.
- An additional transparent table (HRTnnnn) for tabular data is available for infotypes whose data has a repetitive structure (table infotypes). The logical structure of tabular data is described by structure PTnnnn.
- You can specify objects for a sequential evaluation using their IDs. The sequential evaluation then takes place for all of the objects you have specified. For example, you can display a list of all organizational units in your enterprise.
- When a structural evaluation is performed, the objects to be evaluated are listed. However, the system interprets these entries in a different way. It treats each selected object as a root object and uses it as a starting point for a hierarchical structure, which it builds up using a specific evaluation path. The evaluation path consists of a series of relationships to be evaluated, starting from the root object. Structural reports can be displayed using structural graphics.
- An evaluation path describes a set of relationships between objects in a hierarchical structure. Evaluation path O-S-P , for example, describes the set of relationships found between organizational units, positions, and persons. Evaluation paths are used to select objects for structural evaluations. You choose an evaluation path, and the system evaluates the structure along the evaluation path. The report only evaluates objects that it finds in the specified evaluation path. Every standard report has a defined standard evaluation path. They are predetermined in the system and must not be changed. The standard selection screen enables you to choose evaluation paths. You can also create new evaluation paths to meet the particular requirements of your enterprise. Report RHWEGID0 displays all possible evaluation paths between the starting object type and the target object type.
- This evaluation path determines all of the assigned positions (S) and their holders (P) for a specific organizational unit (O). The subordinate organizational units are processed in exactly the same way. The &quot;Skip&quot; field enables you to determine that a specific relationship within an evaluation path is included in the evaluation but not displayed in the report list. Some evaluation paths consist of just one relationship. For example, A001 is a subdivision of and B001 is subdivided into . Thus, each relationship in the standard system has two evaluation paths. The convention A = bottom up and B = top down can be taken into account when a relationship is first defined. However, you are not obliged to follow this convention.
- For each selected object, internal table Pnnnn is filled per infotype with all available infotype records. The infotypes from Personnel Administration can also be imported.
- The only difference between a structural and sequential evaluation is the additional GDSTR entry in the TABLES statement. This ensures that the structure parameters are shown on the standard selection screen. Note: If you do not specify an evaluation path before starting the program, a sequential evaluation is performed.
- In the Evaluation path field, you enter the required evaluation path. In the Status vector field, enter the status values required by relationship infotype 1001 along the evaluation path so that the appropriate target objects are selected. This parameter enables you to determine the objects irrespective of the status of the relationship infotypes along the evaluation path. For example, enter 12 (without a comma or blank character) to indicate that you only want to display objects whose relationships have status 1 &quot;active&quot; or 2 &quot;planned&quot;. The Status overlap checkbox is used in conjunction with the status vector field. This enables you to perform a simulation. The results are displayed once all of the relationships have been activated internally. During the simulation, all of the relationships are activated in accordance with the status specified in the status vector field. Every status value as of position 2 is actived with the status value of position 1. For example, if the status vector is 123 and the status overlay parameter has been set, every relationship in status 2 and 3 is activated with status 1. The value entered in the Display depth field determines the hierarchical level up to which the structure is displayed. If the value of the field is 3, for example, the system only evaluates and displays the three highest hierarchical levels. In other words, the depth of the root object is 1. Technical depth: Depth at which a structure is read internally (interactive reporting). Recursion check : If the system detects recursion (for example, recursive data, recursive evaluation path), the selection ends.
- You can set additional structure conditions for objects to meet. For example, you can evaluate all of the positions along the organizational hierarchy that are also described by one or more specific jobs. Read type for structure condition: Objects of the check object type must be accessible from the root object using the evaluation path. AND relationship: All of the structure conditions must be met. OR relationship: One of the structure conditions must be met. Object filter: Irrelevant objects - that is, objects that do not meet the structure conditions - are hidden. Branch filter: The entire branch below such objects is also hidden.
- When the INITIALIZATION event occurs, you can set default values for the selection screen. The fields for the object ID are defined in include DBPCHSEL. This is an internal table (PCHOBJID) that must be filled with APPEND.
- You must ensure that the relationship type is queried (in accordance with table T77AR) before an assignment is effected to an additional data structure that is dependent on the relationship type.
- RH-GET-TBDAT is a macro for logical database PCH. These macros are defined in include DBPCHCOM. With this macro, you can import the data for an infotype with a repetitive structure. See also Table Infotypes . The parameters for macro RH-GET-TBDAT are: Parameter 1 : Infotype Parameter 2 : Reference field Parameter 3 : Table for structure PTnnnn Macros for logical database PCH must not be confused with macros for logical database PNP. Please note that you cannot use macros for logical databases PCH and PNP at the same time.
- The access sequence of PCH macros facilitates fast object selection using value conditions of infotype fields (infotype index). You must use this access sequence when objects are selected for sequential evaluations on the basis of whether infotypes exist with specific field values, rather than using the object ID. The parameters of macro RH-CONDITION-LINE are: Parameter 1 : Field name (for example, ABTEL) Parameter 2 : Condition (EQ,BT ) Parameter 3 : Value (for example, ‘X‘) Parameter 4 : Value (for Between) You can use this method for sequential evaluations, but you cannot use it for structural evaluations.