The main source transaction of most HR data is PA20. Here the data for every employee can be viewed. All the data relating to the employee is stored using infotypes. So for example Address information is stored under infotype 0006. Organizational Assignment is infotype 0001. You can either type the infotype number directly into the infotype field or use the F4 help to find the on you wish.
Please note the green ticks these indicate whether this employee has data saved under this infotype.
Each infotype is matched to a flat table. The format is PA<Infotype Number>. So the data of infotype 0001 is stored in table PA0001. Please note in help.sap.com the datasources give the source tables. So if in sap help the Table of Origin is PA0000 you know that the data is viewed in PA20 - infotype 0000.
For all of the below extractors it is recommended that you ask the customer for 1 single employee number for which the problem can be seen.
'''0hr_pt_2-Actual Time and Labor Times'''
'''Reporting Time Types'''
Hr time data is stored referencing 'time types'. So for example 'Normal Work hours' might be time Type 0002 or Overtime might be 0310. For BW extraction time types must be grouped to form 'reporting time types'. A reporting time type can contain more then one time type. So for example if customer just wishes to report on absences in BW and they are not interested in the nature of these absences the can add all absence time types into one reporting time type, the key figures will be aggregated accordingly. If a time type is not contained in a reporting time type the record will not be extracted by 0hr_pt_2
'Reporting time types' are maintained in sbiw->Settings for Application-Specific DataSources
->Human Resources->Actual employee times->Define reporting time types->Maintain Accumulators for Employee Times
You can view the actual 'time types' on the system in transaction spro->Time Management->Time data recording and AdminAbsences/Attendances-->Define Absences/Attendances. The source table is 554S.
Taking the 'leave' reporting time type as an example. All records for an employee, whose time type is leave, leave w/ quota deduction and paid leave will be cumulated and extracted as 'Reporting time type 00000001
Source of extraction for 0HR_PT_2
Depending on how the customer creates their time data the will have to maintain different reporting time types. Please note this means the source tables of the data for 0hr_pt_2 can be different depending on customer's configuration
Many companies have different working conditions for different employees. For example salaried verses hourly rate workers.
This also needs to be handled by 0HR_PT_2. To do this you maintain GRDWT. Path sbiw->Settings for Application-Specific DataSources->Human Resources-> Actual Employee Times OHR_PT_02
->Define reporting time types--> HR: Transport Customer Features
This is a decision tree. So in the above example if the records Org_Unit = 100 it is given Grouping feature 01. If Org_Unit is any other value the grouping feature is 02.
Returning to the Maintain Accumulators for Employee Times. The first field GrpgRptg gets this grouping feature.
'''If an employee is not caught by the tree they will not be extracted'''
Each employee has a work plan in HR. i.e. number of planned hours per week to work.
This is viewable in pa20 for infotype 0007 or table pa0007
This datasource always extracts two records for each source record (a planned day's work). The first is in hourly units the second is in day units. It is up to the customer to decide which record they which to use.
Above shows the two records for employee 1000 on 14.07.2005. Planned to work 8 hours (first record) or 1 day (second record)
Note also the reporting time type (RptgTmTy) above. 0HR_PT_1 does not use reporting time types in the same manner as 0HR_PT_1. The reporting time type is always hard coded to 00000009.
0HR_PT_3- Quota Transactions
Each employee has a quota of days off they are allowed to take each year i.e. your holiday allowance!
Quotas must be maintained into 'reporting quota types' in exactly the same manner as for time types in 0HR_PT_2.
Sbiw -> Settings for Application-Specific DataSourcesHuman Resources -> Quota Transaction Data OHR_PT_03 -> Define Reporting Quota Types Maintain Reporting Quota Types. If a quota type is not maintained it is not extracted.
'Maintain Feature GRDWK' is also the same process of configuration as for 0hr_pt_2 and again if a record is missed in the decision tree it is not extracted
The delta for all of these PT datasources uses the timestamp stored in infotype 439 table PA0439. In PA0439 you will see, that the subtype field basically reflects the Datasource number, so subtype 0001 is for 0HR_PT_1, subtype 0002 for 0HR_PT_2, 0003 for 0HR_PT_3.
For each employee Change_Log_Date is updated for each delta run with the lowest value from the time record. Delta the checks every record subsequent to Change_Log_date. The before and after image is compared and if there is a difference the record is extracted.
Because PA does not store after images the delta process must store these. The records of ALL the deltas are stored in a series of tables PTDW*. The data is stored in a referenced nature much the same as SID's in BW. There is a view over each table which allows you to read the record
'''Data Source ---Header Table ------ View'''
0HR_PT_1 --- PTDW_PWS_DB ----- PTDW_PWS_VIEW
0HR_PT_2 --- PTDW_TIMES_DB ----- PTDW_TIMES_VIEW
0HR_PT_3 --- PTDW_QUOT_DB ----- PTDW_QUOT_VIEW
==Time Window for Delta:==
The above delta process can be very time consuming. For each employee in the system many records must be checked and compared to see if thee is a difference for the delta. To reduce some of the load on each delta run there is a time window for
Sbiw -> Settings for Application-Specific DataSources -> Human Resources -> Define Time Frame for Transfer
Here the customer must maintain an upper and lower limit for extraction. This affects all PT Datasources. Any records which are outside the range maintained here will be ignored by the extraction. This also affects full updates and delta initializations. We recommend maintaining a range of approximately one year. If the customer does not maintain this feature they will have major performance issues. See note '''353177'''
'''0HR_PY_1- Payroll data'''
See also description of cube Payroll data cube 0PY_C02
This datasource extracts data from a payroll run. In HR each employee is assigned to a Payroll Area PA20->Infotype 0001.A payroll area holds all the employees contained in a payroll run for example 'Salaried employees Dublin'. The payroll run would calculate all the data needed to create the Personnel area's wage slips for a given period. It will then write these results to cluster table PCL2. Note as this is a cluster it cannot be read directly. You can use transaction pc_payresult to view the data of a run.
Above are all the payroll runs for this employee. 'For-Period' is the period the work was done. 'In-Period' is the period the payroll run happened. For example many employees are paid for work that happened in the past.
A payroll run can happen more then once for a period. E.g. a mistake may be discovered by an employee in their wages. You can then do a recalculation run. This run appears as a new run in Pc_payresults. If you note the first column of pc_payresults 'Current indicator' this will tell you if a recalculation has occurred.
The last payroll run for a period is 'A'. If a recalculation occurs this gets changed to P and the recalculation becomes 'A'. If another recalculation occurs the P record becomes 'O' (you can have many 'O' records). The 'A' again becomes 'P'. This is necessary for the delta process to find before images. As the delta just needs to read the P record to get the old value which went to BW and compare it with the A record to get the change. Please note this extractor only delivers additive records.
You can also have 'Off cycle payroll runs' e.g. a bonus payment. These will have no For-Period or In-Period in pc_payresult just a payment date.
If you drill down on a specific payroll run tables RT and _RT contain the data transferred by 0hr_Py_1.
Drill down on these to get the actual data
The wage types describe each record. You have an individual wage type for any modifier to an employee's payroll. Medical insurance, gross pay, pension payment are all examples.
You can view the wage types on the system in transaction spro Personnel Management Personnel Administration Payroll DataAll of these are different wage types. An easier way to see this is to use sm34-V_T512T and enter the country.
Note that each 'wage type' here is extracted as a separate record. So an extraction for one employee in one payroll period can return a large number of records
Payroll Control Record
There is also a Payroll control record for each payroll run. This is usually not an issue on a production system as the customer will be constantly updating this as they run their payroll runs. However on a test system this can be changed. The Payroll period date here is an upper limit for extraction (This only affects delta initialization and delta, full update is not affected).See message 1288871 2005 for more explanation. To view the control record you use PA03.
PY Delta Process
PY uses an extractor delta; it does not use the delta queue.
There is a special infotype 439 the BW delta. Use transaction PA20 to view this or table PA0439. Subtype 1001 is payroll
The field transferred-to PA0439-TRANSFERE_DATE holds the date of the last extraction to BW for this employee. For each employee all relevant Payroll runs subsequent to TRANSFERE_DATE are checked for delta records. If necessary the A and P payroll runs are checked for additive deltas. If the is no recalculation run (no P record) in the period the extractor will only deliver new records.
0HR_PY_PP_1 and 0HR_PY_PP_2
0HR_PY_PP_2 contains essentially the same information however 0HR_PY_PP_1 is more granular.
After the payroll run the CO system needs to be informed of the costs involved in paying the companies employees. These extractors extract this information. When a payroll run is executed there is an option to create this CO data after the run completes. The data is stored mainly in table PPOIX. As it is stored across many tales you must use transaction PCP0 to view the data. Please note when you use PCP0 select EditFilterDelete Filter in order to be able to see delta relevant information
Each line here is the costing information of one payroll run. Please note only type PP are extracted. This means that the run must have status 'Documents Posted' for BW to read the run. If the run has any other status it is not extracted.
Select the run you want here.
This is the source for 0HR_PY_PP_2, drill down again for 0HR_PY_PP_1.
The delta is quite simple. All payroll runs greater then the timestamp contained in table hrms_biw_ppdelta are extracted.
Performance issues will occur here if the size of table PPOIX gets too large. An easy way to reduce this is to get the customer to delete old SIMULATED payroll runs. This can be done using report RPCIPQ00.
Cross-Application Time Sheet (CATS) Extractors:
'''CA_TS_IS_1 - Time Sheet Data (Approved)'''
This datasource extracts time sheet data from transaction CATS. The source table is CATSDB. Records are only extracted if the time data is Approved i.e. (CATSDB -STATUS) = 30. However the status field is not extracted to BW.
The extractor uses a delta timestamp (which is held in table CATS_BW_TIME).
This means that in a special case records with STATUS 60 will be extracted.
The extractor cumulates the records into reporting time types using the same process as
0HR_PT_2.Please note however if CATSDB-AWART and CATSDB-LGART are both not filled the record will be extracted without being cumulated by the Reporting time types.
Time Sheet Data (Released for Approval) CA_TS_IS_2
Similar too CA_TS_IS_1, this datasource extracts records with CATSDB-STATUS = 20.
BCT-PA Masterdata attributes
'''This covers all the datasources in PA. For example 0employee, 0person.Follow link for full list.'''
All of these extractors use the function module HR_BIW_GET_MASTER_DATA. This function operates in much the same way as EXIT_SAPLRSAP_002 for customer exits in extraction. There is a CASE statement which catches all the datasources. So if the problem is with 0person.Search the module for Person (note you drop the 0) to find the clause for this datasource.
All of these datasources are time dependant and they cannot have overlapping time records. In standard HR will not allow overlapping time records to be created however customers will sometimes modify standard to allow overlaps. When this data gets to BW it will dump with itab_duplicate_key or an error message in the PSA relating to the overlap. To spot modifications to standard you can run the report heck the time constraints in T582a-ZEITB.If this is not equal to 1 then overlapping records can occur. The report RHCTIMCO will spot changes to standard here (Plan version is 01) . Also if you need to check an individual employee you can use report RPU_CHECK_TIMECONSTRAINTS_S1
'''BCT-PA Masterdata Texts'''
( See list of datasources on the left pane)
These datasources are simply a view over the source table. Use rsa2 to find the view in question.
== PA Masterdata in BW ==
A dummy record is always created in BW to complete the time dependency to 01.01.1000.This is ignored in reporting.
== BCT-PA Transactional Data ==
'''0HR_PA_1 Personnel actions'''
This datasource extracts information about changes in employees employment status i.e. hired, fired, transferred etc. There are no cumulative key figures in the datasource. All the key figures use exception aggregation in BW. For example if you are hired the status will be '01' but if you then have a change of organization the status will be '02'. It makes no sense to cumulate these figures in BW as they represent actions not numbers.
The source of the data here is usually infotype 0000(Table PA0000).However there is a customizing table T7750.If the value in here for GRPID=ADMIN and SEMID =EVSUP
Is any other value then ' ', the source of the data will change to infotype 0302(Table PA0302)
=== 0HR_PA_PA_1-Headcount ===
Please note the extractor exists in BW not in the source system. It extracts data from 0person and 0employee so these must have the data loaded into them first! In order to use this datasource customer must follow the instructions in note '''336229''' exactly. All problems so far with this extractor have related to customers missing a step in the note.
=== 0HR_PA_2-Structural Authorizations ===
Hr has its own authorization model which is built on top of R/3 authorizations. 0HR_PA_2 extracts this model into an ODS whereupon the program RSSB_GENERATE_AUTHORIZATIONS is run in BW to transfer these authorizations in BW relevant authorizations.
In HR the authorizations are created using the program RHBAUS00 or RHBAUS02. These two programs filled the cluster INDX which acts as the source for extraction of 0HR_PA_2. You can read this cluster using the process described in note 836478.
The two programs RHBAUS00 or RHBAUS02 read the tables
T77UA- This maps a profile to a user
T77PR- Profile definition
T77UU- Control information about how often a users authorization should be generated.
So if a user is not in T77UA no profile will be generated for this user into the INDX table and therefore no data will be extracted, therefore the user will have no authorizations in BW.
If a user exists in T77UA, but T77UA-PROFILE is empty or has no associated profile in T77PR then the user is given the value of SAP* user. This SAP* user is a default user and has access to ALL authorizations! Therefore the user can see everything in BW HR.
== BW-BCT-PA - Organizational Management ==
An Organizational Structure can be viewed with the report RHSTRU00.Their evaluation path is always in help.sap.com for the datasource. Sometimes customers modify the evaluation path. To see if this is the case, compare the path in table T77AW to one of our test systems. If there is a difference the customer must retry extraction without the modification.
=== 0HR_PA_OS_1- Staffing Assignments ===
Only the active plan version is taken into account in the extraction.
If customer has notes '''783998 and 777928''' the performance of the extractor is set. There is no possibility to improve this.
For general functionality see note '''520677'''
'''Span of control (CONTROL_SPAN)'''
The span of control contains the number of employees who a Manager is in control of (Note field IS_LEADER i.e. person is a manager) must be set for span of control to be calculated. The Span of control is calculated in function HR_BW_GET_CONTROL_SPAN.
Please note span of control only counts the employees directly under a manager. If you have Manager A who is in charge of 7 employees. 2 of these employees D and F are also managers who each have 2 and 3 employees in their charge respectfully. The span control of Manager A is 7. It does not include the employees under Managers B and C(who's span of control is 2 and 3 respectfully)