Once I was in a customer performing an optimization service for HCM when the following case was brought to my attention. The project was in the middle of integration tests.
The first executions of the payroll posting to FI (RPCIPE00) took around 30 minutes for payroll area with 21,000 employees. A later execution for other payroll area with a similar volume took 18 hours before being cancelled. Since the customer wanted to run a full simulation at each payroll cycle, this response time was unacceptable.
The first troubleshooting step was to make sure that the log was disabled, which is the recommended procedure when executing the posting for a large population.
In the next step the job was executed and several traces were collected using transaction ST12 (ABAP Trace). The following partial trace shows that in 117 seconds, 26 employees were selected (perform PUT_GROUP) but 19 were rejected (perform REJECTION). Over 90% of the time is spent building the log (method PROCESS_LOG, class CL_HRPAY99_POSTING_LOG):
Tests with a small subset of employees from that area showed a high amount of employees with errors, creating a large log that was decreasing the runtime
As mentioned before, it is recommended not selecting the “Output log” option when executing the posting for a large population. However, if most employees have errors, there will be performance degradation. The customer fixed the master data errors and the job could be finally executed.