There are many countries in the world including Nordic and Middle Eastern where salary disclosure at the JD level, salary negotiations, offer letters and annual salary review happen on monthly remuneration unlike in USA or India where it’s Annual. But the standard SuccessFactors system is designed with annualization across suite where amounts are projected to the complete year to get the annual income. We require to stop the annualization to perform salary review on monthly income
It requires customisation and workarounds to perform salary review on monthly pay in SuccessFactors. There are two approaches which we can follow for EC-integrated templates, the Compensation approach and the EC approach. For non-EC templates, it’s easy and straight forwarded, we are not going to discuss it.
Compensation Approach: As the name indicates, we perform all the changes in the compensation module without touching anything in EC
EC Approach: As you guess, all the customisations are done in EC
Considering the length and complexity of the topic, we’ll discuss this in two parts. In the current part, we’ll discuss the compensation approach, and the EC approach follows in the second part which will be concluded by discussing the points to consider while choosing the suitable approach for your organisation
Before going ahead with the compensation approach, let’s understand few compensation concepts to establish the background of the issue
Compensation Concepts:
For the sake of simplicity, we’ll consider a vanilla version of comp planning with just a set of standard fields. There are two groups of fields, “Impacted Fields” and “Salary Planning”. Impacted fields are the ones which are not used anywhere in the calculation of the final salary but are impacted by the customisation that we are planning to do, whereas salary planning fields are the ones which are used for the calculation of the final salary.
Click to enlarge
Let’s understand how the value for each field derived for the first employee to get the inner workings
There should be only one pay component which should have “Used for comp planning” field either with value “Both” or “Comp”, it can be a single pay component or sum of individual pay components
This pay component would be assigned to the employees through compensation information portlet with amount, currency and frequency
Local currency code: It shows the currency code of assigned pay component -> SEK
Pay type: It shows the frequency of the assigned pay component -> M
Units per year: It’s derived from the annualized factor field of concerned frequency record -> 12
Current pay Rate: It’s the amount that we used for the pay component -> 15000
Current Salary: It’s the product of current pay rate and units per year -> 15000*12 = 180000
Merit: It’s the percentage/amount, of current pay rate, as proposed by manager -> 6%*15000 = 900
Final Salary: It’s the sum of current salary and annualized merit -> 180000+(12*900) = 190800
Salary Range: It’s also called pay range which is selected by the system based on the attributes like frequency, pay grade which are assigned to employee in comp and job info -> 56098 – 70122 – 84147
Comp Ratio: it’s calculated using mid value of pay range and current salary rate -> (15000/70122)* 100 =21.39
Background of the issue:
As you have seen above, the values for current salary, merit and final salary got annualised. Merit’s annualization creates a negative impact on one more area which is budget. The budget is calculated as per the existing setup which is 1.8 % of the current pay rate i.e. 1.8% of 35000 = 630 (for both the employees)
The total utilised budget is calculated as 2100*12 = 25200 as the total merit 2100 got annualised, due to this remaining budget went negative disproportionately which should not happen
Compensation Approach:
Now time for the discussion of core topic, we’ll divide this into 3 steps and after each step we’ll see the output to understand where we are standing with regards to our goal.
Step 1: Do field mappings of mandatory fields
Local currency code, pay type and units per year are the mandatory fields to be included in any template. These fields can work without mapping as well but to get our intend result we need to do the explicit mapping. Please choose the pay component group to which your assigned pay component belongs. Field ids can be different from field names, salary type is pay type.
Output: We still have following three issues
- Pay range is not visible anymore and so is comp ratio
- Current pay rate got annualised and so is merit
- Budget issue is still same as before
Click to enlarge
Step 2: Delete standard current salary and final salary fields
Delete the standard fields and create custom fields for both current and final salary with required mapping and formulas.
Create custom current salary field by mapping the amount of your assigned pay component
Similarly, create a custom field for final salary whose value will be calculated by formula
Output:
- Annualization and budget issues of step 1 got resolved, we need to fix salary range issue yet
Click to enlarge
Step 3: Delink EC salary pay matrix
Salary range for employees picked up by system by mapping the attributes like frequency and pay grade. As the pay type changed from monthly to annual, system couldn’t find any pay range with that frequency, that’s why N/A showing up, as pay range is null comp ratio also showing N/A.
We’ll use pay ranges from compensation as frequency is not mandatory for that. Create salary range table under action for all plans. Then go to the settings of compensation template to update the created salary range table and uncheck the use EC salary pay matrix checkbox guiding system to get pay ranges from this table instead of EC
Output: Everything resolved including salary ranges to perform salary review on monthly pay
Click to enlarge
As you might have seen remaining budget is still negative, its because merit percentage is greater than budget (6>1.8) but its not as disproportionate as before.
That completes the compensation approach where we have made all the necessary changes within comp to achieve our goal of performing salary review on monthly income without hindering the annualization in EC
With that we came to the end of our discussion, please don’t hesitate to post your opinions, queries or issues, would love to know your perspectives and happy to help. You can find other interesting blog posts over here https://community.sap.com/topics/successfactors
We’ll discuss the EC approach in part 2 of this blog post until then stay tuned.
Update: As an alternative, you can even follow the solution mentioned in following blog in accordance with the comments
