2084594 - Currency - Currency Conversion Tips - Compensation

• Compensation Planning supports use of multiple currencies. This is a great feature for customers, but does have the potential for adding a level of complexity to what can already be fairly complex calculations. However, proper
  configuration can minimize issues, and an understanding of the possible issues will help explain those cases that do appear.
• Advice on maintaining precision?
• What is best decimal precision?
• How are values affected when being converted between currencies?

SAP SuccessFactors Compensation Management

Roundoff Effect

A brief discussion of roundoff effect as it relates to currency conversion will be useful for context.

Whenever calculations like multiplication or division are performed using a finite number of digits (for example: 5 decimal places) some degree of roundoff ‘error’ or effect is inevitable.

Example A:

1 USD = 43.99775 Indian rupees. A Compensation form is generated that has USD as Functional Currency and Indian rupees as a Local Currency. The money format is set to utilize no decimal places (i.e. $1 instead of $1.20)A planner enters a merit increase of 40,000 rupees, then switches to Functional Currency. The system calculates 40,000 / 43.99775 = 909.137399 USD. This is then rounded to 909 USD as per the money formatting, and if the form is functionalCurrencyCentric, 909 is what is saved in the database.

Now, if the user switches back to Indian rupees, the system will calculate 909 x 43.99775 = 39993.95475. This value would be rounded to 39,994 rupees in the form, for an observed discrepancy of 6 rupees or approximately 0.015% error. An error of 0.015% is relatively small but generally not acceptable when dealing with compensation. However, "Example A" represents a ‘worst case’ scenario as both the conversion rate and the rounding configuration for money are both what would be considered on the more extreme ends. Rounding money values to no decimal places is often requested for convenience, but due to its impact on currency conversion it is not recommended.

Recommend at least 1 and preferably 2 decimal places of precision for money format in Compensation forms.

Example B:

Same setup as Example A except that the money format is set to 2 decimal places.

A planner enters a merit increase of 40,000 rupees, then switches to Functional Currency. The system calculates 40,000 / 43.99775 = 909.137399 USD. This is then rounded to 909.14 USD as per the money formatting, and if the form is functionalCurrencyCentric, 909.14 is what is saved in the database.

Now, if the user switches back to Indian rupees, the system will calculate 909.14 x 43.99775 = 40000.114435.

This value would be rounded to 40,000.11 rupees in the form, for an observed discrepancy of 0.11 rupees or approximately 0.000275% error.

It is at this point that the option of localCurrencyCentric template configuration can be raised. Using that option would allow the preservation of exactly 40,000 rupees by saving that Local Currency value in the database rather than the Functional Currency value in USD. However, the important decision is based on whether the customer will primarily plan compensation in the Local or Functional Currency amounts.

Note: LocalCurrencyCentric configuration is useful but recommended only when absolutely necessary as it introduces the added application complexity of storing values in many different currencies versus just one.

Currency Conversion Rate Tables

Compensation Planning stores currency conversion rates in tables that are importable via Admin Tools. Multiple Rate Tables can be imported into a company instance, and each Compensation template can be configured to use one of these Rate Tables.

When setting up currency conversion rate tables, there are several major points to consider:

Conversion rate storage precision.

The rate tables support only 5 decimal places of precision for storage (5 decimal places is the maximum for all Compensation Planning numerical or currency storage). For example, a EUR-GBP rate should be imported as 0.74477 instead of 0.74477426 as the system would only store up to 5 decimal places.

Note: The recommendation is to use conversion rates with a precision of 5 decimal places: more would not be useful and less would be less precise.

Currency conversion rates cannot be inferred.

• Some implementations use many different currencies. As a result, many possible scenarios of currency conversion are possible. For example, if only three currencies are involved: A, B, or C… there could be a case where a user switches currency views in a way that results in: A to B, B to C or A to C. What can happen is that only rates for A to B and A to C are defined in the currency conversion table. Then, if the application is asked to convert from B to C, it will actually do nothing and no warnings will be displayed.
• Be sure to define a conversion rate for each possible currency combination.
• Tip: Use this online calculator to see how many rates you would need: http://www.analyzemath.com/Calculators_3/combinations_calculator.html
• It looks for an entry of ‘n elements taken r at a time’. For our purposes read this as ‘n currencies taken 2 at a time’.

Currency conversion rates are ‘bi-directional’.

• A common mistake is to define two rates for any pair of currencies. For example, the EUR-GBP conversion rate could be 0.74477. We often see another entry in the rate table for GBP-EUR as well, which may be a close reciprocal of the EUR-GBP rate, like 1.34270. The problem here is that 1.34270 is not an exact reciprocal of 0.74477 : 1/0.74477 = 1.342696402. When two rates are defined in this way, the system will actually use the rate that begins with the ‘starting’ value, so a different rate would be chosen if converting from EUR or from GBP. However, if only one rate is defined, the system will find that rate and use it for either direction of conversion. This is preferred as it minimizes the effects of rounding as described above as well as avoids the possibility of human error when defining an A-B as well as B-A rate.
• Be sure to define only one conversion rate per currency pair: If you have EUR to USD there should not be a USD to EUR rate.

currency, conversion, rates. compensation, table, roundoff, effect, planner, merit , KBA , sf compensation currency data , LOD-SF-CMP , Compensation Management , How To