For example, the figure above shows a view of setting a wage type. One incorrectly set parameter or checkbox will lead to an incorrect calculation.
Moreover, the price of an error can be very high both in monetary terms and in terms of reputation.
It is also worth noting that the error may not appear immediately, but only a few months after the calculation. In this case, it may be necessary to recalculate wages for several months, or to create a special corrective calculation scheme. Both of these scenarios are extremely time-consuming and risky, therefore they can only be considered as a last resort.
Where can such errors come from? HR-functionality is constantly evolving; legislative requirements and business requirements are changing. To meet these requirements, you must regularly make changes to your SAP HCM settings. In our company, all changes are implemented in monthly releases. Standard updates from SAP also come out about once a month and are installed with the release.
Updates from the vendor are packages containing notes with changes to programs and settings. The figure shows the composition of the update package SAPK-60866INEAHRCRU, containing four payroll notes for Russia.
Installing your own development products / settings and standard service packs can change the current settings and lead to incorrect system operation.
Regression testing
How can I confirm that the existing functionality was not affected by standard SAP updates and my own new developments / settings?
You can of course analyze all the changes, all the standard notes. Create examples for them and conduct functional testing.
But here it must be borne in mind that the number of notes can be in the tens, and they can affect the accompanying functionality. And if we add to this the size of our company (more than 270,000 employees are calculated in SAP HR), then the number of possible cases will exceed a reasonable amount.
To solve this problem, the employees of our department “Business Applications SAP HR Management” developed a mechanism for regression testing of wages.
The essence of this mechanism is quite simple. First, a standard is created - by calculating wages on the original system.
Then updates are installed on the system and a new payroll calculation is made. The results are stored as release data.
And at the last stage, the standard is reconciled with the release data.
Testing takes place on the entire volume of personnel numbers.
Now let's talk about this in more detail.
Our SAP HCM has a classic 3-system landscape. A development system (let's call it HRD), a testing system (HRT), and a productive system (HRP). All improvements are necessarily tested in HRT, while the technical characteristics of the test system are close to the characteristics of the productive.
Regression testing is divided into stages:
- HRT system preparation
- Test data preparation
- Removal of the standard
- Release release
- Reconciliation of Results
HRT Test System Preparation Phase
At this stage, the base specialists are preparing the HRT system. HRT is restored from a backup of a productive system on a specific date. Those. data in HRP and HRT become the same.
Test data preparation phase
Despite the fact that the data between the productive and test systems are aligned, testing payroll must be carried out on an unbilled period. To do this, prepare test data:
- Timestamp Generation
Since we want to calculate a new period, we need to generate time stamps for employees who are registered positively. For this, with the help of the developed program, time stamps of arrival / departure in IT2011 are generated from the employee’s schedule in IT0007.
- Data Maintenance IT0027 Cost Sharing
For employees who are registered positively, 0027IT Cost allocation is filled out by copying data from IT1018 using a specially designed program.
- Maintaining Data for Down Payment Calculation
Test data is prepared in full on personnel numbers assigned to each calculation unit. To do this, IT267 Extra-cyclical payments are filled in using transaction HRUU0267.
To calculate vacations, bonuses, layoffs and various types of sick leave, test data is created for about 20 employees.
After all the test data has been started, the back-up of the HRT system is performed.
Stage of removal of the standard
This phase includes:
- Time Evaluation
For this, a variant is created in the pt60 time evaluation transaction, which is further used in the RPCS0000 program. The standard program RPCS0000 is used to run time evaluations in parallel by personnel group groups. Using RPCS0000 can significantly reduce the time evaluation time.
- Saving the benchmark for time evaluation results
After completing the time evaluation, it is necessary to save the result. To do this, a special program has been created that stores the results of the assessment (tables ZES and ZL) in text files:
A fragment of the created time evaluation standard file:
- Carrying out payroll (regular and inter-settlement payments)
Settlements are performed by standard means (HRCUCLACM program and transaction PUST) on the entire volume of personnel numbers.
- Saving calculation results for subsequent reconciliation
To do this, in the standard report on wage types PC00_M99_CWTR, we save the option for viewing the necessary calculation (regular or inter-settlement). To save the calculation data in the HRD development system, a user program was developed. One of the input parameters for this program is the generated version of the report PC00_M99_CWTR:
After working out this program in the HRD development system, reference results of payroll calculation will be saved:
- Posting
In the HRT test system, a productive run of postings to the test financial system is performed. After that, using a specially designed program, posting data is uploaded to the HRD development system as a reference for future reconciliation.
After completing this program, the reference results of postings to the financial system will be saved in the HRD development system:
- Formation of registers for transfer
After calculating the salary, we form a register for transfer. Using the developed user program, these registries are also stored in text files as a reference.
Fragment of a file of the registry standard for salary transfer:
- Tax reporting
6-NDFL and 2-NDFL tax reports are generated using standard reports RPCPAYRU_6NDFL and HRULNDFL, respectively. For testing needs, they have been extended with logic to store results in transparent tables. After the tax reporting is generated in a test environment, these results are transferred to the development system using a user program.
Received tax data standard:
Release Release Phase
After the standard is removed, it is necessary to restore the testing system from the backup made after the stage of preparation of test data. Those. we get a system with wound up test data, but without calculations. All updates are installed on this system — proprietary developments and standard service packs from SAP. After that, regular and inter-calculation payroll, posting and other actions are performed similar to the actions at the stage of removal of the standard.
Reconciliation stage
After removing the standard and release, the turn of the reconciliation stage comes. At this stage
we compare the data received before installing the updates with the data on the updated system. And based on the analysis of the discrepancies, we draw conclusions about the presence of errors in the installed updates.
- Reconciliation of time evaluation results
To do this, we run the automation program for reconciling the calculation results in the "Comparison of the standard and release" mode. As one of the parameters, we indicate the directory in which the time evaluation standard file was saved.
If there is a difference between the standard and release data, this report will display it.
- Posting reconciliation
Posting data from the release and benchmark is already in the development system. For verification, a user report is used, in which we indicate the release dates and the standard as parameters:
If there is a difference between the standard and release data, this report will display it.
- Reconciliation of tax reporting
Data with the results of generating reports of 2-NDFL and 6-NDFL at the stage of removal of both the standard and the release were transferred to the HRD development system. A user report is used to verify data. Where the input parameters are the dates of removal of the standard \ release and the user under whom these removals took place:
If there are differences in the data, they are displayed.
- Reconciliation of payroll
The data obtained during the regular calculation of wages, with various inter-settlements in the test system at the stage of formation of the standard and release, were transferred to the development system. Now in the development system there is a verification of data on the standard and release using the developed user program:
All discrepancies received are available in the report.
- Reconciliation of registries for transfer
At the stage of release release, text files with registry data for transfer were generated. We compare these reference data with the registries for listing created after installing the updates.
In case of discrepancies, they are displayed in the report.
All discrepancies obtained are analyzed by specialists of SAP HCM support department. If the reason for the discrepancy is errors in the settings / designs, they are corrected and tested in the next iteration. Those. the test system is again restored from the backup taken after the establishment of the test data, install updates with bug fixes and re-carry out the steps of removing the release and reconciliation.
This approach allows for very high quality testing of such a critical process as payroll and is used not only for testing monthly releases / updates, but also in project activities. So, only this year it was successfully applied on two large projects - reorganization of legal entities and updating the SAP HCM system to enhancement level 8.