Making employees recently increased in EC ineligible in compensation worksheets

[xavierlegarrec]

Introduction

In this 30 minutes recording we look at two different ways to make recently increased employees in EC ineligible in Compensation worksheets (before or during the cycle) which is not possible with Compensation eligibility rule engine (as mentioned at the bottom of this blog).

 

Designs

This recording covers the two following designs :

• The leading practice of adding a field called "Date of last salary increase" in EC Comp info which will be populated on save (see design details here) of an increase on Base Salary.
  
  
  • This design which is recommended when Compensation is implemented at the same time than EC has a major drawback for customers trying to implement it after EC is live which is that it doesn't come with prepopulated current data for the field (for example if the field gets added to CompInfo only on February 15 for the purpose of launching the cycle on March 1st and the requirement is to capture all changes to Base Salary since January then the customer will have to make data loads for all employees in Comp Info as the new field doesn't come with current data situation).
  
  
  

• An alternative which involves the creation of a custom objects with business rules that gets fed from Integration center and which will allow us to capture this information even if the actual salary cycle is already live or is happening imminently and without any data loads.

https://youtu.be/5IMmy9L7FbU

Please note that to capture the case of employees going from FTE = 1 to FTE = 0.75 (and getting their salary adjusted in the pay component as a consequence since we store actual salary data in EC), the below tweak is needed in the Set_AnnualizedSalary rule: 

Other complex business cases related to this topic

• In case a customer must have the Compensation template EC effective date be April 1st for example (no flexibility for change) but for specific business reasons they can only launch Compensation worksheets after April 1st and would like to grey out employees receiving an increase in EC after April 1st then we can use one of the custom01 to custom15 columns of the UDF to store the Date of last salary change from EC with an HRIS-sync. In this scenario when the salary change gets approved in EC with an effective date of April 5 for example then the HRIS-sync immediately feeds that date to the UDF which we can then pull into a worksheet column used for eligibility purposes (field-level eligibility feature documented here).

• In case we need to display more information than just the "Date of last Salary increase" for employees receiving increases in EC after April 1st (to use example above) then the only option is to go through an MDF + Integration center design as documented below (credit Andres Carter, SAP).

 

 

 

--

All the best,

Xavier

 

 

 

(If you found this blog useful please consider giving it a Like)

[vinkamath]

Hi xavierlegarrec

Thanks a lot for these blog posts. These are really insightful and show how we can leverage the MDF objects + integration center in Compensation.

Thank you

Vinod..

[sbsrajendran]

Hello Xavier,

Thank you for the detailed explanation on the solution and it really helps. Do we actually need the effective date in the object? why don't we create the custom object as non-effective dated? As shown in the solution we are hardcoding the effective date and what will happen for the upcoming year's comp process?

Please advise.

[xavierlegarrec]

Hi sakthi1991venki

non-effective dated object would work here fine as well for my proposed workaround to the leading practice field.

Most compensation eligibility rules have dates in them that need to be edited from year to year no matter what.

Does this answer your questions?

All the best

Xavier

[ErikaT]

Hi Xavier,

 

Nice blog!

We tried to set up the same logic. However we realized that Previous Effective Dated Record.externalCode.Employment Details.Compensation Information ☰.Annualized Salary is always NULL. We would  like to add the increase % in the MDF object. Any idea how to solve this?

Thanks!

BR, Erika

[xavierlegarrec]

Hi erika.toth2

It worked fine for me in my recording so I am not sure how I can help.

Did this test user ever get a salary change ? Did you create the same On Save rule than in my example ? Could it have to do with the effective date of the record you are using ?

Thanks

Xavier

[ErikaT]

Hi Xavier,

The test user has a salary change.

I created the same On Save rule as in your example. I only wanted to add the increase %

The annualized salary of previous record is NULL:

The expression 'PreviousObject.externalCode.employmentInfo.compInfo[0].AnnualizedSalary' is considered to be NULL.

 

Thanks!

BR, Erika

[xavierlegarrec]

Hi Erika,

Are you using a record effective data aligned with the template effective date ?

Maybe it isn't Annualized Salary in your environment that holds the actual annualized salary for most employees ?

I will retry in a dev environment used by customers to see if I come across your error message.

All the best

Xavier

[ErikaT]

Hi Xavier,

 

I re build the same solution in sales demo environment and also there I face the same issue.

Last salary change screenshot

 

The expression 'PreviousObject.externalCode.employmentInfo.compInfo[0].AnnualizedSalary' is considered to be NULL.

Thanks if you check it.

Kind Regards,

Erika

[Svetlana92]

Hi Xavier,

We also tried to set up the same logic and unfortunately got the same issue as ErikaT in the comment above: Previous Effective Dated Record.externalCode.Employment Details.Compensation Information ☰.Annualized Salary is always NULL. In the logic you described in the video, the previous record is compared with the current record not to be equal and since the previous effective record always gives NULL and the current record gives a value, they are not equal and hence it could be the reason why the logic is working.

As per our requirement, the last salary change should always be an increase (if there is a new record in the compensation portlet but no salary change or a decrease, we do not consider it) for an employee to be excluded from a worksheet, but when we use ">" instead of "not equal to" in the same business rule,  the rule does not give any result (since it's not possible to compare NULL and the value).

Is there any other way that you could recommend to find a last salary increase date?

Thank you in advance.

Kind regards,

Svetlana.

[xavierlegarrec]

Hi @Svetlana92 

Taking a look at this today and will update.

[xavierlegarrec]

@Svetlana92 @ErikaT 

You are correct, something is not working anymore as it used to. 

I found a workaround that I will document tomorrow and share here.

I also asked a colleague if there is a way with standard business rule to access the value of the previous PCG as of a specific date.

All the best

Xavier

[xavierlegarrec]

Hi @Svetlana92 @ErikaT 

I documented the workaround I found in a new recording (link updated in the article above).

All the best

Xavier

[Svetlana92]

Hi @xavierlegarrec,

Thank you so much for your quick response and for documenting the solution! 😊

[karingrunwald]

Hi @xavierlegarrec 

Thanks a lot for your blog posts. I see you replaced the old video with a new one in the last week. I have some questions on this.

I have some questions:
1. In the previous video that you replaced by the latest one on Youtube, you scheduled the IC as a daily job.
Why has this changed now in your tutorial? I have some doubts if we really catch all the employee salary changes, e.g. What about oncycle increases? E.g. CP planning for the Managers has started in February and there occurs also a salary increase during the cycle while the forms were already launched in February (not considering the salary change). Also when there are new employees after running the IC job, they will not show up any value in this field.
In my opinion the MDF Object has to be updated on a daily basis with the updated value of the last salary change (as described in your previous video).

2. What about future dated records (salary change). The date of the last salary change in the MDF object does not consider this in my testings. Example: Last salary increase in the past was August 1st, but there is a future dated record in Feb. 2025. The MDF object gets feed by the IC with the date from August.
Is there a way to handle this?

3. You define the MDF Object field "date of last salary increase", in your rule you are comparing the annualized salary with the previous annualized salary being "not equal". Not equal also includes any change, not just increases but also decrease? How to handle this?