Skip to Content
Product Information
Author's profile photo Neelesh Kamath

Sick Leave Handling in EC Time Off for Middle East Countries

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.

Note: We are also planning to roll this out as a best practice solution via upgrade center in the coming releases. 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 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

  1. 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
  2. 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.

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.

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

A message is displayed indicating that it can take upto five minutes for a new adhoc time account to be created.

The Integration center is run as expected every 5 mins .

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

 

 

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Hany ZANATY
      Hany ZANATY

      Thanks Neelesh for this great solution, this solution really covers the legal Saudi Arabia requirements for Sick Leave 🙂

      Author's profile photo Neelesh Kamath
      Neelesh Kamath
      Blog Post Author

      Thanks a lot Hany 🙂