Time Type Validations based on a separate limit for different event or leave reasons

[NeeleshKamath]

Welcome to my second blog of year 2021.

We have come across many situations where we would like to check total absences taken for a particular leave type. Pretty Simple Isn’t’ it? But what if I need to check a limit per event, reason for a single leave type. Now things are getting complicated. Imagine you have a single leave type which can be used for multiple event/leave reasons and each event or leave reason has a defined limit.

We have standard rule functions like 'get absences in a period' etc, but they can be used for time types in general as a whole. But we have a scenario to check the absences taken for a time type for a particular leave reason. This makes things complicated

In below Blog , I will demonstrate one of the ways to achieve this. Since there is no standard way of doing this, consider the below solution as a workaround itself. Adapt and test for your use cases thoroughly before using it in any implementations

The blog is going to be long as both the requirement and solution is complicated. Kindly browse through all the details to understand the design completely

Disclaimer: I have used the Leave reasons A & B  for demo purposes. You can adapt the leave reasons name as per your company policies.

Requirement:

In most of the countries there is a Leave which can have two or more leave reasons associated with it. The employee needs to specify the leave reason when applying for this leave.

These leave reasons are

• Leave Reason A– Example Limit of 3 days per year


• Leave Reason B – Example Limit of 1 day per year

Configuration

The configuration is divided into two parts.

• Custom fields


• Rules (take rules and on Save )

 

Add following custom fields in the Employee Time Object Definition

Two counter fields to keep track of number absences taken per event reason (Reason A and for Reason B). The third field is a picklist containing the two event reasons

 

Now coming to the main part. We will create one take rule per event reason

Event Reason A (limit of 3 days per year)

Take Rule

Create 6 variables. The variable 3 and 3P checks if there is at least 1 leave record with status either Pending or Approved and counter value 3 for leave reason A . Similarly, there are other variables to check for counter values 2 and 1 respectively

On Save Rules

 

There are two on Save rules for handling Reason A (attached to Employee Time Object)

1. It saves the counter value for current leave request created based on previous counters


2. The second onSave rule updates the counter values of existing requests in case some of the leaves has been cancelled .

For example consider the below scenario for leaves with leave Reason A

Leave created on March 8 – Counter 1

Leave created on March 9 – Counter 2

Leave created on March 10 – Counter 3

 

Leave on March 9^th is cancelled.  The counter value of march 10^th record should be updated to 2. This is done using Integration center job which we will see later

On Save Rule 1:

As you can see the variables are the same as in the take rule.

Coming to actual conditions

As you can see the conditions in rules are almost like the one in take rule. Just that instead of throwing an error message, we are setting up the counter value. For example, if there is already a leave record with counter value for Leave Reason A with 2 days, we are setting the current counter to 2+ number of days in current request. Another important to note here is the rule is processed only if Original Record is Null (Create Case), since there is a minor limitation with edit case which we discussed earlier

On Save Rule 2 :

This rule is mainly meant for updating the counter value if some of the existing absences are cancelled or declined. Refer to second example discussed above

We have similar lookups as before but just with counter value 2 and 2P, 1 and 1P

Conditions:

 

Similarly, we have other four conditions (with different combinations) below to check the counter value of current request and analyse if other lookups with counter values 2 or 1 are returning Null. This indicates that some leaves have been cancelled or declined .

Handling other leave reason B

This is very straightforward case as limit is just 1. We do not have much complications. There is only one rule needed to track and update the counter. The below is the onSave rule

Take rule for Reason B

With this we are done with the rules configuration.

 

The final piece in this puzzle is the Integration center

Why do we need Integration Center (IC)?

If a leave in between is cancelled or declined, we would need to reset the counter of existing requests with leave reason A. The Integration center ensures that the counter values are always up to date. This can be scheduled by the customer based on desired frequency like daily, hourly, monthly etc

Let’s get to the configuration of IC (needed only for Leave Reason A since it has a limit of 3 days)

Build an Integration Center Scenario by choosing source and destination as SuccessFactors

Choose source as EmployeeTime

In the below step, “target” is also EmployeeTime. Idea is to re-run the rule regularly to see for changes done by employee. Use + button to choose the target.

Drag the External Code field from target to source. Save it.

Next add the following filters and Save

The filters are self-explanatory . We are checking for Demo time type  and with either approved or pending status and with classification as Absence (Note that even Time Sheet uses time types with attendance classification and created the employee time objects)

Finally add a sort criteria

TESTING

 

Create a leave on March 9^th with Reason A. The counter is updated to 1

Create a leave on March 10^th and 12^th respectively. We have counters 2 and 3

 

Now cancel the leave on March 10^th

We have the leave only for 9^th and 12^th for Leave Reason A. But the counter for 12^th is 3 which is incorrect. Now run the integration center. After Integration Center has been run, the counter for march 12^th leave is updated to 2 (Integration center calls the onSave rules to update the counter)

Since counter is back to 2, the employee can now request another leave with leave reason A. If I try to request more than 3 (including current one), I get an error

I hope you find this solution useful to tackle requirements for handling different limits for leave reasons within the same leave type. Of course, the more the limit and leave reasons, the more the conditions and complications. This solution is advisable for requirements where limit and leave reasons are not more than 3.

 

Thanks

Neelesh