Hi Successfolks!
I hope you are having a good time implementing, supporting Successfactors.
I will keep this blog post short and simple.
Introduction: The customer has implemented Employee Central with Employee Central Payroll for managing HR master data and processing payroll for around 240K employees. They have a considerably high volume of HR transactions like Mass Hiring, Rehiring and Termination.
Background: Payment information portlet in Employee Central stores the main bank information and other payment-related information for the employee. The data maintained in this portlet gets replicated to the Employee Central payroll system in the infotype 0009 as part of the employee master data. This infotype is very critical for payroll processing. In E People Profile, the payment information portlet is not mandatory information to be maintained while Hiring/Rehiring employees. As the customer processes several hundreds of hiring actions in a day, it's not uncommon that on some occasions, the payment information is skipped and the hiring process gets completed. The new employee information then gets replicated to the Employee Central Payroll system with the infotype 0009 information which causes severe impact to the payroll processing resulting in the non-payment for such employees.
Our first choice was to perform the validation at the source Employee Central data-model using business rules to avoid data inconsistency during the hiring/rehiring process. However, we stumbled upon a technical limitation where payment information portlet cannot be set mandatory during the hiring/rehiring process. The KBA-https://launchpad.support.sap.com/#/notes/2488404 mentions this technical limitation. There is an enhancement request as well but currently, there is no clarity on the roadmap.
Workaround: To handle this situation we considered a couple of options:
We considered Payroll Control Central validation checks as a long term solution as the PCC implementation is pretty complex and the customer is on a tight schedule. This will definitely be a beautiful solution for the payroll administrators to check the master data inconsistencies.
The second option to handle this in the BADI was an easy win and was vetted by the customer as well as an immediate solution.
We choose the BADI HRSFEC_B_CE_PROCESS_ET as this BADI implementation will be called every time the replication job is run in Employee Central Payroll. The implementation of the BADI was pretty straight forward.
We choose the method- if_hrsfec_ce_process_et~process_employment_addin to hook our code for checking Employee Central xml incoming payload for the payment_information portlet. If there was no data in the xml tag, we simply raise an error and it to the standard message handler. This will fail the replication of the employee data in Employee Central Payroll and update the system log (SLG1) with the error message.
Below is an example of how to raise the error message in case of empty payment information:
Error snapshot from the system log after implementation of the BADI and replicating:
When system administrators, see this error in the Data Replication Monitor, the responsible HR team is notified to add the payment information in Employee Central so that it can be replicated correctly.
Future Scope: Future scope of this enhancement can automating the sending of error log periodically using email notifications for proactive monitoring or errored replications to HR transactions team directly. This can be done by a scheduled ABAP report.
I would like to give absolute credits to our technical team members Mithun Manik Naik and Santosh Kumar Parashivamurthy and functional consultant Pedro Collantes for their efforts on developing and testing this enhancement. I hope this is useful for you and help with similar requirements.
Thanks and regards,
Soumyajit
I hope you are having a good time implementing, supporting Successfactors.
I will keep this blog post short and simple.
Introduction: The customer has implemented Employee Central with Employee Central Payroll for managing HR master data and processing payroll for around 240K employees. They have a considerably high volume of HR transactions like Mass Hiring, Rehiring and Termination.
Background: Payment information portlet in Employee Central stores the main bank information and other payment-related information for the employee. The data maintained in this portlet gets replicated to the Employee Central payroll system in the infotype 0009 as part of the employee master data. This infotype is very critical for payroll processing. In E People Profile, the payment information portlet is not mandatory information to be maintained while Hiring/Rehiring employees. As the customer processes several hundreds of hiring actions in a day, it's not uncommon that on some occasions, the payment information is skipped and the hiring process gets completed. The new employee information then gets replicated to the Employee Central Payroll system with the infotype 0009 information which causes severe impact to the payroll processing resulting in the non-payment for such employees.
Our first choice was to perform the validation at the source Employee Central data-model using business rules to avoid data inconsistency during the hiring/rehiring process. However, we stumbled upon a technical limitation where payment information portlet cannot be set mandatory during the hiring/rehiring process. The KBA-https://launchpad.support.sap.com/#/notes/2488404 mentions this technical limitation. There is an enhancement request as well but currently, there is no clarity on the roadmap.
Workaround: To handle this situation we considered a couple of options:
- Implement standard checks in Payroll Control Center and use the payroll control center to show the bank information related errors to the payroll administrators.
- Hook a validation logic in one of the BADIs provided in the Employee Central -P2P replication enhancement spot- HRSFEC_CE_MASTER_DATA_REPL.
- Use a workflow step for validating payment information while hiring. (Not feasible in this case because of the volume of hiring transactions)
We considered Payroll Control Central validation checks as a long term solution as the PCC implementation is pretty complex and the customer is on a tight schedule. This will definitely be a beautiful solution for the payroll administrators to check the master data inconsistencies.
The second option to handle this in the BADI was an easy win and was vetted by the customer as well as an immediate solution.
We choose the BADI HRSFEC_B_CE_PROCESS_ET as this BADI implementation will be called every time the replication job is run in Employee Central Payroll. The implementation of the BADI was pretty straight forward.
We choose the method- if_hrsfec_ce_process_et~process_employment_addin to hook our code for checking Employee Central xml incoming payload for the payment_information portlet. If there was no data in the xml tag, we simply raise an error and it to the standard message handler. This will fail the replication of the employee data in Employee Central Payroll and update the system log (SLG1) with the error message.
Below is an example of how to raise the error message in case of empty payment information:
Error snapshot from the system log after implementation of the BADI and replicating:
When system administrators, see this error in the Data Replication Monitor, the responsible HR team is notified to add the payment information in Employee Central so that it can be replicated correctly.
Future Scope: Future scope of this enhancement can automating the sending of error log periodically using email notifications for proactive monitoring or errored replications to HR transactions team directly. This can be done by a scheduled ABAP report.
I would like to give absolute credits to our technical team members Mithun Manik Naik and Santosh Kumar Parashivamurthy and functional consultant Pedro Collantes for their efforts on developing and testing this enhancement. I hope this is useful for you and help with similar requirements.
Thanks and regards,
Soumyajit
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
