Payroll Control Center and PA03 Conundrum
Payroll Control Center has simplified the processing of payroll by shifting from transaction based payroll process to a nice intuitive UI5 screen which guides the users through the whole process.
I have been part of quite a few PCC demos , prototypes and productive implementation. The payroll users are very happy to see the new screen and more excited with the validation of the payroll results with the pre defined validation rules and alerts coming up for employees who fail the validation rules .
For employees captured in the alerts, the payroll admin can correct the master data of the employees without worrying about changing the control record status as the system ignores the control record checks for all the employees who are part of the PCC alerts.
But then there is a feeling of uneasiness among the users when there is a change needed for some employees who aren’t part of the alerts and the users have to go to PA03(payroll control record), change the status , proceed with changing the master data and then again reset the status back in PA03 before running the payroll again via PCC.
This acts sometimes as a minor deterrent if not a showstopper to an otherwise wholesome user experience when processing the payroll via PCC.
In my blog below, I will be sharing with you a simple solution/workaround that can be done in the system which can ensure that users don’t have to navigate to PA03 and can stay in the PCC screen for most of the scenarios till they complete the payroll process.
Important note :
As per the PCC process designed, a monitoring process has to be part of every month payroll wherein all the necessary validations are executed on both PA and PY data in the payroll system . All the issues have to be identified and corrected in the monitoring stage, The workaround that i am proposing is for a few cases that might popup during the productive payroll process and the steps to handle them in a easier way.
For the scenarios below, i have assumed a landscape where there is EC system connected to Employee Central Payroll (ECPY) system.
PCC Processing Steps:
- Start Payroll step ensures that mater data are locked and sets the payroll control record status to ‘Released for Payroll’
- Run Payroll runs the respective payroll as per the variant configured
- Initiate Policies section runs the pre defined validations rules as per the policies assigned to the payroll process
- Employees who fail the pre defined rules are captured in the Alerts section and the payroll manager assigns the employees to the payroll admin for analysis
- The payroll admin analyses the issue for every employee and directly does the necessary adjustment either in EC or ECPY system.
- The ECPY system allows the correction to happen for master data employees who are part of Alerts section even though the control record is in ‘Released for Payroll’ status
The standard logic of ECPY system to skip PA03 checks are as below
- When payroll relevant infotype is being saved, the ECPY system checks if the employee being processed has been captured in the PCC alert database tables.
- If yes, then the system checks if the logged in user correcting the master data is the same user mentioned as the processor of the alert in the PCC alert database table.
- If yes, then the ECPY skips the PA03 checks and allows the infotype changes to be saved
- If no, the system checks if the logged in user correcting the master data of the employee is one of the users maintained in the User List section of the PCC admin setup (program- PYC_ADMIN_TRANSACTION)–refer Image below
- If yes, then ECPY system skips the PA03 checks and allows the infotype changes to be saved
- If there are employees who are not part of the alert but needs some master data changes, then the ECPY system invokes PA03 checks and prevents updation of any master data of the employee
If more details are needed, you can check the class- CL_PYC_PCC_MDF_CHECKER where this logic is implemented and this class is called in IT0003 logic.
Custom Validation rule:
You can make a copy of one of the existing validation classes and redefine the ‘CHECK’ method.
You can implement the logic as below
- From the importing parameter IT_PAR, derive the payroll area and also the payroll period of the current process.
- Based on the periods, loop through the declustered payroll results and collect all the employees for whom payroll was run
- Update the exporting parameter RT_RESULT with the all the employees derived in the previous step
You can create a validation rule with the above validation classes and then assign the validation rule to the Policies assigned to the existing PCC process.
This will ensure that all the employees for whom payroll was run are part of the PCC alerts database.
Maintain User list:
When maintaining the user list as part of the PCC admin setup , kindly ensure the following
- Mention only payroll admin ids
- The payroll admins can correct the employee master data in EC and then execute the replication program manually for the affected employees with their userids.
- Do not have the replication program technical user id mentioned
- If we mention, then the replication program would start replicating the data of all employees as all employees are part of alerts and this would end in inconsistencies
When creating the custom validation rule , also ensure that you also have the employee payslip(pdf) configured in the Root Cause Analysis section (PCC configuration workbench). The employee Payslip PDF logic is delivered by standard as part of RDS package .
In many organizations, its common practice that payroll managers/admins randomly check few payslips before they start the detailed reconciliation. In such scenarios, having the PDF Payslips in the alert section enables the payroll manager/admin to access any employee’s payslip for checking within the PCC process
Enhancing the Solutions section in PCC:
The PCC should enable the payroll admins to navigate to the respective infotypes or the respective portlets in EC.
There is a blog available which mentions URL to navigate to the particular portlet in Employee central.
We can define the necessary Solution variables and provide the link to navigate to comp portlet or job or employment information portlet. A sample URL to navigate to SFSF is given below.
https://<EC URL>/sf/liveprofile#mobileViewBlock/<EC employee id>/<portlet block_no>
Similarly a link can also be provided to replicate employee from EC to ECPY. A sample URL is given below wherein the config id and the employee id can be defaulted in the selection of the replication program
https:<system_url>/sap/bc/gui/sap/its/webgui?~TRANSACTION=HRSFEC_PTP_EE_REPL p_extid2=<EC employee id>;p_confid=<CONFIG-ID>
Execution of production payroll:
Once the above steps are completed, production payroll process can be started and the live payroll can be performed. Once Initiate policies is executed, the custom validation rule will ensure that all employees are part of the alerts.
During reconciliation, if there are few employees whose data has to be corrected, the payroll admins can directly navigate to either EC or ECPY from the Solutions section and do the necessary corrections without worrying about PA03 status.
Once change are done, they can also navigate to the replication program from Solutions section and just press the execute button as config id and the respective employee would have already been prefilled.
Once the Reconciliation is completed, the status of all the employees can be set to resolved and payroll for the month can be ended.
The ideal objective of PCC is to ensure adequate pre-defined rules to capture all possible issues coming out of reconciliations. But in the real world, there would be some validations for which we wont be able to build the rules. In such scenarios, the option above would help the users to focus more on correcting and replicating the data instead of worrying about the status of PA03.
If there is a different way of handling the above scenario, kindly mention the same in the comments section.
Note :There is a exciting feature for PCC in Q2 2021 as per the roadmap and kindly stay tuned for Q2 2021 🙂
Thank you ,
Great job Jose
Nice article Jose as this reduces the end users effort to toggle screens.
Nice Article, can you update on odata api
Good work Jose !
Meticulous and effective Jose.
Superb Jose, really a wonderful workaround. Having working in ECP gives us a lot of flexibility in the day to day to usage of the system. Thanks a lot for sharing this block. I am pretty much sure, I can use it to the maximum effect as I already lot of use cases, where they waned to modify the Master data without having them in the Alerts and without disturbing the Payroll Control Record. Now I a got a fantastic solution through you.
Just a quick question, we have implemented PCC at a client but not EC or ECPY, how do you fix the alerts and errors in the monitoring step and or productive payroll step?
PCC developments and configurations resides in the payroll system --this could be your on premise or ECPY system.
Fixing alerts and errors have to be done from the Alert Management tool.
The easiest way to get the links is to navigate to SICF transaction -- sap-->bc-->ui5_ui5-->hrpy_pcc_errm_2
Right click and once you press test service--you will get the full URL for alerts and management screen.
Thank you for your reply, I get that I must go to alerts and management screen, but how do I fix an alert without navigating to PA30 in ECC and without having to change the payroll control record (PA03)
I misunderstood your initial question then 🙂
If there is an alert captured for an employee which requires change in IT0008 or IT0014 or any payroll related infotype---you can provide the link for the necessary infotype action for the employee via the Solutions section.
You will have to navigate to PA30 to change the data of an employee via the solution section if at all any data changes are required.
The behaviour is that since the employee has been recorded as part of the alert, the check on PA03 is skipped when you change data via PA30 for a payroll related infotype.
Via PCC, you need not change the PA03 setting before you update PA30 for the affected employee alone.
So you will have to navigate to PA30 via the solutions or otherwise for the affected employees(captured in alert) but you need not perform PA03 reset.
Also note that if you dont want to perform any actions on infotype--you can just press on Resolve button in Alerts screen and that would fix the corresponding alerts.
Thank you so much, now I understand the process🙂