In this series of blogs I will explain how you can leverage the new analytics capabilities of the payroll declustering tools, so that you can analyze and report payroll data in real time without the need of data replication and also how you can build custom queries based on the declustering data model which can be consumed for example by the payroll control center or by your own custom reports.
First of all, some background: with the introduction of the declustering tools, SAP has enabled the so far clustered payroll results data to be stored also in a transparent structure (usual database tables, not BLOBs). This new data structure enables great analytical capabilities that can be performed directly on database level. Until now, the analysis of payroll data was restricted to the ABAP reporting layer by using the logical database PNP, which required that each individual employee’s data is collected sequentially one by one, leading to long run times (an alternative to the abap reporting is also to bring data to BW systems, which also requires long data extraction times).
Reporting of sums (aggregation of salaries, taxes, social insurances, per company code for example) made so far by the wagetype reporter (program H99CWTR0, which runs for large employee population over batch jobs) can now be done real time allowing users to interactively filter, group by and sort the data they want to see. The iteration time between one query and another is reduced to seconds instead of minutes or hours.
Customers can connect analytic (OLAP) tools to payroll declustering Cubes or develop simple queries to obtain their desired data.
Here is how this is possible: SAP has made a couple of “Payroll results indexing tables” available together with the declustering tools, which in combination with the usual *transparent payroll result tables allow:
- Period (in-period/for-period) specific aggregations
- Correct assignment of wagetypes to time split (work pay basic pay “WPBP” splits).
- Retro-calculation analysis
- Authorization restriction on employee level
*For more information on the “transparent payroll result tables” and declustering in general, see notes 1774918 and 1846500 (in the meanwhile, the declustering has been enabled for almost all existing SAP_HR country versions, with the last country versions being available from SAP HR 604 SP 71. For country specific availability information, see the Declustering notes on SAP Marketplace). Documentation about declustering can be found on SAP Help: http://help.sap.com/erp2005_ehp_06/helpdata/en/d6/e9ae62080b4ec19946efb32e50d82a/frameset.htm
This first blog focuses on the introduction to the indexing tables. You will find more information on these posts: analytic tools, HANA content, building queries, and authorizations.
Indexing tables
The indexing tables, as the other common payroll result tables, are filled up with data by the declustering tools, they just need to be enabled for declustering in your system. Let’s have a closer look into each of these tables and their usage:
Table P2RX_WPBP_INDEX
This table serves to map the wagetypes without a WPBP split (when the APZNR = 00) to the last split of the payroll period.
Basically every WPBP (table work place basic pay in payroll results cluster) record stores the information of the (among others) employee’s organizational assignment for a given payroll period. In case the employee has been assigned to different organizations within the same period, the WPBP table will hold multiple records for that payroll period. The WPBP records have a numeric key field (field APZNR) which starts with value ‘01’. The table RT contains a reference to this WPBP key, so that it can be made possible to assign the amount or value of a specific wagetype to a specific organizational assignment.
This is useful when it is required to know for example the total amount of employment tax paid by a company code in a given period. The problem is that in many cases the gross wagetypes (between others, and country and context specific) do not physically point at all to any record of WPBP table (the field APZNR in table RT is equal to 00 and this value does not exist in WPBP). By convention, many HR reports and also the wagetype reporter H99CWTR0 will automatically link such cases to the last assignment in table WPBP for that given period. And this convention has meanwhile become a common business practice.
The picture bellow shows typical wagetypes unassigned to any WPBP record:
In contrast the following wagetypes are assigned to WPBP record 01:
The following example shows the already declustered payroll result tables WPBP and RT (the transparent tables) with a case in which the employee has had a “company change” during a payroll period; therefore two records in table WPBP exist for that period:
And the RT table shows wagetypes assigned to APZNR field values 00, 01 and 02. Naturally, if we try to join tables RT and WPBP on database level (for example with a SQL JOIN) we would miss all the wagetypes that have APZNR = 00
In order to solve the issue of not being able to “SQL JOIN” (DB level) between RT and WPBP, the table P2RX_WPBP_INDEX has been introduced. This table has a copy of the APZNR pointer of table RT and an additional field called WPBP_APZNR which is a pointer to a real WPBP record. Following the convention used in the wagetype reporter, all the wagetypes in RT table that point to APZNR = 00 now point to the last WPBP record of the corresponding payroll period.
In the case below, wagetypes of result SEQNR = 9 with APZNR = 00 will now point to APZNR = 02. Note that the field DCT_SEQNR in the picture below is the so called Payroll result sequence number (field SEQNR):
Therefore the three above mentioned tables can be joined on DB level according to the following relationship:
To make the declustering tools automatically fill the table P2RX_WPBP_INDEX, you need to register it in the IMG step “Register Payroll Result Tables to be Declustered” (maintenance view V_T77DCT_REG) as in the picture below:
- WPBP_INDEX P2RX_WPBP_INDEX
Table P2RX_EVAL_PERIOD
This table makes retro-calculation analysis possible and allows an easier payroll period evaluation. This kind of evaluation had so far only been provided by Function Module CD_EVALUATION_PERIODS (ABAP layer) on an employee by employee basis. Now the process of identifying the correct employee’s “Actual” and “Previous” payroll result periods and their delta (so called “A minus P” when processing wagetypes) is much easier. And this can be done for both “in-period” view and “for-period” view (these views are usually output options on payroll evaluation reports such as the wagetype reporter). Therefore you can now achieve this kind of analysis on DB level for a big set of employees at once instead of depending on the classic employee-by-employee analysis on the ABAP layer.
Let’s first have a look how the data in this table is organized. First, taking as an example the payroll results directory table (RGDIR) of an employee (which you can access in transaction PC_PAYRESULT) we might find retro-calculation over retro-calculation scenarios such as the following on period 04.2014 on the picture below (see SEQNRs: 00022 till 00032):
This employee has a case in which period 04.2014, originally calculated on SEQNR 00022 has been retro-calculated on periods 05.2014 and 06.2014 (SEQNRs 00023 and 00028, notice in between we see some off cycles). This leads to a problem when we want to obtain the correct (in-period) evaluation of wagetype amounts for each of the periods 04, 05 and 06 of 2014; this would have to be achieved in the following way (ignoring the off cycles for simplicity reasons):
- Evaluation of Period 04.2014: consider the Period with SEQNR 00022 as the ‘A’ result (RGDIR shows it as an ‘O’)
- Evaluation of Period 05.2014: subtract the sum of the amounts (of the required wagetypes) of Periods with SEQNRs 00024 and 00023 from the amounts of period 00022. In other words, result = 00024 + 00023 - 00022.
- Evaluation of Period 06.2014: subtract the sum of the amounts (of the required wagetypes) of Periods with SEQNRs between 00028 and 00032 from the amounts of periods between SEQNR 00023 and 00027. In other words, result = (00028 + 00029 + … + 00032) – (00023 + 00024 + … + 00027). The situation could easily get more complicated, for example if period 03.2014 had been retro-calculated in 06.2014, this would require a subtraction of period 00021 as well, while skipping period 00022.
So we see that the logic involved in evaluation the periods is tricky, which is why it had always been calculated in the abap layer, employee by employee.
Now we can check how the data of the above example is displaced in the table P2RX_EVAL_PERIOD:
In order to perform the evaluation of periods 04.2014, 05.2014 and 06.2014 as in the above stated examples, you can SQL Join table P2RX_EVAL_PERIOD with P2RX_RT (and others too) and it is only necessary to scan the entries filtering the column “INPER” with the required in-period value and to invert the sign (multiply by minus one) of the wagetypes of the periods shown as “P” (SRTZA = ‘P’). Note that this table holds only the Key fields of table RGDIR, so it serves a Period-index to the RGDIR (or to the payroll results directly) by means of the field SEQNR. The field SRTZA (actual/previous indicator) will only hold values ‘A’ and ‘P’ (Actual and previous), the value ‘O’ (older) will not occur, which is the same resulting logic provided by function module CD_EVALUATION_PERIODS.
This is an example on how the table P2RX_EVAL_PERIOD can be joined with table P2RX_RT (represented as “data foundation” on the below picture):
A helpful trick is to invert the sign of amounts and number fields for the “previous periods” by using calculated expressions, like:
*We will talk more about this here.
To make the declustering tools automatically fill the table P2RX_EVAL_PERIOD, you need to register it in the IMG step “Register Payroll Result Tables to be Declustered” for Cluster ID = ‘CU’. This step is different as for the one related to P2RX_WPBP_INDEX since it is country independent. Maintenance view V_T77DCT_REG as in the picture below:
- EVAL_PERIOD P2RX_EVAL_PERIOD
Note: don’t forget that for simpler period analysis table HRPY_RGDIR is also available and can be joined with Declustered tables like P2RX_RT. Check the blog post about hana content and ddl views for examples on how to consume these tables.
*Technical note on how these tables are filled by the declustering tools: Method MODIFY_DATA_EXT of class CL_HRDCT_MANAGER will call the BAdI hrdct_b_processor_ext. This will then trigger the enhancement implementation HRDCT_PROCESSOR_PY and the specific implementation CL_HRDCT_IM_EVAL_PERIOD (done via Badi filters depending on the table’s name) which is the class that contains the period evaluation logic and is responsible for the filling the content in table P2RX_EVAL_PERIOD. Similar works for table P2RX_WPBP_INDEX with an implementation class following the same naming convention.