- SAP Managed Tags:
This blog describes the implementation design principle document on managing pensioners in Employee Central.
SuccessFactors Employee Central is the Core HR module that is usually the system of record for many downstream systems such as payroll. Employee Central holds data of active employees as well as pensioners of an organization. While most transactions in EC pertain to active employees, some transactions need to be performed on pensioners. These changes also need to be replicated to downstream systems for further processing.
Persons who have worked as a regular employee for several years and has retired from their occupation are called as a pensioner. The pensioner in certain companies get payments called pension from the day of retirement. This blog focuses on how pensioners can be managed in Employee Central specifically for those who get a pension from the company.(The focus is not for pensioners getting paid from the government).
The details of the solution for are mentioned in the implementation design principle document. Link at the end of this blog.
There are two possibilities with respect to the Employee Central core. Customers can decide if they want to create new employment or retain the same employment.
Typically rehire is performed on the same employment .
There are two use cases for a new employment for a retiree. In certain countries, it is necessary to create a new employment to make sure that the privacy laws are adhered to. In such scenarios, a new employment is created for such employees. The advantage of creating new employment (New PERNR) is that the admin cannot see the previous work history of the pensioner though the history user interface of the job information portlet.
There could be scenarios where retirees/pensioners return to work at the same company as a separate employment. This could be returning to work as a Contractor (Contingent Worker) or in a different job role. If the employee returns to work in a different job role, they should be hired into EC with new employment. This will provide the ability to run a regular payroll for the new employment while the pension payments can be processed on the previous employment that has been retired/terminated.
In dealing with pensioner it is important to know the different employee status in Employee Central. For each Employee Central status, the corresponding user status for Employee Profile is shown in the table below.
Before the event reasons are mapped to actions in ERP, it is necessary to know the status available for Employees.
There are 3 status indicators in ERP. The customer-defined status(STAT1), Employment status(STAT2), and the special payment status(STAT3). The below table shows the values and the description. Typically payroll considers the employees in status (Inactive, Retiree, Active). Payroll only considers the employee in withdrawn status if a date is defined in infotype 3 – field “Run Payroll up to“ (ABWD1).
Though all the 3 statuses could influence the payroll, we could focus on Employment status (STAT2).
The Event reason in Employee central is mapped to the actions in ERP. The employee status in Employee Central is set by the event reason configuration and similarly, in ERP the Action (not the Action Reason) sets the employment status of the employee in ERP
The below table shows the recommended mapping between EC and ERP to handle the retiree.
Note that if there is a beneficiary/ Survivor who continues to get the pension after the death of the retiree that person should be hired as a survivor.
The implementation deign principle document has more details on
Where are the SAP Successfactors implementation principle documents published?
SuccessFactors Employee Central is the Core HR module that is usually the system of record for many downstream systems such as payroll. Employee Central holds data of active employees as well as pensioners of an organization. While most transactions in EC pertain to active employees, some transactions need to be performed on pensioners. These changes also need to be replicated to downstream systems for further processing.
Persons who have worked as a regular employee for several years and has retired from their occupation are called as a pensioner. The pensioner in certain companies get payments called pension from the day of retirement. This blog focuses on how pensioners can be managed in Employee Central specifically for those who get a pension from the company.(The focus is not for pensioners getting paid from the government).
What are the typical requirements of maintain a pensioner?
- Handling Position and cost center
- Handling death of a Pensioner
- Handling Survivors /Beneficiaries
- Maintaining Address
- Maintaining Bank Information
- Maintaining Personnel Information
- Maintaining changes to payments for pensioners
- Where are the SFIDPs published?
The details of the solution for are mentioned in the implementation design principle document. Link at the end of this blog.
Solution details
There are two possibilities with respect to the Employee Central core. Customers can decide if they want to create new employment or retain the same employment.
Typically rehire is performed on the same employment .
There are two use cases for a new employment for a retiree. In certain countries, it is necessary to create a new employment to make sure that the privacy laws are adhered to. In such scenarios, a new employment is created for such employees. The advantage of creating new employment (New PERNR) is that the admin cannot see the previous work history of the pensioner though the history user interface of the job information portlet.
There could be scenarios where retirees/pensioners return to work at the same company as a separate employment. This could be returning to work as a Contractor (Contingent Worker) or in a different job role. If the employee returns to work in a different job role, they should be hired into EC with new employment. This will provide the ability to run a regular payroll for the new employment while the pension payments can be processed on the previous employment that has been retired/terminated.
Employment Status and Mapping of Event reasons with that of ERP actions
In dealing with pensioner it is important to know the different employee status in Employee Central. For each Employee Central status, the corresponding user status for Employee Profile is shown in the table below.
| Employee Profile /User Status | Active user |
| Employee Central Status | Active |
| Suspended | |
| Dormant | |
| Paid leave | |
| Unpaid Leave |
| Employee Profile /User Status | Inactive user |
| Employee Central Status | Discarded |
| Furlough | |
| Retiree | |
| Terminated | |
Before the event reasons are mapped to actions in ERP, it is necessary to know the status available for Employees.
ERP STATUS
There are 3 status indicators in ERP. The customer-defined status(STAT1), Employment status(STAT2), and the special payment status(STAT3). The below table shows the values and the description. Typically payroll considers the employees in status (Inactive, Retiree, Active). Payroll only considers the employee in withdrawn status if a date is defined in infotype 3 – field “Run Payroll up to“ (ABWD1).
Though all the 3 statuses could influence the payroll, we could focus on Employment status (STAT2).
| Status Code | Status Description |
| 0 | Withdrawn |
| 1 | Inactive |
| 2 | Retiree |
| 3 | Active |
The Event reason in Employee central is mapped to the actions in ERP. The employee status in Employee Central is set by the event reason configuration and similarly, in ERP the Action (not the Action Reason) sets the employment status of the employee in ERP
The below table shows the recommended mapping between EC and ERP to handle the retiree.
| EC Event Reason | EC Event | Employee Status EC | SAP ERP Action Type | ERP Action Reason | Employee Status ERP |
| 1000-Regular Termination | Termination | Terminated | 10 - Leaving | 01-Voluntary | 0 – Withdrawn |
| 2000-Retirement with no Pension | Termination | Retiree | 10 - Leaving | 02- regular retirement | 0 – Withdrawn |
| 2001-Retirement with Pension payment through PY | Termination | Retiree | 14 - Retirement | 03-retired with pension | 2 – Retiree |
| 3000-Death after Retirement | Termination | Terminated | 10 – Leaving | 04- Death | 0 – Withdrawn |
3500 Death after Retirement With survivor | Data Change | Terminated | 10 - Leaving | 05- Death with company pension survivor | 0- Withdrawn * |
| 1100 Hire as Pensioner(New employment use case) | Hire | Retired | 11-Hiring of Pensioner | 02- Hired as a retiree | 2 – Retiree |
Note that if there is a beneficiary/ Survivor who continues to get the pension after the death of the retiree that person should be hired as a survivor.
Document Details
The implementation deign principle document has more details on
- Mapping of Event reasons in Employee central to Employee Central Payroll actions
- Handling Partial Retirement (Germany-Altersteilzeit)
Link to the Implementation principle document
Where are the SAP Successfactors implementation principle documents published?
- Customer Community
- Please check the above link for many other
20 Comments
| User | Count |
|---|---|
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
