BREAK dungbv7.

1. Payroll posting in a nutshell

For those who didn't know yet, Payroll posting is a part of the payroll process in SAP HCM. That is after the remuneration is finalized, the salary of all employees will be summed up according to the nature of each item and then packaged into a finance document in the SAP FI system.

Basically, employees' payroll results will be evaluated by 2 factors: wage type (the code represents the type of salary expense) and the employee group (the code represents the group of employees to be paid). These 2 elements are mapped to a G/L account (general ledger account) of the FI document.

If there is one thing that special about payroll posting, it must be the retroactive mechanism. You can click here to read my previous detailed explanation about payroll retroactive calculation.

Now let's take a look at the example below, I have an employee's February 2023 payroll with a retroactive amount of 5 million because he gets a raise in basic salary of January 2023 (backdate increment).

When I run the Payroll posting program for February 2023, the system will perform the following operations in turn:

• Reverse the old version of payroll Jan 2023:

  

• Post a new version of payroll Jan 2023:

  

• Finally, Post the current version of payroll 02/2023 (here you should notice that wage type 1R01 is not selected for accounting)

  

Adding all the Payable amounts, we will see that the Net Salary is 21.600.000 which matches the Payout amount on the remuneration sheet of February 2023.

2. The downside of Retroactive posting

Personally, I think this retro accounting feature of SAP is pretty cool designed, as it ensures that the cost increases or decreases resulting from past payrolls are accounted exactly for the Cost Centers/Businesses Areas/Funds/… in those payroll sheets.

However, when it comes to practical use, most of my customers struggle with this design, because when the retroactive event goes far into the past, most of the time those Cost Centers in the old Payroll results have been deactivated and then they cause errors when the system generates FI document.

If all the Cost Centers are valid at the posting date, the customer still faces another crucial problem. That is the expense posted from Payroll results does not balance with the expense that the Company payout for employees through bank transfer.

3. How to get away with Retroactive posting

After a lot of meetings and persuasions, my customers still reject to follow the standard designation of Retroactive posting, one day I finally give up and then start to find a way to enhance the posting feature.

Here are all of the steps I took in my research:

First, I take a look at the posting program (RPCIPE00) and find out the main object to be used is the class CL_HRPAY99_POSTING_ENGINE_PP.

This class refers to the parent class named CL_HRPAY99_POSTING_ENGINE.

I found 2 crucial methods inside the class CL_HRPAY99_POSTING_ENGINE that in charge of handling posting data:

• GET_LINES_TO_BE_POSTED: this method is used to scan over the RT table and then determine whether each wage type can be posted or not.

• REVERSE_POSTING_ITEMS: this method is used to query the PPOIX table (contains the last posting data) and then create a reversal version of those data in this posting run.

I created one enhancement for each method above.

The first one is right at the start of REVERSE_POSTING_ITEMS, I just simply don't let it proceed :D

The second one is a little bit more complicated, I put it at the beginning of GET_POSTING_LINES.

Because I deactivated the reversal feature, so I must add some adjustments in the RT results before posting, to make sure that the Payroll result will match the Payout amount in the Remuneration sheet.

Now all the problems I encountered have been resolved. My customers are happy and I'm finally able to take a sigh of relief.

Ok I guess this is the end. Hopefully this post can give you guys something useful, thanks for reading and see you again soon.

May the best solution be with you!