Childcare leave refers to a period of paid or unpaid leave granted to employees for the care and/or support of their children under a certain age. In China, we have a common requirement that each couple can enjoy five days’ childcare leave each year until their child reaches three years. In this blog, I am going to demonstrate a workaround solution to achieve this in EC Time Off.

Disclaimer: Please consult your partner before implementing this solution. Perform thorough testing including performance of the Jobs which are going to be listed here.  Reiterating that this is one of my workaround solutions and is not a standard approach. Please do your due diligence before adopting this approach.

For simplicity case, we would take only three children for childcare leave. Any more children need to be handled manually by adding the balance of 5 days to one of the existing accounts

What are the key challenges here?

• Keeping track of every new child born along with youngest dependents
• Avoiding any manual intervention wherever a new child is born. For example, System should be able to detect a child born event and should generate the time account with balance automatically
• Time accounts are not fixed. They do not start with a fixed date like hire date or from Jan to Dec. Every account should start from the child birth date and this process needs to be repeated for the next three years i.e until the child turns 3 years old.

Design

Keeping in mind above challenges the below would be the high level design of my solution

• A custom MDF for every user having such a time profile. An integration center job would run daily to ensure that this custom MDF is created/updated whenever there is a new child born
• The custom MDF is updated with childbirth details each time a child is born using relevant on Save Rules. With every new child born we get a youngest dependent and the youngest dependent keeps changing as and when we progress through years and a new child is born.
• Ad hoc accounts – Since every account should start from the child’s Date of Birth , adhoc account is best suited for this requirement .
• Since we need 3 accounts for 3 years for 3 children, we would need 9 similar IC to create these individual accounts. All ICs are basically a copy of the first IC created with minor changes. This sounds alarming at first sight, but the good part is each IC has its own filter in such a way that it picks only relevant records where The field for Time account is not null. Also, they would filter records only for those users where the MDF was recently changed due to a new child. This is based on last modified date filter. This should take care of performance too.

Since the design is clear , let’s look at  configuration now

Configuration

First, we would build a custom MDF with the following fields and structure

In total we would need 12 fields

External code: This is the user field. For each user we would need an instance of Custom MDF

Child Date of Birth: For each child we have three DOB fields

ChildTA1: We have to store the time account dates for each of the children. For example, Say the 1^st child is born on 1^st June 2022. Then we would need 1^st June 2022, 1^st June 2023 and 1^st June 2024 to be stored as Time account dates for Child 1.  Since we support three children, this would need 9 dates for 3 years.

Now let’s get into the on Save Rules

fillChild1DOB:

The rule checks if this is the first child using count of dependents and gets the youngest dependent date which is the first child itself in this case. We also check for null case “child1DOB is null”. If this is null only then the Child 1 DOB and Time account 1 Date is updated. This is because, there can be cases like Hire, Migration, where the data needs to be fed in manually into this custom MDF (if the employee has existing children). In such manual cases, these on Save rules should not override existing data filled.

Similarly create the other two on save rules for child 2 and child 3

fillAccountDatesCHN:

This is the final on Save Rule which populates fills Child Time Account Dates for year 2 and 3 as and when that birth year is reached

Time Account Type and Time Type Configurations

Since we have three children, we would need three time account types and three time types to be added in time profile. For demonstration purposes, I will be using only two-time account types for two children.

The following is the time account type structure for adhoc accounts

Similarly, create two-time types for 2 children and link them to corresponding time account types. I think this is straight forward and hence I am skipping this part

Integration Center 1

The first Integration center report is to create/update this custom MDF on daily basis. The starting entity is user, and the target is our custom MDF “cust_ChildDOBDetailsCHN”

Once the custom MDF is created or updated, the details like child’s DOB and relevant Time Account Dates are filled

Please note:  The custom MDF is saved only if there are new changes. If there are no changes since the last save from the job, the custom MDF is not saved again. This is necessary for other ICs (which I would explain shortly ) which would filter only recently modified records.

There is only field User ID from User entity which is mapped to externalcode (User field) of the Custom MDF

Integration Center 2

As I explained in above sections, we would need 9 ICs to create three accounts for three children for three consecutive years.  Also, the IC’s are built in such a way that only relevant records are read and only those which have Childs time account date fields filled in custom MDF.

For example, if there is no child born, None of the ICS would pick that user. If the user has only 1 child, IC meant to run for 2^nd child will not even pick that user. Lastly if the user’s MDF has not gone through any changes since the last IC job run that, entire MDF record for that user is filtered out. So overall, this should take care of efficiency of IC runs

I will explain the concept of 1^st IC. The remaining 8 ICS are basically clone of the 1^st one with some attribute changes. If you can look at the 1^st IC design , you can build the other ICs using Save as feature of Integration center in no time

IC to create 1^st time account of 1^st Child:

You would need to create a SF to SF OData Integration with Starting entity as “Custom Child MDF” and target as “Time Account”

1) External Code of Time account is a calculated field which concatenates the user ID with Child Birth of Date and Child No from custom MDF

2) Time Account Type can be hard coded with TAT you use. For example if its child 1 the use the Time account code for child 1, if its child 2 then use time account code for child 2

3) Booking possible from, account valid from and account valid to are all mapped to corresponding time account date field of each child. If we are dealing with child 1 and time account 1, then use child1TA1 from the custom MDF. If its child 1 and time account2 then child1TA2 and so on..

4) Booking Possible Until is mapped to child Time account date (refer to point 3) + 12 months – 1 day

5) User ID is mapped to external code of custom MDF

6) Time account Details (Child Object 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 – 5 days for child care per child per year. You can change it according to your requirement
• Posting Date- Drag and drop effective start date from Child MDF
• Posting Type – Defaulted as “MANUAL_ADJUSTMENT”
• Posting Unit- Defaulted as “DAYS”

The payload looks like this

The payload looks like this
 {
    "entityName": "TimeAccount",
    "payload": [
      {
        "externalCode": "1032582021-04-01C1",
        "accountType": "Child Care CHN (Child1)",
        "bookingEndDate": "/Date(1648684800000)/",
        "bookingStartDate": "/Date(1617235200000)/",
        "endDate": "/Date(1617235200000)/",
        "startDate": "/Date(1617235200000)/",
        "userId": "103258",
        "timeAccountDetails": [
          {
            "TimeAccount_externalCode": "1032582021-04-01C1",
            "externalCode": "1032582021-04-01C1",
            "bookingAmount": 5,
            "bookingDate": "/Date(1617235200000)/",
            "bookingType": "MANUAL_ADJUSTMENT",
            "bookingUnit": "DAYS",
            "__metadata": {
              "type": "SFOData.TimeAccountDetail",
              "uri": "TimeAccountDetail(TimeAccount_externalCode='1032582021-04-01C1',externalCode='1032582021-04-01C1')"
            }
          }

Last step is to add a filter. You can go with a combination of last modified date and a calculated filter

The last modified filter filters out only recently modified records of custom MDF. This ensures that not all user records are picked up unless a new child is born for them

Testing

The 1^st IC (user to custom mdf) is run first in sequence and this should create the custom MDF for the user first.

Let’s assume that employee has 1 child first born on April 01,2021

The on save rules on custom MDF check youngest dependents and fill the child details as and when new childs are born.

Now I Run IC for time account 1 child 1 :

Next I  run IC for time account 2 Child 1:

Next lets say a new child is born today and dependent data is filled (child 2 should be filled by main IC1 when its scheduled and run)

Main IC1 would again fill the existing MDF with child 2 details for this year. See below TA1 date for child 2 is filled

Then IC for Time account 1 Child 2 runs and creates the relevant adhoc account too as you can see below

To summarize, the IC1 for creating custom MDF should be run first so that it periodically keep tracks of new children born and then remaining time account creation ICs should be run. These can be scheduled every day, week during non-business hours with a gap of say 2 hours between each of them

Other user cases and recommendations

• Migration/ New hire :

For new hires, there can be two scenarios:

1. New Hires without any children – This will work without any manual intervention and any new children born would be tracked via IC and MDF.
2. New hires with existing children below three years – This info has to be fed manually in the custom MDF just like any migration scenarios….(The HR can maintain this info just like how they maintain for any new hire like job info, compensation info, dependents info etc). Once the information is fed in custom MDF, the time accounts would get created automatically via IC.  I guess it is reasonable for HR to do this since they anyways feed the other personal and employment details manually during new hire.

• Twins – For twins only the 2^nd child info is fed. You would need to fill the 1^st child info manually.
• This approach is recommended for a customer with relatively smaller employee size. If you have a larger employee size, then you can split the main IC (user to custom MDF) into multiple ICs depending on filters like legal entity, Department, Employee Class, type etc For example, if you have say 5000 employees who need this solution, split the main IC into 5 equivalent ICs and then schedule them with a gap of atleast 2-3 hours. I have tested this for a smaller sample size. For larger size, I would recommend you try out above options, test completely in a sandbox or QA and then deploy it

• Also in the IC, we have operations listed as “Upsert Multiple” and “Upsert Single”. If there are data issues trouble shooting becomes difficult in Upsert Multiple Mode as the entire batch of records would fail. For initial load and testing, use Upsert Single to see if it works for majority of the population. Then once you have tested this and run it multiple times, you can try with Upsert Multiple.

Hope this helps to overcome this challenge

To Summarize, I want to reiterate again that this is merely a workaround solution and not a standard.

If you are implementing this approach, do thorough testing , adjust as per your needs, and then deploy