Introduction
In SAP SuccessFactors Employee Central Time Management you can choose the accruals on your time accounts to be "entitled as accrued" or "entitled as transferred". "Entitled as accrued" means that once accruals are posted to the time account, they can be consumed. "Entitled as transferred", instead, means that accruals can only be consumed once they have been transferred into an entitlement. Typical use case for the latter is Long Service Leave (LSL) in Australia. LSL is typically accrued on a daily basis. However, the initial transfer from accruals into entitlements takes place only after for example 10 years of service and thereafter every additional year of service. However, there are many customers who, after the initial waiting period of 10 or so years, transfer accruals even on a daily basis. Now, if you are initially migrating your time management to SAP SuccessFactors Employee Central Time Management, you need to determine for each employee when the next transfer will take place. In case of long-standing employees, who have already been with the company for longer than the initial transfer waiting period, and daily accrual transfer configurations you might run into issues during your migration. This blog post will address those issues and come up with a solution proposal.
Background Information
To determine the accrual transfer dates there are two relevant rule scenarios:
(1) Initial Accrual Transfer Date rule: this rule determines the initial next transfer date on a time account. For example, it could set the next transfer date to hire date + 10 years if you want the first entitlement to be generated after 10 years of service. This rule is called during account creation.
(2) Accrual Transfer Date rule: this rule determines the following transfer dates after the initial transfer date. For example, it could set the next transfer date on a yearly, monthly, or daily basis. This rule is called during the entitlement calendar run.
Example:
An employee is hired on 1 Jan, 2021. During hire, time information is assigned. As a consequence of this, the time account is created and the initial accrual transfer date rule, which sets the next transfer date to 1 Jan, 2028, is called. On 1 Jan, 2028 the entitlement calendar will run and generate an entitlement for 1 Jan, 2028. Furthermore, during the entitlement calendar run the accrual transfer date rule, which sets the new next transfer date to 1 Jan, 2029 (in case of yearly transfers), is called.
Problem Description
Let's assume the following: The initial transfer is supposed to happen after 10 years of service, thereafter accrual transfers happen on a daily basis. Hence, your rules might look something like this:
Initial Accrual Transfer Date Rule:
Accrual Transfer Date Rule:
One of your employees started to work for your company on 1 Jan, 1992. Now you migrate to SAP SuccessFactors Employee Central Time Management as of 1 Oct, 2020. You assign the time information to the employee and the initial accrual transfer date rule is called. The rule sets the next transfer date to 1 Jan, 2002. The next transfer date is not up to date as it lies in the past. You would first need to run the entitlement calendar which would need to generate (unnecessary) entitlements from 1 Jan, 2002 till today - for every day. As a result, the next transfer date would then be 1 Oct, 2020. However, as a by-product you already start off with 6848 entitlements on the time account. And now let's assume you do not only have one employee with a next transfer date in the past, but multiple ones. The first entitlement calendar that runs needs to process the complete data load which often leads to performance issues disrupting your go live.
Solution Proposal
To avoid this issue, you can set up your initial accrual transfer date rule for the time of the migration as follows:
This way, you make sure that you do not start off with next transfer dates that lie before the go live date. Instead of putting a fixed date (here: 1 Oct, 2020 = Go Live Date), you can also refer to some custom date field or today() - depending on what fits your needs best.
Once the migration process is complete, you can change the initial accrual transfer date rule.
Conclusion
In this blog post you have learnt how to deal with daily accrual transfer configurations during the initial data setup. By applying this approach you get a much cleaner data situation on your time accounts and avoid performance issues. Overall, it leads to a smoother go live.
The solution proposal might be amended as per your individual needs.
Looking forward to your thoughts and comments.
In SAP SuccessFactors Employee Central Time Management you can choose the accruals on your time accounts to be "entitled as accrued" or "entitled as transferred". "Entitled as accrued" means that once accruals are posted to the time account, they can be consumed. "Entitled as transferred", instead, means that accruals can only be consumed once they have been transferred into an entitlement. Typical use case for the latter is Long Service Leave (LSL) in Australia. LSL is typically accrued on a daily basis. However, the initial transfer from accruals into entitlements takes place only after for example 10 years of service and thereafter every additional year of service. However, there are many customers who, after the initial waiting period of 10 or so years, transfer accruals even on a daily basis. Now, if you are initially migrating your time management to SAP SuccessFactors Employee Central Time Management, you need to determine for each employee when the next transfer will take place. In case of long-standing employees, who have already been with the company for longer than the initial transfer waiting period, and daily accrual transfer configurations you might run into issues during your migration. This blog post will address those issues and come up with a solution proposal.
Background Information
To determine the accrual transfer dates there are two relevant rule scenarios:
(1) Initial Accrual Transfer Date rule: this rule determines the initial next transfer date on a time account. For example, it could set the next transfer date to hire date + 10 years if you want the first entitlement to be generated after 10 years of service. This rule is called during account creation.
(2) Accrual Transfer Date rule: this rule determines the following transfer dates after the initial transfer date. For example, it could set the next transfer date on a yearly, monthly, or daily basis. This rule is called during the entitlement calendar run.
Example:
An employee is hired on 1 Jan, 2021. During hire, time information is assigned. As a consequence of this, the time account is created and the initial accrual transfer date rule, which sets the next transfer date to 1 Jan, 2028, is called. On 1 Jan, 2028 the entitlement calendar will run and generate an entitlement for 1 Jan, 2028. Furthermore, during the entitlement calendar run the accrual transfer date rule, which sets the new next transfer date to 1 Jan, 2029 (in case of yearly transfers), is called.
Problem Description
Let's assume the following: The initial transfer is supposed to happen after 10 years of service, thereafter accrual transfers happen on a daily basis. Hence, your rules might look something like this:
Initial Accrual Transfer Date Rule:
Accrual Transfer Date Rule:
One of your employees started to work for your company on 1 Jan, 1992. Now you migrate to SAP SuccessFactors Employee Central Time Management as of 1 Oct, 2020. You assign the time information to the employee and the initial accrual transfer date rule is called. The rule sets the next transfer date to 1 Jan, 2002. The next transfer date is not up to date as it lies in the past. You would first need to run the entitlement calendar which would need to generate (unnecessary) entitlements from 1 Jan, 2002 till today - for every day. As a result, the next transfer date would then be 1 Oct, 2020. However, as a by-product you already start off with 6848 entitlements on the time account. And now let's assume you do not only have one employee with a next transfer date in the past, but multiple ones. The first entitlement calendar that runs needs to process the complete data load which often leads to performance issues disrupting your go live.
Solution Proposal
To avoid this issue, you can set up your initial accrual transfer date rule for the time of the migration as follows:
This way, you make sure that you do not start off with next transfer dates that lie before the go live date. Instead of putting a fixed date (here: 1 Oct, 2020 = Go Live Date), you can also refer to some custom date field or today() - depending on what fits your needs best.
Once the migration process is complete, you can change the initial accrual transfer date rule.
Conclusion
In this blog post you have learnt how to deal with daily accrual transfer configurations during the initial data setup. By applying this approach you get a much cleaner data situation on your time accounts and avoid performance issues. Overall, it leads to a smoother go live.
The solution proposal might be amended as per your individual needs.
Looking forward to your thoughts and comments.
- SAP Managed Tags:
| User | Count |
|---|---|
| 6 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
