Converting Allowance to Time Off in Lieu (TOIL) in...

NeeleshKamath · ‎2023 Aug 04

Background

We have heard of a very common requirement where an employee works on a public holiday, and this needs to be converted to TOIL. We all know this can be achieved in current times.

But what if we have a twist to this story? There are companies where they request employees to record this special overtime on public holidays as allowances (Decimal value). The decimal value then needs to be converted to hours in a TOIL Account. Have you ever wondered if this can be achieved? Currently, there is no direct way of moving Allowance to TOIL or a standard setting to do so.

I would be demonstrating a process that can be used as a workaround to move the allowances recorded in a timesheet as time account balances.

Approach

This is the high-level approach to this solution

Introduce two custom fields in the Allowances MDF Object : User and allowance amount to be moved to TOIL. We need to store the user again because the allowance is a child object of employee timesheet object. Hence we would need to know the user details of each such allowance recording when moving them to TOIL

Make the user field in the employee timesheet MDF Object from not visible to read-only.

Adhoc Time Account type to handle multiple TOIL

Integration Center to Map allowance fields (including custom user field created in the first step) to an Adhoc TOIL Account

The Integration Center job can be scheduled on a daily basis to move these allowance hours

Please note we will use a similar Integration Center approach to Multiple TOIL which was discussed in one of the previous blogs.

For reference, you can read through here

https://blogs.sap.com/2021/04/30/employee-central-time-off-multiple-time-off-in-lieu-toil-solution/

We will use the below sample requirement to demonstrate the approach

At a company, ABC people can select if they work on a specific public holiday to get an 8 or 16hrs added to their TOIL/Flextime account. And because people can decide for themselves, and because the account amount is fixed, (8 or 16hrs) you want to handle this via Allowances.

This means that:

if employees record an Allowance with a 1 in the time sheet, that we transform/convert this via the Integration Center into an 8hr TOIL account update

If employees record a 2 that they then get 16hrs added and so On

Hope this is clear

Now to next steps one by One

Custom Fields in Allowance Object

The cust_user stores the user details from parent object Employee time sheet

Cust_AllowanceAmountToil stores the actual hours to be credited to Adhoc TOIL account

User Field in Employee Time Sheet Object

Make the user field in employee time sheet object as ‘read only’ from ‘not visible’

On Save Rule on Allowance Object

Next create a onSave rule which stores the values of these two custom fields. The onSave rule is attached to Allowance MDF Object

Allowance Time Account (Adhoc Toil Account)

Create an Adhoc account for storing the TOIL Hours

Integration Center

Create an SF to SF OData integration center definition.

The starting entity would be Allowance

And target entity would be Time Account

The mapping is similar to the process defined in (Multiple TOIL blog shared above)

There are subtle differences like

The external code for time account and details both is calculated like the below

Account Valid Start and End Date should be mapped to Allowance Date

Booking Start Date is also mapped to Allowance Date

Cust_user field from allowance is mapped to user field of time account

Cust_AllowanceAmountToil is mapped to bookingAmount field

Booking End Date is calculated field which can be set to say Allowance Date + 12 months for example. It is quite flexible. You can decide booking end date based on your requirement

Rest of the mappings are like the ones mentioned in multiple TOIL blog.

I will add a payload for your reference here.

[

  {

    "entityName": "TimeAccount",

    "payload": [

      {

        "externalCode": "Jgoh2023-07-24EXTRA",

        "accountType": "FLEX_ALLOW_MY",

        "bookingEndDate": "/Date(1721779200000)/",

        "bookingStartDate": "/Date(1690156800000)/",

        "endDate": "/Date(1690156800000)/",

        "startDate": "/Date(1690156800000)/",

        "userId": "Jgoh",

        "timeAccountDetails": [

          {

            "TimeAccount_externalCode": "Jgoh2023-07-24EXTRA",

            "externalCode": "Jgoh2023-07-24EXTRA",

            "bookingAmount": 16,

            "bookingDate": "/Date(1690156800000)/",

            "bookingType": "INTERIM_UPDATE",

            "bookingUnit": "HOURS",

            "__metadata": {

              "type": "SFOData.TimeAccountDetail",

              "uri": "TimeAccountDetail(TimeAccount_externalCode='Jgoh2023-07-24EXTRA',externalCode='Jgoh2023-07-24EXTRA')"

            }

          }

        ],

You would then need to add appropriate filters to ensure that only special allowances are picked up by the IC job and not all allowances.

Also you need to add last modified since filter to pick only recently modified records

This is it w.r.t the configurations. Now let us test some scenarios

Testing

Let's say then you run the Integration Center job.

This would then translate into appropriate Adhoc Toil Accounts

Just some things to note about:

In the end, this is a workaround solution. Please do not expect 100% fitment as standard.

If someone deletes an allowance after it is credited to Adhoc Account, then it would need a manual intervention from admin to clean up that account. This scenario might not be very common though.

Please do your own analysis before recommending this solution to customers. Test them with your use cases.

This solution only works for special allowances type which are recorded not so often. Ex: Special occasions, Holidays, etc. If you create this solution for each allowance type, this will lead to a plethora of Adhoc time accounts. So please only do this for special allowances. I would not recommend this approach for daily use cases of allowances

Best of Luck

Neelesh