Types of planning and number formats in Compensation : the case of Hourly employees
In Compensation (Salary Review) templates of SuccessFactors we can chose between 2 types of planning :
- Option 1 (Periodic planning) : allow planners to enter their recommendations in each employee’s pay frequency (monthly/semi-monthly/hourly, etc..) in which case for an hourly employee making $44.5/hour the planner will see $44.5 in the “Current Salary” column of the worksheet and if the planner enters a 3.5% increase the calculated $ amount in the “Merit” column will also be in the employee’s pay frequency – here hourly as $1.56 (44.5*3.5%). Please note : in this setup, guidelines will always be divided by the value retrieved in the Units Per Year standard field.
- In this type of planning, a different format can be applied based on the pay frequency or the currency of each employee. For example in the same worksheet a semi-monthly employee can be planned without decimals (even if the pay component in EC has decimals) but an hourly employee can be planned (and published back to EC) with decimals.
- To apply the different format based on the pay frequency in this type of planning, we need to navigate to “Set Number Format Rules” in our template and configure the following new custom Money format (and apply it to any Money custom column. Standard columns will pick it up automatically) :
- Option 2 (Annualized Planning): allow planners to enter their recommendations in annualized values for all employees in which case for an hourly employee making $44.5/hour the planner will see $92,560 (44.5*2,080) in the “Current Salary” column of the worksheet and if the planner enters a 3.5% increase the calculated $ amount in the “Merit” column will be also be annualized as $3,239.6 (92,560*3.5%).
- In this type of planning, a different format CANNOT be applied based on the pay frequency or the currency. Only one Money format and one Amount format can be set for the whole template for all employees.
Please watch the video below for additional explanations on how to configure Option 1 and Option 2 above :
In this post, we will look at the following requirement : have all employees (including hourly employees) planned in Annualized values without decimals but allow the new/reviewed pay rate of hourly employees (and only them) to be published back to EC with two decimals.
The problem in this case is that in order for all employees to be planned without decimals we must set the one and only Money format for our template in “Set Number Format Rules” to never show decimals as per the screenshot below :
This leads to issues when publishing back the reviewed pay rate for hourly employees with 2 decimals since the value published back can only be stored in Money format or Amount format columns.
Here we have no other choice but to walk on a fine line between the Money and Amount columns formats.
We need to keep the Money format from the above screenshot (no decimals) but configure all columns of our publish back section in Amount format and set that format to be #,##0.## which means it will display 2 decimals when found.
Then we need to configure the publish back columns of our template the following way (and use a Round(‘halfUp’,…) formula in the Final PayRate to Publish) – click to zoom in :
Once we have successfully created our Publish back section columns as per the above screenshot, all we need to do is make sure the column “Final PayRate to Publish” is correctly added to our publish back xml code section (this step can still only be done in the xml of the template) :
Option 1 : Periodic Planning (also called User Rate Planning)
- This option is configured by not defining any EC mapping for the standard columns “curSalary”, “localCurrencyCode”, “salaryType” and “unitsPerYear”. By doing that the worksheet will automatically retrieve (if data migration was done correctly) for each employee the value of the Pay Component flagged (in Admin Center > “Manage Organization, Pay and Job Structure”) as “Use for = Compensation” that is stored in their compensation portlet.
- To publish back to EC we then need to map the standard column “finSalary” column to the xml publish back code snippet.
Option 2 (Model Company approach) : Annualized Planning
- This option allows more flexibility to capture an employee’s base amount for merit increase (it may differ by country) through the use of Pay Component Groups in Employee Central. To configure option 2, all we need to do is map the standard columns “curSalary”, “localCurrencyCode”, “salaryType” and “unitsPerYear” to the Pay Component Group calculating the Annualized Salary for all employees in Employee Central.
- To publish back to EC we need to add 2 money or amount type columns to our publish back design section :
- A first one called “Current Pay Rate” where we retrieve the current pay rate of the employee from EC (= the value of the pay component flagged as “Use for = Compensation” in each employee’s compensation portlet in EC) : this is done by setting to EC Mapping for the column to “EC Category = Compensation” and leaving the 2 other dropdown lists blank.
- A second column called “Final PayRate to Publish” with the following formula : “finSalary/(curSalary/currentPayRate)”.
- Finally map the “Amount to publish back” column to the xml publish back code snippet.
Worth mentioning that we need to recalculate annual salary on worksheets based on publish final rate column and hide standard final salary fields otherwise data won't match.
E.g., from your worksheet screenshot
46.15 * 2080 = 95992 which doesn't match standard final salary column on worksheet (95985)
It also gets tricky when you are using salary rules as benchmarks are calculated based on standard final salary which doesn't match re-calculated custom final salary.
Yes ! thanks for this input. I'm preparing a post on the topic of "how to keep Comp - EC and statements all aligned on the Annualized Salary" I recently found a workaround for a customer that was annoyed by the few cents differences between statements and EC. It involves hiding specific standard column but the give and take is acceptable.
Hi Xavier, I am also very interested in this topic. I have a customer currently that is requesting a way to publish back the annual salary vs the pay component wage amount for this same reason. The rounding and the differences between statements and EC is a big discussion. Thanks!
Could you please advise how the first option can be configured? I need to have the monthly salaries in the Salary Review, not the annualized values. I read that the Compensation template from SuccessStore is set to annualized values.
hi Tatiana Caraiman
You need to leave curSalary standard column blank on the mapping at the bottom and automatically the worksheets upon launch will retrieve the data from the Recurring Pay Component in EC flagged as "Use for Compensation = Compensation" in its settings.
Thank you, Xavier Le Garrec .
How about if the "Used for Comp planning" field is missing in the the Recurring Pay Component? Is there something that could hide this field?
Below current Pay rate column I created custom column and didnt mapped with any EC settings.
as you said in previous blog to make all Ec settings to null
If you leave curSalary and localCurrency, salaryRate and unitsPerYear blank the forms will automatically pull which ever paycomponent an employee has on the profile that is marked as Use for Compensation = "both" or "Comp" in its settings.
How current salary would appear in worksheets in this case since no mapping has been defined for custom column created as current pay rate. it would come with zero amount.
Is this possible to have a meeting with you to show the necessary settings in the system
Thank for all help
Hi Ritanshi Bansal
Please make sure to review the recording I inserted above as I don't think you have configured Option 1 correctly.
All the best,
I have a requirement to display Hire Date in yyyy/MM/dd format. This date is in MM/dd/yyyy format as per standard and is pulled to template from EC. I created a custom column and passed the hire date field in the formula using toDate function, but it does not work.
Any thought how to achieve this.
Hi swagatika panda
Xavier Le Garrec - thank you so much for this tutorial - you're my VRP and CMP hero as it's another time I'm using your pro tips to tackle some more complicated requirement from the customer.
Thank you for the comment ! it's always nice to know when the information we share is useful.
Hi Xavier Le Garrec ,
For my recent project requirement, I have surfed several SAP blogs as well as partner community and found this post should be the proper place to ask for your experience sharing, hope you still monitor this post (I think so :D).
My recent requirement:
I did think to do it in several ways but seems the below is my final one:
Would you mind sharing if my solution is working (or any other 'standard way' can be adopted)? It seems to me my solution is too complicated but the requirement is common (ie. benchmark/guideline on TCC but merit on basic salary).
Hi Ka Shun Wong
It is a little tricky indeed.
Do they care about having the compa ratio colors ? because the easiest solution in my view would be to bring over the pay range min-mid-max in three separate columns (the standard ones : payGuideMin, payGuideMid, payGuideMax) and recalculate the Comparatio and/or the range penetration with custom formulas in custom fields.
You can map one of your columns to the PCG used in EC for Compa Ratio (let's say this column is called "customPCG" and then the formulas would be :
This way they don't have to maintain pay ranges in a lookup table when it already exists in EC...
All the best
Hi Xavier Le Garrec ,
Thanks for your quick response and such a great idea! I was stuck to look at the pay range and benchmarking as a whole and forgot that the payGuideMin/payGuideMid/payGuideMax can be brought separately in recent releases.
The color feature cannot be used no matter how (and my customers tend to display quartile (Q1-Q4) instead of actual figure to planners, so it is all fine.
Your solution reduces the configuration workload/error (they don't have to maintain 2 tables at all).
Thank you very much.