A compensation form can be configured to include different currency views
- Functional Currency
- Planner Currency
- Local Currency
- Other (currency view)
The functional currency is the currency used by default to calculate values. If you are a company in the U.S. your functional currency might be set as USD. Go to Manage Compensation Plan in Admin Tools > Select the plan template > and under Template Information you can set the Currency.
You may also have Planner or Local Currency options on the compensation forms to allow the user to convert values into these other currencies. For example, if your functional currency was USD, but the user is in the UK, selecting Local Currency allows the user to now see values displayed in their local currency and not USD. (Requires conversion tables are set up)
To enable or disable the available options on the compensation form an xml change needs to be made to the template code. Each currency type can be set as true or false. Please submit a case with Customer Success to have your template updated.
<comp-currency-view includeFunctionalCurrency="false" includePlannerCurrency="false" includeEmployeeLocalCurrency="false"/>
Functional Currency Code and Base Currency View
Functional Currency Code (functionalCurrencyCode)
- Determines currency shown in certain views and reports. Not necessarily the currency that is stored in the database. For example, for a U.K planner their local currency is pounds, but in Functional Currency view the Salary may be displayed in USD if that is the Functional Currency.
Base Currency View (baseCurrencyView)
- Determines how currency values are stored in the database and how currencies are converted.
Default is "functionalCurrencyCentric".
Options: functionalCurrencyCentric and localCurrencyCentric
- So for a client setting their base case currency to USD then all data needs to first be converted to USD and loaded. For example people in U.K would first need to convert all their data to USD.
BaseCurrencyView = "functionalCurrencyCentric"
- Values stored in the system will all be in one currency, so salary passed in the SALARY column on import file must be in the same functional currency for everyone.
- Eliminates confusion around budgets, salary pay matrix (pay ranges) setup, and budget assignments because all are based on the functional currency.
- Because the salary is not stored in the employee's local currency there may be rounding variances due to currency conversion. Please reference the Currency Conversion Tips document on Twiki before you discuss the possibility of rounding variances with a customer.
- Reports exported to Excel (Rollup, Executive Review, etc.) and the Aggregate report will show the currency in the functional currency.
BaseCurrencyView = "localCurrencyCentric"
- Values stored in the system are in the employee's local currency, so salary passed in the SALARY column on the import file must be in the employee's local currency.
- Possible rounding variances when conversions take place on planner or functional currency are more acceptable since the employee's local currency amount is preserved in the database.
- General Note: Using localCurrencyCentric is only an advantage if the customer wants the local currency to be the "official" planning currency.
- Can cause confusion around budgets, salary pay matrix (pay ranges) setup, and budget assignments because all are based on the functional currency.
- Reports exported to Excel (Rollup, Executive Review, etc.) and Aggregate report will show the currency in both the functional currency and local currency.
Currency and Import File
Two columns on the import file affect the currency/currency conversion in the compensation module:
- All other columns that end in _LOCAL are obsolete and no longer used in currency conversions.
- If using functionalCurrencyCentric the SALARY column should be populated with salaries in the same currency...the functional currency.
- If using localCurrencyCentric the SALARY column should be populated with salaries in the employee's local currency.
- It is always a good rule of thumb to populate the LOCAL_CURRENCY_CODE with a value...even if the value will be the same for every employee.
- Note: This solution may contain xml code or ather technical attributes. We provide this to help those clients using the Self-Service Tool to better understand the features discussed from a technical aspect. If you are not familiar with this tool or the technical references made, please know that you can engage SuccessFactors Experts for all your configuration needs.
Always sort in Functional Currency
- Planner wishes to sort new salary from smallest to largest amount, and employees are paid in different currencies. When the plan template setting is enabled and the template is local currency centric, the system will sort correctly.
- Browse to Admin Tools > Managing Form Templates and select the template of interest > Settings > Always sort in Functional Currency
- Planner may sort currency fields (curSalary, finSalary, salaryRateFinal, totalComp, bonusAdjustment, bonusTotal, bonusTarget) on the worksheet and in executive review when plan template is local currency centric
- This is not enabled by default. If worksheets are in multiple currencies, this setting can be enabled.
Other Currency View in Variable Pay
When would you use the "Other" currency view in your varpay program?
It can be used when reviewing currency at the assignment level. Consider the following:
- Program’s functional currency is EUR
- Employee’s current currency is USD
- Planner’s currency is USD
- One of the employee’s assignments is CHF
Without the Other view, it would not be possible to see the bonus amount in CHF for this employee. You would not see it if using functional, employee local, or planner view.
KBA , sf compensation currency data , LOD-SF-CMP , Compensation Management , How To