- SAP Managed Tags
One of the most awaited solutions is here....Enjoy
Often in middle east countries, we come across a requirement for sick leave where the validity is not something which is fixed i.e based on hire anniversary or Jan- Dec etc. The validity varies based on some conditions. Below is a sample requirement which we see typically in these countries.
- Employee is entitled for 120 days in a sickness year
- Sickness year is a year that starts from first Sick Leave request and ends after one year
- If employee request a sick leave after the end of previous sickness year, a new sickness year starts and so on, a gap between sickness years is possible
- The first 30 days of the 120 days are paid, the next 60 days are 75% paid then the last 30 days are unpaid à These slabs (absence distribution) are a payroll activity, and we will not cover this part in EC
Solution Overview
- Create a Custom MDF named “Sick Leave Tracker”. This is a tracker which keeps track of window period of a sickness year. For every first leave of a sickness year, this tracker has to be requested by an employee via ESS through People Profile. This would a one time activity per sickness period/year.
- Create an Adhoc Time account type and corresponding time type. The adhoc time account suits this requirement because it gives you a flexibility to have any gaps and flexible start and end dates between two accounts. The idea is to map the sick leave tracker object to an adhoc account with 120 days
- Create an Integration Center Report which creates an Adhoc Time Account from a sick leave tracker MDF object.
- Some validation rules can also be created to make sure the linkage between tracker and account is correct.
Benefits of this solution
- Every account is tracked separately. Hence easy to report on the balances, usage, etc from a managerial or admin perspective
- No Complex take rules or validations are required to track these sick leave calendars and dates. Very easy to interpret and implement the solution
- The history of leave and balances is captured in time accounts. Hence easy to keep track of history and past balances/leaves
Note: This is also part of the best practice solution via upgrade center. Then you would pretty much get this config automated and deployed in your system in a matter of minutes.
Disclaimer: This is one of the custom workaround solutions that I have built. You may have to adapt or extend this further based on your client’s requirements.
Sick Leave Tracker
External Code: User
Cust_SickLeaveStartYear : Sick leave Quota Start Date of a new sickness year
Cust_SickleaveEndYear: Sick leave Quota End Date of a new sickness year
Each time an employee needs to create a first sick leave which does not belong to previous period OR if this is the first sick leave in the system for an employee, the employee requests a new window period through this tracker object. The employee just keys in the effective start date (basically the start date of the first sick leave). The Sick Leave Quota Start Date and End date are filled by business rules
Here are the on Save rules attached to the MDF object
The above rule checks two conditions
- Initially the window was requested by employee through the tracker and corresponding adhoc time account was created. But later, the employee tried to change the date of tracker object. This can lead to data corruption. Hence an error is raised indicating that a time account is already linked with the original start date. Kindly reach out to admin to change the time account linked or delete and recreate a new adhoc time account. This changing of dates needs to be handled explicitly by admins who can later adjust the tracker and time account
- The second checks for overlapping case. For example, the tracker object has a window from say 15th Oct 2021 to 14th Oct 2022. If some one tries to insert a new record between these dates say Aug 1st 2022, an error is raised
The above rule flashes a message to employee that the tracker request is successful and he/she needs to wait for 5 mins for the time account to get created post which they can start requesting the sickness leave for that sickness year. The idea is to schedule IC every 5 mins so that it picks the latest tracker records.
Imp Note: The above is a sample message indicating that it may take up to 5 mins for IC to create records. In reality, this can also take longer and depends on IC Scheduling. Hence my advice would be to take a higher time frame like an hour or so so that the jobs can run efficiently and also modify the above message according to your frequency. For more details on scheduling refer to IC implementation guide which gives you more clarity on how to schedule these with the best frequencies
Time account Settings
An Adhoc time account needs to be created with below settings
If the balance gets lapsed after every sickness year or bookable end date, attach a standard PEP rule which closes this account.
Also, to ensure, the employee does not overuse the accounts, you can maintain the “balance cannot fall below” field as 0
Time Types Settings
Create the below time type along with a take rule as shown below. Link the Time type to Adhoc Time account type created above
The take rule is to handle cases , when an employee tries to request a leave outside the current window period of a sickness year.
There is another take rule where we need to check that the first sickness leave should always start from the sick leave tracker date. This can be validated using below rule
Add these take rules in the same order to the corresponding time type.
Finally link this time type to a corresponding Time profile
Integration Center
The integration centre is the heart of this solution. Once the tracker is requested by the employee, we need to create a new adhoc account with specific dates and amount (120 days)
You would need to create a SF to SF OData Integration with Starting entity as “Sick Leave Tracker” and target as “Time Account”
1) External Code of Time account is a calculated field which concatenates the user ID with effective start date of tracker
2) Time Account Type can be hard coded with TAT you use. For example:
3) Booking Possible Until is mapped to Sick Leave End Date (Quota End Date) field of custom MDF
4) Booking possible from, account valid from and account valid to are all mapped to Sick Leave Start Date (Quota Start Date) field of custom MDF
5) User ID is mapped to external code of custom MDF
6) Time account Details (Child of Time account)
- Time_Account_External_Code – This is the external code of time account parent object. Use the same calculation and same code as described in point 1)
- External code – This is external code of child time account detail. Use the same code and calculation as described in point 1)
- Amount posted – Default value of 120 days. You can change it according to your requirement
- Posting Date- Drag and drop effective start date from tracker custom MDF object
- Posting Type – Defaulted as “INTERIM_UPDATE”
- Posting Unit- Defaulted as “DAYS”
The payload should like below
{
"externalCode": "1060382021-11-22",
"accountType": "SICK_LEAVE_NK_DEMO",
"bookingEndDate": "/Date(1668988800000)/",
"bookingStartDate": "/Date(1637539200000)/",
"endDate": "/Date(1637539200000)/",
"startDate": "/Date(1637539200000)/",
"userId": "106038",
"timeAccountDetails": [
{
"TimeAccount_externalCode": "1060382021-11-22",
"externalCode": "1060382021-11-22",
"bookingAmount": 120,
"bookingDate": "/Date(1637539200000)/",
"bookingType": "INTERIM_UPDATE",
"bookingUnit": "DAYS",
"__metadata": {
"type": "SFOData.TimeAccountDetail",
"uri": "TimeAccountDetail(TimeAccount_externalCode='1060382021-11-22',externalCode='1060382021-11-22')"
}
}
],
"__metadata": {
"type": "SFOData.TimeAccount",
"uri": "TimeAccount(externalCode='1060382021-11-22')"
}
Last step is to add a filter. You can go with a combination of last modified date and effective date range so that only few records as of today, past year and future year at max are considered for creation, updates
With this we are done with setup. Now time for some testing
Testing
Hire an employee with a time profile that contains above time type
If the employee tries to request a sick leave, an error is raised which directs an employee to request a tracker first
Now employee goes to sick leave tracker and requests a tracker for Say Oct 8th 2020
Imp Note: The above is a sample message indicating that it may take up to 5 mins for IC to create records. In reality, this can also take longer and depends on IC Scheduling. Hence my advice would be to take a higher time frame like an hour or so so that the jobs can run efficiently. For more details on scheduling refer to IC implementation guide which gives you more clarity on how to schedule these with the best frequencies
After IC is run, check the time account for employee. It will be created with one year horizon from Oct 8th 2020 to Oct 7th 2021
If the employee tries to change now the dates , Say he/she changes the date from Oct 8th to say oct 6th an error is thrown
Any changes to the tracker post the account creation has to be dealt with by the admin. The admin can adjust the time account dates from manage data or import/export (if it is mass change) and then adapt the tracker.
Now say , the employee falls sick on Nov 20th 2021. This is outside the current window and he/she needs to request again a tracker with date as Nov 20th 2021.
This should now create a new Adhoc Account from Nov 20, 2021 to Nov 19 2022. As you can see that now there is a gap between previous sickness year and the new year which starts from Nov 20, 2021
Another account is created now with below timelines
This is a custom solution that can be used to tackle the typical sick leave scenarios of Saudi Arabia.
The advantage of using an Adhoc time account is that each account keeps track of all leaves including balances for a sickness year. Reporting and Using APIs to get the corresponding leaves, balance, or time account details for payroll should be possible as well. There also would be no issues encountered during cancellation or editing of existing leaves as each dedicated account and time off framework would take care of the same.
Hope this helps your implementation. We also plan to automate this and release this as a best practice solution
Stay Safe
Best Regards
Neelesh
Senior Product Specialist
Best Practices for Successfactors HXM
SF Product Management
| User | Count |
|---|---|
| 28 | |
| 7 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
