Symptom
The payroll posting is a process with a high workload for the system, and in some cases, issues related to the performance can appear.
The purpose of this article is to provide a collective guide with some known and common causes for a performance problem, with the corresponding recommendations to solve or reduce it.
Environment
Posting of payroll results in HCM module.
Reproducing the Issue
When running the posting with RPCIPE00 / RPCIPE01 / RPCIPE01CE you observe some of the possible situations:
- The background run for current payroll period is taking too much time to complete, compared to previous payroll periods
- The process is stuck in background
- The system is giving memory dumps like TSV_TNEW_PAGE_ALLOC_FAILED
- The system is giving dump SYSTEM_IMODE_TOO_LARGE
- EXPORT_TOO_MUCH_DATA dump is received in RPCIPE01
- The system is giving TIME_OUT dump when ran in online mode for a few employees
Cause
There can be many different causes for a performance issue in this complex process. This article covers many of these possible causes and solutions, and also relevant information which can help to get a better performance.
Please proceed to Resolution section below for detailed explanation and steps for each of the covered points.
- Information concerning upgrade to 6.0 and New G/L accounting.
- Too much data stored in posting tables. Cleanup and archiving.
- Posting log activated for many employees
- Massive generation of error messages in the log
- Payroll period contains massive retroactivity forced through payroll
- Parallelization in RPCIPE01
- Relevant SAP standard correction missing
- Performance and summarization. Potential impact of customer User-Exit 002.
- Document splitting active in Finance
- Elimination of zero amount line items avoided by customizing of note 1624843
Resolution
In this section, each of the described causes and points will be explained.
1. Information concerning upgrade to 6.0 and New G/L Accounting.
As of SAP Release ECC 6.0 the evaluation for the posting of payroll to accounting was adjusted to the current legal requirements by the International Financial Reporting Standards (IFRS).
Notes 1039346, 1079153 and 1699381 provide detailed information on this regard.
- RPCIPE00. As of SAP Release ECC 6.0, important adjustments were done to the report to achieve legal requirements of the New General Ledger Accounting with payroll function XCODI. The logic for New G/L implemented at many places in RPCIPE00 causes a higher amount of data as additional accounting information has to be distributed to liabilities.
- RPCIPE01 (RPCIPE01CE for concurrent employment scenarios). To gain a better performance due to the new functionalities covered in RPCIPE00, posting report RPCIPE01 was delivered. RPCIPE01 covers new General Ledger Accounting with the payroll function XLIDI. With customizing in the posting variant, it can be decided to use the program for posting payroll results (run type PP) or to post payments (run type PM) equivalent to H99_POST_PAYMENT. RPCIPE01 allows parallelization of the posting run creation.
- RPCIPE00_OLD (RPCIPE00_OLD_CE for concurrent employment scenarios).This report corresponds to older previous version of RPCIPE00, before the changes for New General Ledger Accounting. Therefore the functionality of this report corresponds only to the setting 0 (no distribution of liabilities according to expenses) in the table T52SWCODIST.
2. Too much data stored in posting tables. Cleanup and archiving.
It is common that when a performance problem is experienced in the posting, it is related to the high growth and size of posting tables like PPOIX / PPOPX. This usually happens because many simulation posting runs are created and never deleted. So it is much recommended to regularly delete the simulation posting runs, as soon as they are no longer needed. In the case of PPOIX table, it will have an entry for each personnel number, individual wage type and period posted. The estimation of growth per year of this kind of tables is also quite big, and frequent simulation runs or many large retrocalculations will affect the table size very quickly. Please refer also to note 119865 for further information under the section Questions about the technical implementation.
The solution would be, as already mentioned, to delete the data of simulation runs.
RPCIPQ00 can be used, if the requirement is to delete the index information, except the header data which consumes a little amount of space. Directly deleting the posting runs in PCP0 transaction will not actually remove the content of these runs, but sets them with “deleted” status. This can be later checked by RPCIPQ00 for removal. The data from PCP0 transaction (corresponding to PEVST and PEVSH tables) will not be deleted at anytime. Also report RPCIPDEL can be used to reorganize and reduce size of PPOIX and PPOPX tables. There are some differences between these reports:
RPCIPDEL
- Deletes Simulation runs (irrespective of the run status)
- Sets the status of the posting run to ‘Deleted’
- Removes the PCALAC stamp (PCALAC is a table in the payroll cluster which links the payroll result to a posting run) and PPOIX and PPOPX entries
- Does not delete the HR posting documents
- Does not delete the PPOIX entries of productive Posting runs
RPCIPQ00
- Deletes Simulation runs (irrespective of the run status)
- Deletes productive posting runs which have not been posted
- Deletes the HR posting documents and the PPOIX entries for Productive payroll runs that have the status ‘Deleted’ (from RPCIPDEL)
- Does not delete dependent runs through retrocalculation
- Does not delete Productive posting runs which have been successfully posted to the Accounting system or transferred via ALE
Deletion of already accounted productive runs which are already transferred to FI/CO is not possible. Refer to the documentation of these two reports for extended information. Another solution for removing data of old results consists in archiving them, but this is only advisable for results where no payroll and posting of payroll results will take place anymore. Please consider possible legal or revision requirements. If archiving is an option for some posting results, you can refer to note 25622.
3. Posting log activated for many employees.
The detailed log is not designed to be used for multiple employee selections, but only for individual cases which might need to be reviewed in detail. This is a condition valid for the payroll posting, but can also be extended to any other evaluation report in HCM. To avoid any potential issues and to keep overall performance, execute the posting report with no log activated. In case the log option was chosen by mistake, a memory dump like TSV_TNEW_PAGE_ALLOC_FAILED will be issued because there is not enough memory to store all the log information. There can be also other types of performance dumps related to this fact.
4. Massive generation of error messages in the log.
Even if the output log of the posting was not selected, anytime an error message linked to employee data appears, this error will be logged and sent to the log. This is something intended and useful in order to quickly determine potential issues with specific employees or payroll results. Yet it could happen, that the posting is ran and that some general error is happening to certain groups of employees, and that message is then stored in the log causing memory issues, and therefore performance problems.
In this case check if notes 1466074 and 1589752 are implemented, and please refer also to wiki page http://wiki.sdn.sap.com/wiki/x/_YkqCw
As a recommendation to identify if this is what happens, for an ongoing job which keeps running in background:
1) you can check that the variant with which the posting program was ran has the log deactivated (if the log is active in the variant, then proceed to previous point 3 in this guide)
2) you can check that the background job of the posting program is consuming most of the NET time in calls to FUNCTION RPY_MESSAGE_COMPOSE and/or SELECT SINGLE T100. This code corresponds to the code which recovers and creates output messages.
This code can be observed from a few minutes trace, which can be created from ST12 transaction for the ongoing job.
Once identified, in order to find out the type of message appearing massively in the job, a method could be to run a simulation posting run without the log for a few employees and see if there is any unexpected message there. But as some messages appear only during the productive run, this option might not cover all the possible scenarios. In those cases the alternative would be to wait for the end of the massive job, or try with a smaller productive run.
5. Payroll period contains massive retroactivity forced through payroll
There can be special situations where it is required to run a retroactive payroll globally for all employees. Sometimes this kind of massive forced retroactivities are covering a complete recalculation since the beginning of the year (a long retro chain), for example due to some legal regulations or fixes. Of course this kind of payroll runs will have an important impact on the posting process, as each single month will need to be processed individually.
Best practices like reducing the amount of data proactively for the posting tables ppoix / ppopx might be helpful to gain a better performance in these situations, as logically the runtime will be increased for payroll periods with a long retroactivity chain. Still it is recommended to review the other points described in this article for further performance optimizations.
6. Parallelization in RPCIPE01
This feature was added to RPCIPE01 with note 1079153. Further explanation of setting up a run variant in table view V_T52E_ARFC can be found in note 1699381 under chapter 6.
This point would be specially relevant if dump EXPORT_TOO_MUCH_DATA is received in RPCIPE01.
Running RPCIPE01 in parallel mode helps to increase overall performance. The recommendation here is to test this option with different configurations in view V_T52E_ARFC. There is extended documentation in the F1 help of “Run Variant” field in RPCIPE01. A general advice for the run variant parameters cannot be given here because this has to be tested depending on the system resources. It is important to know that both the dialog work processing time (parameter rdisp/max_wprun_time) and the set size of PERNRs in correspondence with the number of tasks are relevant here for parallel aRFC task processing. It has to be considered for a posting run that, in order to be able to run a parallel task within the dialog runtime all conditions have to be met, specially retrocalculations.
Example: If you have set up the default setting of parameter rdisp/max_wprun_time to 600 seconds and you have a posting run with extensive retrocalculations, then it must be still possible to finish it within dialog processing time. So the set size of PERNRs would have to be set in a lower size, e.g. 50 or 100 PERNRs. Also it has to be taken into account that the number of tasks should fit to the system setup of dialog processes.
The parallelization setup might take some time until it is accurately configured regarding the optimal configuration in correspondence to specific system resources. Testing and evaluation of these settings are recommended before its final use.
7. Relevant SAP standard corrections missing
As a general rule, it is recommended that you have the latest corrections available for the corresponding posting report being used. For report RPCIPE00, ensure that you have applied note 1801744 which adds an important performance improvement. Other important note with high impact in the performance of posting is for example note 1749877 (which adds performance corrections affecting the payroll results retrieval).
It is recommended that you keep the system as synchronized as possible regarding performance notes, for example you can search for latest notes in PY-XX-DT* area using “performance” as a search term. Or, in a more automatic way, you could find out relevant notes using the Automated Note Search tool (more information in KBA 1818192).
8. Performance and summarization. Potential impact of customer User-Exit 002.
The summarization is an important process which allows to reduce the amount of lines, therefore having a positive impact on performance. More details are available in note 760900. Basically, no line item will be created if the total amount of the summarized line items is 0, since a posting with an amount of 0 is not necessary to be posted as the total of the affected account has not changed.
If amounts summarize to zero they will not be part of the documents. It does not mean they have not been evaluated as it can be seen checking the posting records with help of report RPCIP_SUPPORT. Also the corresponding revision information can be checked in transaction PCP0 or via analysis report like RPCIP_DOCUMENT_ANALYSE. Posting functionality is a mass data process for creation of posting documents and performance loss and memory consumption can raise significantly if zero line items would not offset each other.
Taking this into consideration, obviously any action which avoids the standard summarization, will have a negative impact on performance. For example, two possible reasons for a summarization not carried out could be:
- User exit 002 (method EXIT_RPCIPE00_002 of BAdI SMOD_PCPO0001) is used to store data in fields SGTXT or ZUONR. If the PERNR is stored in these fields, then the summarization would only be achieved at employee level, because data from line items of different employees will remain differentiated in the collection process).
- With the alternative of note 1629094 or 1624843 activated, summarization could have been also prevented to fulfill reporting requirements. This can also have longer runtimes and higher memory consumption.
9. Document splitting active in Finance
In correspondence to HR posting rule based splitting must not be activated as it can have negative impact in performance in New GL and can cause memory dumps (TSV_TNEW_PAGE_ALLOC_FAILED).
Please refer to question 12 of note 1039346 for further details.
10. Elimination of zero amount line items avoided by customizing of note 1624843
From default standard behavior, and due to efficiency reasons, records which will not result in a line item in the FI/CO posting document are removed from the final document (zero amount line items are removed).
Since note 1624843, it is given the possibility for customers to make RPCIPE01 (RPCIPE01CE for concurrent employment) ignore the elimination of zero amount line items, through described customizing constant ZPOST/ZZERO in T77S0. If this prevention is activated, it will for sure cause higher runtime and bigger consumption of resources which will depend on system hardware settings and size/complexity of the payroll and posting document. Therefore, if performance problems appear during payroll posting, there is a big possibility it is coming from the impact from these additional line items. Returning to standard default behavior is highly recommended in these cases (please check description of mentioned note for more details).