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.
PCC screen and PA03 screen
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.
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
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 🙂