This is the second part of the topic “Salary planning without Annualization”. In this blog, we are going to discuss the EC approach for performing salary review on monthly income. I would encourage you to go through the first part https://blogs.sap.com/2023/03/17/salary-planning-config-design-without-annualization-part-1/ to get the context in more detail.

The annualization concept is not specific to the compensation module, it happens across the SF suite including EC. Our plan is not to stop annualization in EC unlike in the Comp approach, being the source to all talent modules, doing that can derail the processes. We’ll create a parallel setup in EC which would be in sync with EC but without hindering EC’s annualization.

It might sound confusing until you see the result. Just to confirm again, here we are not doing any changes that we have done in the Comp approach and the status of the solution is the same as in the background of the issue section of part 1 and now we are going to resolve that issue by doing required changes in EC.

Let’s divide the EC approach into two activities, creating a parallel pay component and creating parallel pay ranges and each activity is further divided into steps. Like in the comp approach, at the end of each activity, we’ll see the output to know the status. Without further due, let’s dive right into the design process

Creating Parallel pay component:

Step 1: Create a new frequency instance 

Go to “Manage organization, pay and job structures” to create the new frequency instance with annualization factor 1 

Step 2: Update the existing pay component of the monthly pay

Use the same tool to update the “Used for Comp Planning” field to “None” for the existing monthly income pay component 

Step 3: Create a new pay component for monthly pay

Then within the same tool, you can create the new pay component by using the newly created frequency along with updating the “Used for Comp Planning” field to “Comp”

Step 4: Create a business rule to default the new pay component 

Go to “Configure business rules” to create the business rule which automatically creates the new pay component for the employees based on EC’s existing monthly pay by copying the amount and currency from existing pay competent but with the new frequency which we created earlier 

Step 5: Assign the business rule to comp info portlet 

Go to “Manage business configuration” to assign the newly created business rule to the comp info portlet with event type OnSave which means it would be triggered while saving the comp info for an employee

Step 6: Grant view permission for the new pay component 

Go to “Manage permission roles” to grant the view permission for the newly created pay component for the concerned roles

Step 7: Assign the new pay component to the employees

If you want to assign this new pay component for a few employees, you can go to their employee profile and re-save their comp info portlet to have this pay component automatically created which you can’t edit. If you want to do it for multiple employees you can use the “Import employee data” functionality   

Output:

Except for the pay ranges, it seems everything is correct including merit and budget.

Click to enlarge

Creating parallel pay ranges:

As the system couldn’t find the pay ranges with the comp frequency instance “CM”, pay ranges are blank. Now we’ll create the parallel pay ranges for comp. 

Step 1: Export the pay ranges from the system

As you can’t export the foundation object data directly from the system, create a table report to export the data as follows. 

Step 2: Create a duplicate file from an exported file 

Once you have exported the file, you can just create a duplicate copy of the file using the save-as option and then update the columns “Pay Range ID” and “Frequency” 

You can just add the prefix “Comp” to the existing ids to serve the purpose and replace the existing frequency values with the value “CM”

Step 3: Import the newly created file 

Go to “Import foundation data” to import the newly created file. Rest assured that these pay ranges wouldn’t impact EC’s functionality as the frequency is specific to the comp 

Output:

Now you can see the pay ranges in the worksheet. 

It is recommended to delete and relaunch the worksheets after each activity to see the required output otherwise you can do all the changes in one go and launch them. You can prefer this approach if you want the templates to be purely EC integrated. If I can draw a parallel between both approaches, both are good to meet the end goal as long as you implement them correctly and one is not better than the other.

There are many variables including timelines, expertise, cross-functional cohesiveness across teams and project status which can be considered to decide the approach. For instance, if a company has an EC module gone live before the implementation of the compensation then the Comp approach can be better considering the workload of the EC approach as it needs to re-import all the pay ranges and comp info for all the affected employees whereas if both the modules are scheduled for go-live in one go then EC approach can be better as these changes can be included in the project scope without the need of re-work later.

If you are still with me, thanks for taking the time to go through the post. Considering the scope, I have not added complete “How to” details for each of the steps, if you need any assistance, you can comment on the same and don’t hesitate to suggest improvements or future topics, see you soon.

Update: This solution is developed by keeping the purpose of using standard fields in comp to meet requirement without doing any customization