Declustered Payroll Results in PCC
Declustered payroll results are tables of results that have been converted into an easy-to-read decimal format. Validation of payroll results is typically stored in compressed form, which is only possible using standard or custom reports or transactions that convert payroll results from compressed form to a decimal representation that the user can understand.
Customers using PCC must store test payroll results in declustered tables. These customers can check the correctness and completeness of the payroll results during "Initiate Policy" payroll process step. They can also solve all the found issues in advance without waiting for a productive payroll and check all the required KPIs.
For customers not using PCC, declustered payroll results make it easier and faster to develop their reports for checking payroll results. Customers with PCC work with validation rules and KPIs, using all the advantages of PCC. Declustered payroll results need to be translated into decimal format, which makes the data easier to use. To use these declustered results, there are certain prerequisites to follow.
Let’s see what this looks like.
Explanation of Table Requirements
There are several critical technical requirements for a payroll solution. Performance is the first essential requirement because payroll must be processed for hundreds and often thousands of employees within strict deadlines.
Because payroll runs regularly, it is necessary to store many different wage types generated during each employee's payroll month after month, year after year. Therefore, the second critical requirement is to minimize resources for storing payroll results.
Managing Payroll Results
Managing payroll results is very important for understanding how data is stored and where it comes from in order to:
- customize new validation rules, KPIs, and analytics designer via the Manage Configuration app
- prepare technical specifications for developers to create client rule logic for validation rule types, KPI types, and analytics designer types in the Configuration Workbench
These are critical requirements for the payroll solution. Validation of payroll results stored in compressed form is only possible using standard or custom reports or transactions. These transactions convert payroll results from a compressed form to a decimal representation that the user can understand. For customers not using PСС, declustered payroll results make it easier and faster to develop their reports for checking payroll results.
Image B shows the human-readable format of the cluster tables; this is the end user result. The converted payroll results are not saved anywhere in the database but are only displayed on the screen.
An additional option is to save the information in a declustered table, seen in image C. This option is also understandable for the end user payroll results. Unlike the results in the end user transaction (image B), the information seen in image C will be saved. Information from declustered tables is used to configure KPIs, validation rules, and other PCC objects.
Using the Directory: Table HRDCT_TPY_RGDIR
Declustered payroll results are stored in several tables. There are key fields that join all these tables, including:
- person number
- a sequential number that depends on payroll area
- payroll period
- test/productive mode
Entries created on the table P2RX_RT are for both test and regular payroll.
Working with Declustered Tables
You must understand how payroll results are stored in declustered tables for:
- customizing existing validation rules, KPIs, and analytics designer
- creating new ones via the Manage Configuration app
- preparing technical specifications to create customer’s rule logic for validation rule types, KPI types, and analytics designer types in the Configuration Workbench for developers
When the system starts validating the payroll results or generating KPIs, it is very important that all conditions are met for selecting required personnel numbers and that all necessary payroll results are filtered.
Let's look at how payroll results are stored in the declustered tables in more detail.
Directory and Result Table
Relationship Between the Directory and the Result Table
There are key fields that join all these tables. The system determines the required payroll periods from one table for each employee and then sequentially selects the required payroll results by key fields in the other table. The system needs to select the payroll results from the second results table (Table P2RX_RT) specific to the personnel number and payroll period.
- Select employee personnel number
- Select payroll period
Remember, the business user thinks in terms of the payroll periods (for example, payroll results in 04 payroll periods of the current year for 03 payroll period of the current year), while the system works with the sequential number (00004) for the same payroll period.
Example of Payroll Declustering
To generate a KPI for the Monitoring (pre-payroll) process, the system first determines the required payroll periods from the table HRDCT_TPY_RGDIR for each employee from the payroll then sequentially selects the required payroll results by key fields from the table P2RX_RT.
Production Versus Test Payroll Results
Next, let’s discuss how payroll directories are organized and how the payroll results are numbered.
With the launch of PCC and its ability to store test payroll results in declustered tables, a clear differentiation between production and test payroll results has become critical. For this purpose, two catalogs were developed – one for test results (table HRDCT_TPY_RGDIR) and the other for productive ones (table HRPY_RGDIR). The system uses different number ranges for test and production payroll results.
Only the last payroll execution (last in–period) is stored in the test result directory. Every new execution causes the table entries (for the selected employees) to be deleted and recreated. The entries that correspond to the productive rows from HRPY_RGDIR are copied to the test payroll result directory so that the chain of periods for each employee is completely contained in the test payroll result directory. This allows the period evaluation to take place by analyzing the test directory as if it were the productive directory, without the need for complicated comparisons between two different directories.
Payroll in Action
To see how the payroll process works, let's look at an employee's payroll for several payroll periods and get acquainted with the features of storing and processing payroll results during executing of validation rules and generating KPIs.
Multiple Options for Payroll Results
The PCC system stores all payroll results and can distinguish them by the sequential number. This figure is an example of how production and test payroll results are numbered.
Monitoring Process
After completing the payroll test run using the Monitoring pre-payroll) process via the PCC system, the record was saved with sequential number 99001 for the personnel number 72299110 in the table HRDCT_TPY_RGDIR.
Productive Process
After completing the payroll run using the Productive process via the PCC system, the record was saved with sequential number 00001 for the personnel number 72299110 in the table HRPY_RGDIR for the same payroll period.
There are multiple options when it comes to running the payroll process that you should be aware of. For example, you can choose to use the same policies as the validation rule sets for the Monitoring (pre-payroll) process and subsequent Productive process for the same payroll period or periods. Alternatively, you can choose to use one policy for the Monitoring (pre-payroll) process and another for the Productive process.
Retroactive Calculations
For a consultant, when customizing the validation rules via Manage Configuration and preparing specifications for rule logic used in Configuration Workbench, it is important to understand how payroll results are stored and numbered in declustered tables.
Consider the Scenario
Next, let’s look at an example that shows how production and test payroll results are numbered in the case of retroactive calculation. During the closing of the 01 payroll period, the productive posting run was executed, and money transfers to employees' bank accounts were made. Unfortunately, the monthly salary amount for the already calculated period for the employee needed to be changed.
Option: Test Payroll Run
During the test payroll run (via the Monitoring (pre-payroll) process), the system can recalculate the relevant payroll data for the 01 payroll period in the 02 period (when the data was maintained in the system). The system copies existing productive payroll results for the 01 payroll period from the table HRPY_RGDIR to the table HRDCT_TPY_RGDIR with the sequential number 00001. It creates two test payroll results for the 01 payroll period (taking into account the amount of monthly salary change) with sequential number 99001 and for the 02 payroll period with sequential number 99002.
Option: Productive Payroll Run
During the productive payroll run (via the Productive process), the system recalculates and creates productive payroll results for the 01 payroll period in the 02 payroll period and productive payroll results for the 02 payroll period in the table HRPY_RGDIR. The sequential numbers for these periods were 00002 and 00003. Original payroll results for the 01 payroll period calculated in the 01 payroll period are still stored with the sequential number 00001 in the table HRPY_RGDIR because these results are used for the posting and bank transfer. Table HRPY_RGDIR is the declustered copy of the Cluster Directory RGDIR for the compressed payroll results.
Numbering Results After Retroactive Calculations
Next, let’s look at an example that shows how production and test payroll results are numbered in the next period after retroactive calculation. After the closing of the 02 payroll period, nothing changed for the employee’s master data relevant to the payroll.
Option: Monitoring Process
After completing the payroll test run using the Monitoring (pre-payroll) process via the PCC system, the system copied the actual productive payroll results for 01 and 02 payroll periods from the table HRPY_RGDIR to the table HRDCT_TPY_RGDIR and created test payroll results for 03 payroll period with sequential number 99001 for the personnel number 72299110.
Option: Productive Process
After completing the payroll run using the Productive process via the PCC system, the system stored productive payroll results for the 03 payroll period with sequential number 00004 for the personnel number 72299110 in the table HRPY_RGDIR.
Validation Rules and Database Joins
Validation rules use database joins between the test result directory and other declustered tables. Let’s see how this works with the actual tables.
Database Joins in Action
The system selects wage types and amounts for an employee and a specific payroll period in the table P2RX_RT using a sequential number from the directory HRDCT_TPY_RGDIR. For example, a validation rule should sum the total gross of an employee for the last actual period of 2024. Then, the database join is built on the P2RX_RT and HRDCT_TPY_RGDIR by joining fields PERNR and SEQNR. Table P2RX_RT contains both productive and test payroll results SEQNRS, in any case, only the correct mixture of SEQNRS is considered by the database join due to result directory selection criteria.
Monitoring Process
In the previous example, we examined how payroll periods are numbered in the case of retroactive calculations. In this example, we will focus on the amounts that will be used for the validation rules, the KPIs for the payroll period for which the recalculation was performed. When customizing the validation rules via Manage Configuration and preparing specifications for rule logic used in Configuration Workbench, it is important to understand how payroll results are selected from the declustered result table P2RX_RT using a sequential number from the directory HRDCT_TPY_RGDIR in case of recalculations.
Scenario
After the closing of the 03 payroll period, when the productive posting run was executed, and money transfers to employees to the bank were made, It turned out that the monthly salary amount for the already calculated 03 period for the employee needed to be changed.
During the test payroll run (via the Monitoring (pre-payroll) process) in 04 payroll period, the system recalculated the payroll relevant data for the 03 payroll period in the 03 period (when the data was maintained in the system). The system copied existing productive payroll results for the 03 payroll period from the table HRPY_RGDIR to the table HRDCT_TPY_RGDIR with the sequential number 00004. It created two test payroll results for the 03 payroll period (taking into account the amount of monthly salary change) with sequential number 99001 and for the 04 payroll period with sequential number 99002.
Declustered Results
Now, the declustered results table P2RX_RT stores two payroll results for the same 03 payroll period:
- Productive payroll results created in the 03 payroll period for the 03 payroll period
- Test payroll results created taking into account updated information on the monthly salary received in the 04 payroll period.
For the validation rules and KPIs, the system will only take into account the test payroll results created in the 04 payroll period for the 03 payroll period, taking into account current information and ignoring outdated productive calculation results created earlier for the same payroll period. We still need the payroll results performed in period 03 for payroll period 03, for recalculation differences, and for consistency of postings and bank transfers data.
Business Functions
Here is a list the business functions that need to be activated for two alternative SAP payroll solutions (single employment (SE) and concurrent employment (CE)). In this course, all demonstrations and exercises are performed based on the SE solution for the international version (molga 99).
Prerequisites for Declustered Payroll Results:
- SWF5: HCM_LOC_CI_50 OR HCM_LOC_CI_75
- AND HCM_LOC_CI_63
Note that activating these Business Functions is a mandatory prerequisite for configuring and using the declustered payroll results. The Declustering functionality is not new – (available since EHP4); what is new is the creation of pre-payroll declustered results, making PCC validations possible during monitoring process run.
Declustering Payroll Results
Next, let’s talk about what needs to be done to set up data declustering payroll results. After activating the corresponding business functions, a new branch with two customizing nodes will appear in the Implementation Guide (IMG). The system needs to provide additional information for the declustering of payroll results.
Storing declustered payroll results requires significant memory. There are two options for storing declustered payroll results:
- Option 1: On the same server as the cluster
- Option 2: On a different server. In this case, you need to configure DB Connection (first setting). Then, define how the declustered table will be filled (second setting). Immediately upon completion of the payroll processing, the payroll results will be exported to the cluster and to declustered tables at the same time.
Alternatively, you can use a special report that runs as needed.
Defining What Payroll Result Tables Need to be Declustered
There are several internal tables for storing different information connected with payroll results. In this step, it is necessary to define which tables must be stored in declustered format. Because storing declustered payroll results requires significant memory, only use only use tables that are truly needed for the validation rules and KPIs. Of course, the payroll results (RT) table is the most important. But for various checks, you may need some additional tables.
Let’s talk about what needs to be done to set up data declustering payroll results. When creating settings, it is important to understand what you are doing and why. Country-independent settings aren’t accessed through IMG, but these settings are mandatory. It is necessary to perform not only country-specific settings for declustering the payroll results but also country-independent settings. Make sure to decluster tables P2RX_EVAL_PERIOD and P2RX_TPY_EVAL_P.
The meaning of the settings is the same as for country-specific settings, but in this case, setting up declustering for a country-independent table P2RX_EVAL_PERIOD must be done explicitly, otherwise, declustering cannot be performed due to the technical features of storing payroll results.
Country-independent is not accessed through IMG.
- Cluster ID CU where?
- On Cluster Table PCL2!
Configure through SM30
- V_T77DCT_OPTION: Turn on first
- V_T77DCT_REG: Select table
Initial Load Report
After setting up declustering, if necessary, you can perform an initial load of the payroll results using a report RPCDCT_INITIAL_LOAD. For some specific validation rules and KPIs, it may be necessary to load historical payroll results from the cluster, which are created before activating business functions and setting up declustering. This image shows what an initial load for declustered payroll results report looks like.
System Table
This is a system table, which means that all records in it belong to SAP, and no changes from the customer's side are implied in this table. Therefore, this table is not included in Implementation Management Guide (IMG). To set up declustering, it is important to know where to get information about the cluster ID for a particular country. This image shows system table T500l, where it is possible to check cluster IDs used for particular country-specific versions. You can check country-specific Cluster ID in table T500L.
