Multiple time-off in lieu (TOIL) is a common requirement across many customers. However, until now we have posting to only one time account as standard option via Time Sheet. This can be addressed with our super cool Adhoc Time Account Type.
Before we divulge to solution, a quick explanation of TOIL concept to our new Time Management learners.
When an employee works on public holiday or non-working day or overtime, the company has the option either to compensate the hours in payroll or provide a time-off in lieu which the employee can avail. There are multiple variations of TOIL as listed below.
- Provide only time-off for additional hours worked.
- Provide time-off that needs to be availed within a certain period (E.g., 60 days from eligible date) and post that, it is forfeited.
- Provide time-off that needs to be availed within a certain period (E.g., 60 days from eligible date) and post that by default it is compensated in the following payroll.
- Only compensation. This is done via standard payroll with time sheet replicating the data and is not relevant for this blog.
In this blog we will try to address the scenarios 1 to 3 with multiple TOIL accounts. We are going to using Adhoc Time Accounts and Payout concept to achieve this.
Please note that this solution involves many standard steps which I don’t want to detail out in this blog. I only wanted to highlight the key configurations to achieve this solution.
The following steps are performed to achieve this solution.
- Create Time Account Type for each TOIL account (e.g. Public Holiday account, Overtime Time account etc).
- Account Creation Type – Adhoc
- Assign a Payout Profile. This also means the necessary Pay Components are to be assigned in this profile.
- Create Period End Processing rule based on your scenario for paying out at the end of booking period.
- Assign the Time Account Type to relevant Time Types.
- Create your time valuation rules that captures hours into their respective Time Collector. Please note that for each TOIL account there needs to be its respective Time Collector. E.g., Public Holiday into collector object called PH_Collector with “daily” frequency. Another one could be Overtime TOIL to OT_Collector with “daily frequency”.
- Create Integration Centre report based on Time Collectors to create Adhoc Time Accounts. This is what the blog is about – key configuration.
- Execute Integration Center report only daily frequency.
Step 1 to 5
Assign to Time Type.
Step 6 is simple, and I leave it to consultants to create on their own based on customer requirement. Some sample below.
Create time entries in timesheet accordingly and generate the collector value.
Similarly, you can perform the same steps for other TOIL accounts.
Step 7 : Please note that you have to create one Integration Center report for each TOIL account. For this blog, I will create one and you can repeat for multiple cases.
Create Integration Center (IC) report with “More Integration Types”
Choose the setting as shown below and click “Create”.
Choose the Source object as “Time Collector”
Provide a name to the report:
Choose “Mapping View” as shown in the below screen shot and follow the steps. Add object Time Account in Destination.
While in Field Mapping view (blue icon on the top right corner), drag and drop the fields as shown in the snapshot below. Please note that you can generate External Code for Time Account on your own, however, I choose to use the same Ext. Code of Time Collector for Time Account and Time Account Details. Feel free to choose your methodology.
Important: It is key how we create our Account Valid From and Account Valid Until. Since we can’t have overlapping accounting period, we have to choose the lowest frequency – a day. I envisioned it like an Adhoc Account valid for one TOIL occurrence, that’s max one day. However, the booking period is important one and that can be for a period. For the blog scenario, I have kept it as 60 days from day of eligibility.
You can go with startDate or Last Posting Date (bookingDate) of Time Collector to map with Booking Possible From, Account Valid From and Account Valid Until. I believe (unverified yet) Last Posting Date is more accurate if user do retro changes and this is handled automatically. This can be explored by consultants.
For Booking Possible Until, switch to detail view and created a calculated field.Choose Start Date + 60 days as logic. Run calculation trace to verify the results.
Map the Time Account Type to the TOIL account you created. In this case ADHOC_TOIL1. Follow the blue icon to configure.
Map field Time Account – Closed (Boolean) as False by default setting.
Now open up the child object Time Account Details navigation and map the fields as shown below.
Map the Posting Type to INTERIM_UPDATE
Amount Posted – Calculated field. This is because the Time Collector value is always in seconds. This needs to be converted to Hours.
After all the mapping is done, switch to Test View (blue icon in snapshot) and run the preview records. Check if you see successful results in the Run Results Status column. Refer to our step 6 where we created those two entries and that has been successfully queried below.
Now save this section and click next for Filter and Sort page.
This is a section I always recommend customers or consultants to build their own effective filtering configuration. Filter criteria is built based on the various factors like what frequency is the IC report need to be run, how much data is processed (this comes after some trails), what is the best time to run it, are there any pre-requisite jobs e.g. importing timesheet entries from terminals and etc.
Here is a simple sample. Make sure you have Time-Based filter is modified or effective since “last run time”. This is critical in any retro changes to be automatically handled. Also, filter the Time Collector for which the IC report is built.
Set frequency. Since I have kept my Time Collector frequency as Daily, it is logical to run the IC daily. However, you can build based on your requirement.
Step8 : Click to next screen, schedule the report and move to Review and Run page. Now run the IC report.
After execution of IC report. Check the booking period and posting values.
For April 26th PH working TOIL
For April 29th PH working TOIL
Viola ! 🙂 we achieved multiple TOILs. Repeat the steps to other TOIL accounts like Overtime. There is no change in configuration.
For forfeiting there are two option. One, this leave has to be taken only within the booking period. So automatically this bounds the employee to take the leave and is technically forfeited already if taken outside of the booking period.
Second, if back dated booking is not permitted, the accounts can also be closed. There are multiple ways of doing it – Using Integration Center to filter out all open account as of particular date and update the same object back with “closed”. Refer to my mandatory leave blog where I used EmployeeTime object to update itself- https://blogs.sap.com/2021/02/15/employee-central-time-off-how-to-solve-mandatory-block-leave-scenario-blog-1-2/. Similar concept can be deployed.
Also for payout options, there is no special configuration but just the standard steps. Once PEP runs and Payout is generated, the balance can be forfeited to 0 and closed via rules.
In the interest of time and length of the blog and more importantly in keeping my learned colleague and friend Volker- https://people.sap.com/volker.ruof happy 😉 I’m leaving out the above standard steps. We need to do release this blog asap ;).
Happy learning and stay safe !! Thank you.