Salary Planning Config Design without Annualization – Part 1

[Venkatesh_M]

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. We’ll discuss the EC approach in part 2 of this blog post until then stay tuned.

[xavierlegarrec]

Hi whenkey

we have a standard way in the product to build this requirement, please see situation 1 from the blog below (example and also recording on how to switch from annualized planning to rate type planning).

To keep budgets in non annualized amounts with situation 1  we can simply based them off a custom field where we multiply current pay rate by budget % assigned from a lookup table.

https://blogs.sap.com/2020/07/21/types-of-planning-and-formatting-in-compensation-the-case-of-hourly...

All the best,

Xavier

[Venkatesh_M]

Hi xavierlegarrec ,

Thanks for the suggestion but unfortunately it doesn't work for the issue I've specifically addressed which is the "Total" field of budget table

I agree that we can make use of custom fields for budget, current salary or even final salary etc. but I believe "Total" field can't be customized, please let me know if its otherwise.

Based on the setup of situation 1 in your blog, it can work for other fields as you shown but "Total" field still gets annualized

Regards,

Ven

[xavierlegarrec]

Hi yenchech

Yes it is possible, please see this recording (without sound) I just made to show you :

https://youtu.be/puGOUsfh4ZY

The only thing we can't remove (as can be seen in the recording too) s the fact that the budget always shows in Functional Currency by design due to the possibility of having people in different local currencies.

The reason budgets are annualized in leading practice even in rate type planning is because rate type planning allows us to have people with different frequencies on the worksheet : Hourly, Monthly, etc.. But if all of the employees are monthly then yes you can change your budget configuration to reflect the one and unique frequency used by these employees.

All the best

Xavier

[Venkatesh_M]

Hi xavierlegarrec

So basically instead of using standard merit field directly, you have created a custom field based on standard merit field and used that as a base for budget utilization to control the annualization, hope we are on the same page

 

Regards,

Ven

[xavierlegarrec]

Hi yenchech

Correct, you can see it all in the recording. Please let me know if you need the xml.

All the best

Xavier

[Venkatesh_M]

Hi xavierlegarrec

 

Though its not a standard solution but more of a workaround, its good enough to be considered.

People might find this conversation helpful if they ever need this scenario

Thanks for contributing to the blog

 

Regards,

Ven

[xavierlegarrec]

Sure, it’s fine to keep it here but I think the following sentence should be removed or rephrased as per my demonstration in the recording (our product gives customer the choice in standard) “But the standard SuccessFactors system is designed with annualization across suite where amounts are projected to the complete year to get the annual income.” The standard way of building this requirement takes a few minutes only and is fully doable from the Admin Center.

All the best

Xavier

[Venkatesh_M]

I understood your concern but i didn't mention anywhere that its not possible to do in SF.  Its conveying that by default annualization happens and we need to do customization to make it happen on other frequency. I've added updates to the posts at the bottom.

Regards,

Ven

[pmacgovern]

Hi

I have to agree with Xavier here. There is no reason to go to the extent you are in order to make pure "monthly" planning happen.

While you are correct in the module wants to "annualise" all values, there is an alternative. The other choice is what I call "periodic" planning. When a template is placed in to periodic mode, the assumption is that the client will be using many different frequencies. Some people may be planned annually, others monthly and then others hourly. Each salary would then be shown in the module as it appears in EC, as I have shown in the screenshot.

However, since Compensation doesn't know what range of salaries could be sent to it, for certain fields, it has to fall back to the only thing it can to reconcile - the annualised value. This is most obvious in "total" rows. Just like how total rows are always shown in the functional currency, they are also shown in the annual amount, if it is a 'standard' column.

The solution above uses the "meritTarget" concept. I mapped curSalary to the pay component group and hid it. I then mapped "meritTarget" to the pay component, rather than the group. I modified the XML to set merit-target to use "Target". Then, I made a custom column called "Increase" and used it and meritTarget as the two components for the budget.

I think this is a MUCH simpler method and significantly closer to best practices. It even uses the EC pay ranges.

As it stands, I don't think SAP can recommend either of your methods.

Phil

[I844293]

Hi Venkatesh,

As mentioned by Xavier and Phil above, this is already supported as standard offering. If you look at the example from Phil, the configuration can easily be enabled by pointing merit target as the base for merit calculation.

Thanks,

Gurusimran

[Venkatesh_M]

Hey, 

Sorry for the delay, I was awaiting a few details from SAP. I just wanted to make a few things clear for the benefit of the community. Being an SAP employee does not make your workaround SAP's standard solution as long as its not part of SAP’s official documentation for a larger population. More importantly, this is not SAP’s standard offering or part of SAP’s standard solution as being claimed. Here is confirmation from the SAP support team approving this 

The solutions which are shared by me are audited by the SAP CQC team and approved. 

Moreover, this platform is not to share ONLY SAP recommended solutions for which there are other platforms handled by SAP specifically. The purpose of this platform is to share our experiences and learnings to learn from each other instead of judging others solutions or canceling each other. Gracefully, I've acknowledged the solution provided by Xavier and even included it in my post but stating SAP would not recommend my solutions does not hold the community spirit. 

[xavierlegarrec]

Hi yenchech

It is unfortunate that there was a misunderstanding with support.

However the way I built my budget (I won't talk about meritTarget solution proposed by Phil as it less documented) and made it work myself is ABC of Compensation module. It looks to me like you had an issue but didn't research yourself or tested much and instead asked support and took their word for it. That is not really how I see compensation consulting especially when the workaround you have in mind is so impacting to other streams. We should validate with several sources, including SAP Questions, existing SAP Blog posts (the blog I referenced above) and most importantly the Partner community where I don't see any question raised.

Our goal as a community of implementation partners is to make the best designs for customers so they are confident and empowered in using SuccessFactors.

Your design is highly impacting in a wrong way because it involves adding new pay components to Employee Central that are not needed other than for the Compensation module and could have impacts on Payroll replications. It also creates a lot of confusion for new system administrators and it prevents customers from using the existing EC Pay Range in the integrated Compensation template. Not to mention the heavy maintenance of business rules whenever changes to Pay Components need to take place. It is an administrative nightmare. Sometimes when there really is a product gap the latter is acceptable because we don't have any other choice but here it is not.

[Venkatesh_M]

Hi xavierlegarrec

Thanks for 101 on consulting, all the resources have been utilized to make the solution. When you know your solution in and out, you can analyze deep enough to make it as smooth as standard solution. Btw your blog doesn't include the solution, it includes standard settings, we discussed the solution over here, i rest my case with this 

Thanks,

Ven