Manage Sick Leave Scenario in SuccessFactors Time Off as per Middle East Policies, without creating any Time Accounts (Quotas)
Dear Readers, In this blog we’ll check a suitable solution for one of the very demanding scenarios for Middle East region-specific customers.
Sick leave is granted for 120 days per annum, where the year begins from the first date of the sick leave, at the following rate. The sick leave period can either be continuous or intermittent.
- The first 30 days: entitled for Full Pay (100%)
- The following 60 days: entitled for three-quarters of the wage (75%)
- And the following 30 days without pay.
As per current features in SuccessFactors, this dynamic year detection based on the first sick leave application is not feasible by standard. So in this blog, we’ll check a suitable workaround solution, to meet this requirement.
NOTE: In this blog, we have focused only on the specific part of the requirement (dynamic year detection). The salary proration based on the number of days applied in sick leave is not covered in this blog. This can be done in Payroll directly, rather in SuccessFactors EC Time Management.
Disclaimer: All pictures are taken from DEMO system.
Key Benefits of the Solution:
- No Time Accounts (Quotas) need to be created. The policy restriction can be managed through Take-Rules (Business Rules). So no burden of time accounts.
- End User Experience wise also this solution will be stable and acceptable, as the end-user only will interact with Time-Off screen, just like other leaves.
- Apart from the Leave application, no additional manual activity is required.
Overview of the Solution Design:
Configuration Steps in detail:
Step 1: Time Type Creation and Assignment to Time Profile
Go to ‘Manage Data‘ and create ‘Sick Leave’ Time Type as below:
Assign the sick leave to relevant Time profile.
Step 2: Create custom fields in ‘Employee Time’ Object.
Go to ‘Configure Object Definition -> Object = ‘Employee Time” and create two custom fields as below to capture Sick Leave Period Start Date and End Date.
Apply the below field condition so that those fields only appear/applicable for ‘Sick Leave‘. In the below example, the condition value is set as ‘1011’ as we have created Sick Leave with external code ‘1011’.
NOTE: ‘Visibility‘ of those custom fields should be ‘Editable‘, else in Integration Center Job, those fields will not be available.
Go to relevant permission role in ‘Manage Permission Role‘ admin tool and apply below permission setting for those custom fields in ‘Employee Time’ object, so that those fields should appear as read only in Time-Off Screen.
Step 3: Create a custom MDF.
Go to ‘Configure Object Definition‘ and create one Custom MDF as below. The purpose of this MDF is to store Sick Leave Period Start Date and Sick Leave Period End Date as per approved sick leaves.
Step 4: Business Rule to populate Custom fields ‘Period Start Date’ and ‘Period End Date’ in ‘Employee Time‘ object.
Go to ‘Configure Business Rule‘ and create a business rule as below with base object ‘Employee Time’ and assign it to ‘On Change‘ event of below fields in ‘Employee Time’ MDF.
- Time type
- Start date
- End date
Purpose of this business rule is to populate ‘Period Start Date‘ and ‘Period End Date‘ while employee going to submit Sick Leave request.
Business Rule Logic:
If employee is applying first sick leave in that period, then ‘Period Start Date’ = Leave start date and ‘Period End Date’ = Leave start date + 12 Months.
If employee is applying further sick leave in that period, then ‘Period Start Date’ and ‘Period End Date’ is getting populated based on Custom MDF Table data.
Step 5: Build Integration Center Job
Build one Integration Center Job as below.
The Purpose of this Job is to replicate the Period Start date and Period End Date as captured in approved sick leave requests, into the custom MDF created in Step 3. As it is expected that data should be automatically replicated to custom MDF table, so we need to schedule this IC Job. In this design, we have scheduled the Job with Multiple execution per day (with minimum frequency as 2 hours).
Step 6: Create Take-Rule
This step is the most important in this whole solution and a bit tricky. As we are not supposed to create Time Accounts (Quotas), so our take-rule should be capable enough to bound employee to follow Sick Leave Policy as well as populate the balance, so that Employee can understand how many days has already been taken and how many days are remaining to take within the specific period. To populate that we have used Message Parameters to dynamically show the values through take-rule.
Lets check the take-rule part by part.
Part 1: In this section, Rule is going to populate the entitlement for 120 days as an information message when first time employee is going to apply for sick leave in any specific period.
Part 2: As we have scheduled the frequency of Integration Center (to update the custom MDF as per Period Start Date and Period End Date from approved sick leave request) as 2 hours, so we have to restrict employee to apply new sick leave if previous sick leave is still in pending status.
This section of rule is serving that purpose.
Part 3: As we have scheduled the frequency of Integration Center Job as 2 hours, so we have to restrict employee to apply new sick leave request until Period Start Date and Period End Date fields are not updated in custom MDF table as per previous approved Sick Leave Data.
This section of rule is serving that purpose.
Part 4: After the previous sick leave is approved and the Period start date and Period end date is replicated to Custom MDF, when employee try to book next sick leave request, system should prompt the available balance.
This section is serving that purpose by populating the information type message.
Part 5: In this section, we apply restriction to book sick leave more than entitled days (120 Days) in a single transaction.
Part 6: In this section, we apply restriction to book sick leave if the aggregation (current sick leave days + previous approved sick leave days in same period) is more than entitled days (120 days).
Part 7: In this section, we apply restriction to book sick leave if Employee has already consumed max entitlement of sick leave in the same period.
Sequence of the Rule Blocks in Take-Rule:
For the purpose of better understanding, we have described each part of the Take-Rule in previous section, but you need to maintain the sequence of rule-blocks as below, so that it can work properly:
- Rule-Section1: Part 7
- Rule-Section2: Part 5
- Rule-Section3: Part 6
- Rule-Section4: Part 3
- Rule-Section5: Part 2
- Rule-Section6: Part 4
- Rule-Section7: Part 1
Now it is time to test the solution. Lets test it based on below scenarios:
Scenario A: Employee is going to book sick leave first time in a period.
- Period Stat Date and Period End Date fields are getting populated as per selection of Time Type/Start Date/End Date. Business Rule created in Step 4 is responsible for that.
- The information message (in blue) populated to show the max entitlement of sick leave. Take-Rule Part 1 is responsible for that.
Scenario B: If previous sick-leave request is still in pending status, take-rule will restrict to book new sick leave.
This check is required because we are using here Integration center which runs in every 2 hours and pick approved sick leave records to to update period start date and period end date fields in custom MDF. So until that MDF table is updated, we cannot allow employee to new sick-leave request.
Take-Rule Part2 is responsible for this check.
Scenario C: If previous sick-leave request is approved but the Custom MDF is not updated yet, take-rule will restrict to book new sick leave.
NOTE: In place of ‘Integration Center’, if you are planning to use Custom CPI Interface to update Custom MDF in real time, then this part of take-rule will not be required.
Take-Rule Part3 is responsible for this check.
Scenario D: For testing purpose, now we are running the IC Job manually and update the Custom MDF table.
Scenario E: If previous sick-leave request is approved and the Custom MDF is updated as per Period start date and Period end date, Employee will be allowed to new sick-leave request and then take-rule will populate the balance details of Sick-Leave in that specific period.
Take-Rule Part4 is responsible for this message population.
Scenario F: If Employee is going to book more than entitled days (120 days) in a single transaction, take-rule will restrict by throwing error message.
Take-Rule Part5 is responsible for this check.
Scenario G: If Employee is going to book more than entitled days (120 days) in multiple transactions, take-rule will restrict by throwing error message.
Take-Rule Part6 is responsible for this check.
Scenario H: If Employee is going to book sick leave from future period, system also allows that and also prompting entitlement for future period. Current period remaining balance is not going to be counted in that case.
NOTE: This scenario many vary organization wise. If your organization, will not allow to book future period sick leave, we can apply restriction on that in take-rule.
In a nutshell, the summary of the overall solution will look below, to detect the dynamic year based on first sick leave application by employee:
- There is no time account type we have created to generate the quota, which eventually reduce the burden to maintain quota balances.
- We simply created one custom MDF to store the sick leave period start date and end date.
- We also have created two custom fields in ‘Employee time’ object, based on which Custom MDF table is updated via scheduled Integration Center Job and if employee try to apply further leave in the same period, those custom fields in ‘Employee time’ is getting populated based on custom MDF table data. One business rule is created for this purpose and assigned to on change of Time type/Start Date/End Date fields on ‘Employee time’ object.
- Lastly, one take rule is created for Sick leave to apply all relevant restrictions as per Middle East Sick Leave policy.
Hope this solution will help you to overcome the challenges on Middle East Sick Leave requirement. Please help to put your thoughts and comments on this solution and follow my profile for my more upcoming topics.
Also, you can find more topics on SAP SuccessFactors Core Environment here: https://community.sap.com/topics/successfactors
You can also post question and answers on SuccessFactors Topics here: https://answers.sap.com/tags/67837800100800006332
This is such a detailed and elaborated blog on the scenario! thanks Arpan for sharing your knowledge and expertise
Thank you Swathi!
what the purpose of custom MDF and syncing the data thru Integration Job?
Purpose of Custom MDF: As the sick leave period is dynamic here (not calendar year or service year), we need to have a reference table to store the sick leave period start date and end date based on first sick leave application in that period. Custom MDF is serving that purpose here.
Why need to sync data to Custom MDF through IC Job? - The data in custom MDF is fed from two custom fields in Employee time object. The Integration Center Job is used to sync that data from Employee time to custom mdf.
Hope the explanation, clarifies your queries.
This is a great solution. It was mentioned that the salary proration based on the number of days applied in sick leave is not covered in this blog. That this can be done in Payroll directly, rather in SuccessFactors EC Time Management.
Question: This would mean EC Payroll would have to identify the number of sick leave days used by the employee correct? It is a payroll activity to which proration days the newly requested sick leave will be applied to?
Thank you. Yes your understanding is correct.