Using Standard Eligibility Flags in an EC-integrated Compensation Template


Introduction

Before the introduction of Employee Central integration, eligibility was controlled either through basic rules entirely within the Compensation module or via the upload of TRUE/FALSE values in the UDF. When integrating with EC, most think that the only way of controlling eligibility is using Business Rules. While Business Rules do allow for much more complex eligibility conditions than were previously possible, they can add significant time to processing. In addition, many clients prefer determining the eligibility externally and directly uploading a TRUE or FALSE value. This method provides more precision and is much faster (albeit at the expense of externally creating the upload).

With a recent release, the Product has been enhanced to allow for the Compensation Home UI to directly modify the eligibility fields. I combined this functionality with the ability to map columns to MDF objects to allow an external object to control eligibility in an EC-integrated template without the processor-hungry and complex-to-maintain Business Rules.

Method

The first step is to create an MDF object to hold the eligibility fields. I followed this excellent blog post (https://blogs.sap.com/2020/07/13/compensation-planning-simplified-with-mdf-integration/) to create the following object:

The highlighted fields are the custom fields added to control the eligibility. Their names are arbitrary, but my intention was to replace the function of the UDF fields COMPENSATION_ELIGIBLE, COMPENSATION_SALARY_ELIGIBLE and MERIT_ELIGIBLE, so they were named appropriately. This method is not limited to just those columns; any eligibility field may be mimicked using this method.

I also permissioned the MDF appropriately.

In Compensation Home, I opened my EC-Integrated template. For this example, I used the starting condition of “No Employees are Eligible” (which is my personal preferred starting point for new implementations). However, the method also works for the other starting position; all that changes is loading FALSEs rather than TRUEs.

I then went to Design Worksheet and chose to modify the “Eligibility Fields”:

Once there, I clicked on the “Add Eligibility Column” and added all three available options. My template just used the merit column; had I used lumpSum or extra, then there would be more options.

This created three fields:

I clicked on each to map them to the appropriate MDF fields:

I did something similar for each of the other eligibility fields (for this example, I also created three regular custom string columns to show the values loaded – which could then be used for formulas, if so required)

I then went to Manage Data and created a record for one of my test users:

The expectation is that this employee will be eligible for the worksheet and the salary tab, but ineligible for the merit increase. Of course, this data may be uploaded with a simple CSV file. Consult other documentation on how to do that.

I then created a worksheet for my test user’s manager. Note: there are no compensation rules and I never “applied” eligibility:

Here is the worksheet:

Only the one employee is on the worksheet (as I created an MDF object just for that one user, so all others are ineligible) and you can see the Merit fields are greyed out as the employee is ineligible for Merit.

So, what if this is incorrect?

If Megan was supposed to be eligible for Merit, I can go back to Manage Data and modify the values:

Note: it would be possible to upload changes as well.

Afterward, I return to Compensation Home, open the template, and navigate to Manage Worksheets. There, when executing the “Update all worksheets” action, I choose just “Update worksheet to reflect any employee’s eligibility changes” but NOT “Reapply defined eligibility rules before updating worksheet”:

Of course, it would be possible to update a specific worksheet, but the point here that there are no rules to be reapplied, greatly reducing execution time of the update job, which often is a significant performance bottleneck.

Custom Field Eligibility

Unfortunately, this method doesn’t work for any custom editable fields which have the “Enable Rules Eligibility” flag chosen. It works only for the “Standard” fields and the general Compensation and Compensation Salary Eligible flags. If your template includes custom fields with eligibility, I suggest that you stick with the same method with a few extra steps. I would:

  • Add another field to the MDF for the custom column and load TRUE or FALSE
  • Create a business rule that checks this field
  • Add the Business Rule to the Eligibility section of the template

From here, you would need to “Apply” eligibility rules before creating worksheets and when updating, but by eliminating rules and keeping other rules simple, the execution time is still reduced.

Conclusion

By mapping an MDF object directly to the standard eligibility flags in an EC-Integrated Compensation template, it is possible to mimic the non-integrated convenience of loading UDF columns for externally determined eligibility. Doing so significantly reduces processing time of updating worksheets, as no eligibility rules need to be processed. This method can be combined with the recent feature of controlling eligibility of custom fields, albeit with the addition of simple rules.