3000109 - Duplicate Entitlement Postings

• Duplicate Entitlement postings showing on user's Time Accounts Tab
• Entitlement Calendar Failed

SAP SuccessFactors Employee Central -  Time Off

Example for Monthly Entitlements:

1. Next transfer date for user's Time Account is set to 01.11.2020
2. Entitlement calendar on 01.11.2020 runs, & creates the following entitlement: 01.11.2020 - 30 days
3. Accrual transfer date handling rule should set Next transfer date to 01.12.2020.
4. However, it fails, so next transfer date stays as 01.11.2020.
5. On the next day (2.11.2020) entitlement calendar picks up the TATAT again because next transfer date lies before 02.11.2020 and creates again an entitlement: 01.11.2020 - 30 day

Support: See internal Memo

• During the entitlement calendar run, first the time account is saved, then the Time Account Type Accrual Transfer (TATAT) Object (which sets the Next Transfer date).
• Due to a failing entitlement calendar, it can happen that time accounts are saved successfully with the entitlement/accrual reset posting, but then there is an issue when saving the Time account type accrual transfer, hence, new next transfer date cannot be set.
• As a consequence, if the calendar runs on the next day it will pick up the account again because next transfer date shows still the old next transfer date, and creates again an entitlement on the same date with same amount.

Proposed Code Fix: Time Account will not be saved if TATAT failed during update. With this in place, if time account type accrual transfer cannot be saved, whole transaction will be rolled back, and entitlements are also not saved.

Workaround: A check tool check "DuplicateEntitlementPostings" is being added (via patch scheduled on 25th Dec 2020) , which can retrieve the necessary data that can be deleted manually/via import. Meanwhile, you can raise a case to SAP Product support (under the component LOD-SF-EC-TIM) for a db query to fetch duplicates. And based on these results you'll be able to delete the postings manually or via an import.

Note: The check tool results file contains max. 10,000 entries. If a customer’s instance contains > 10,000 issues, they need to repeat the steps until the check tool runs green.

Once check tool check "DuplicateEntitlementPostings" is patched to the instances, please follow the below steps:

1. Navigate to Admin Tool -> Check Tool -> Select 'Time Off' -> Run the check for "DuplicateEntitlementPostings". If the check tool returned any issues, click on “Export Results”
2. Go to Admin Center > Import and Export Data and download the template for the generic object “Time Account-Time Account Details”.
3. In the template, you only need the columns “Operator”, “externalCode, and “timeAccountDetails.externalCode”. Remove the other columns.
4. Copy the results from the CSV file which you have downloaded in step 1 and paste it into the template which you have downloaded in step 2. The columns map as follows:

Result file > Template:

Time Account Code > externalCode

Time Account Detail Code > timeAccountDetails.externalCode

You don’t need the remaining columns from the result file.

5. As “Operator”, enter “Delimit” for all rows of the file.

Note: The result file does not contain all entitlement/accrual reset postings on a day but only the redundant ones. This means that you can delete all of the postings from the result file. Here’s an example:

The following entitlement/accrual reset posting pairs are on a time account:

1 Jan, 2020 – Entitlement: 1 day

1 Jan, 2020 – Accrual Reset: - 1 day

1 Jan, 2020 – Entitlement: 1 day

1 Jan, 2020 – Accrual Reset: - 1 day

1 Jan, 2020 – Entitlement: 1 day

1 Jan, 2020 – Accrual Reset: - 1 day

So, in total there are 3 entitlement/accrual reset posting pairs on the same date. The result file will only show two of them:

1 Jan, 2020 – Entitlement: 1 day

1 Jan, 2020 – Accrual Reset: - 1 day

1 Jan, 2020 – Entitlement: 1 day

1 Jan, 2020 – Accrual Reset: - 1 day

If you delete them now, one posting pair will remain on the time account:

1 Jan, 2020 – Entitlement: 1 day

1 Jan, 2020 – Accrual Reset: - 1 day

6. Go to Admin Center > Import and Export Data and import the template which you have filled out in steps 4 and 5. Make sure that you select the generic object “Time Account-Time Account Details”. Furthermore, purge type must be set to “Incremental Load” and key preference to “External Code”.

Other Root Causes:

1. In the Accrual Transfer Date rule, there is no distinction made between regular and ad hoc transfers, or if made, the posting date for ad hoc transfers is set to "Next transfer date" .

For ad hoc transfers the posting date should be "Ad hoc transfer date", not "Next transfer date".

Engineering are working on a preventative enhancement where we will add a config guardrail: (TIM-20206)

This enhancement will add a validation which prohibits the following for Accrual Transfer Date Rules:

• Setting "Next Transfer Date" as posting date for ad hoc transfers.
• Creating an "Always true" rule (i.e. not distinguishing between ad hoc and regular transfer)

     2. Before the 2H 2020 release, the posting date of an entitlement was set to the bookable start date of the time account in case that the posting date was outside the bookable period. If entitlements on multiple transfer dates outside the bookable period were created, there can be multiple postings on the bookable start date of an account.

TIM-19617, TIM-20206, TIM-17400, TIM-19193, PTCH-34659, entitlements posting twice, entitlements failing, duplicate entitlement, DuplicateEntitlementPostings , KBA , LOD-SF-EC-TIM-CAL , Calendar Jobs , LOD-SF-EC-TIM , Time Off , Problem

SAP SuccessFactors Employee Central all versions ; SAP SuccessFactors HCM Core all versions