Currency Translation Rule

Currency translation applies to both financial and legal consolidation models to which a corresponding rate model has been referenced.

When performing currency translation, different exchange rates such as average and period end rates, as well as formulas, are applied. A currency translation rule contains the necessary rates and logic for a unique account rate type. The account rate type must exist in the Account dimension in order to be triggered. However, you can create and name the currency translation rule first, and then assign the RATE_TYPE in the account dimension to the accounts to which it relates. When currency translation runs, it translates each account in accordance with the rules defined for the account rate type which has been assigned to that particular account.

If you need to store data in the local currency of the entity and also convert it to one or more reporting or group currencies, a currency type dimension must exist. In addition, the system must access a rate model that stores the exchange rates used for the automatic translation. The following list provides a summary of the environment requirements to support currency translation:

• The environment must include a rate model where exchange rates are stored. You must assign this rate model to any model that utilizes it.

• The model itself must include a currency type dimension and possibly a Group dimension.

• The Currency (R type) dimension must include the properties:

  • REPORTING, whose values are Y or blank

  • CURRENCY_TYPE, whose values are R for Reporting Currencies, T for transaction currency, or L for local currency. The value G for group currency is used only if the currency dimension is also used to manage groups. This value is only relevant for models migrated from a previous version of SAP Business Planning and Consolidation.

• For Consolidation type models, the Group (G) dimension must include the following properties:

  • GROUP_CURRENCY, whose values are valid currencies in the previously mentioned Currency dimension

  • CURRENCY_TYPE, whose values are G for group currency or N for Non-Group related data, meaning local data

• The Entity (E type) dimension must include the property CURRENCY, whose values are valid Input_Currencies. Input currencies are listed in the currency dimension of the Rate model.

• The Account (A type) dimension must include the property RATETYPE, values of the RATETYPE property should be names of corresponding currency translation rules.

• The Time (T type) dimension must include the properties YEAR, PERIOD, TIMEID, and MONTHNUM.

• The Audit dimension is not mandatory for currency translation, but if you include it, the dimension must include the following properties:

  • DATASRC_TYPE, whose values include the following:

    • I - Input

    • M - Manual Adjustment

    • A - Eliminations and Adjustments

    • L - Audit level (use only for consolidation)

  • IS_CONVERTED, whose values include the following:

    • N - these members are ignored in the conversion

    • Y (or blank) - these members are converted from LC into the desired currency unless the members are flagged as requiring manual adjustment; these members have their currency conversions entered manually

    • G - these members are copied from the reporting currency of the group that is being translated into the currency member corresponding to the given group

• The Flow (S type) dimension is not mandatory for currency translation, but if you include it, the dimension must include the property FLOW_TYPE.

• The InputCurrency dimension within the applicable rate model must include the property MD, whose values are M for multiply rates or D for divide rates.

• The appropriate FXTRANS logic must be available.

The default translation reads all values in local currency where currency = LC, applies the correct exchange rate according to the applicable rate model, and writes the results in the appropriate reporting currency (USD, EURO, and so on).

Rate selection

For the selection of the correct rate, the following rules apply:

• The source currency is derived from the property CURRENCY of the entity being translated.

• The rate to be applied during translation, such as Endflow, Histrate, and so on, is derived from the property RATETYPE of the account being translated.

• The valid rates are those corresponding to an account of the rate model for which the value of the GROUP property is FX rate.

• The system does not convert any accounts with a rate type that is not a part of the currency translation business rules.

The default currency translation supplied with the product for multi-currency models performs a cross-rate translation; it multiplies the amount in local currency by the ratio between the rate of the destination currency and the rate of the source currency. This allows the model to use only one table of rates for translating any source currency into any destination currency.

Other types of translations can be defined by using the currency translation business rules tables and the relevant properties in the Currency and InputCurrency dimensions to support:

• the ability to use different tables of rates by reporting (destination) currency

• the ability to distinguish between Multiply currencies and Divide currencies

Conditions for Running Currency Translation

Currency translation can run in the following two modes:

• Reporting currency mode

  Reporting currency mode converts transaction data recorded in a local currency to the specified reporting currency. For this mode, make sure the script is similar to the following:

  *RUN_PROGRAM CURR_CONVERSION

  CATEGORY = %C_CATEGORY_SET%

  CURRENCY = %RPTCURRENCY_SET%

  TID_RA = %TIME_SET%

  RATEENTITY = GLOBAL

  ......

  *ENDRUN_PROGRAM

  Pay attention to the keyword CURRENCY. If running currency translation for the reporting currency, the keyword on the left side should be CURRENCY. If running currency translation for a group, use the keyword GROUP.

• Group mode

  Group mode converts subsidiaries' data to a group's currency. This is mainly used before consolidation.

Whatever mode the currency translation runs in, the following conditions must be satisfied:

• The model must contain only one Currency (type R) dimension.

• The model must contain only one Group (G type) dimension if the model is a Consolidation model.

  For consolidation models migrated from previous versions of SAP Business Planning and Consolidation, this dimension is not mandatory, in order to ensure compatibility with the current version.

• The reporting model must reference the RATE model.

• Some dimensions, such as Account, Entity, and Currency, must contain appropriate properties as noted in the following table:

  Model	Dimension	Property	Description
  Main	Account	RATETYPE	The value of the RATETYPE property must be the name of a currency translation rule, such as AVG, END, and ENDFLOW.
  Main	Entity	CURRENCY	The CURRENCY property denotes the local currency for the current entity. For example, for entity US, the currency is USD; for FRANCE, the currency is EUR. The value of this property must be a valid member of the InputCurrency dimension.
  Main	Currency	CURRENCY_TYPE	The CURRENCY_TYPE property specifies the currency type, and it should take the following values: L (local currency) R (reporting currency) G (group, for compatibility on migrated models only)
  Main	Group	CURRENCY_TYPE	The CURRENCY_TYPE property specifies if the member is a group/sub-group or is used to enter local data: G (Group) N (Non-Group, used for data input)
  Main	Time	YEAR	The YEAR property contains the year information of the ID. For example, if the ID is 2016.AUG, YEAR is 2016.
  Main	Time	PERIOD	The PERIOD property denotes the period to which the current time belongs. For example, if the ID is 2016.AUG, PERIOD is AUG.
  Main	Time	PERIOD	The TIMEID property is a numerical value for the current time. For example, for 2016.AUG, the TIMEID is 20160800.
  Main	Time	MONTHNUM	The MONTHNUM is defined to identify the closing period of a year. It's a number that stands for the chronological sequence of the base member in a Time dimension hierarchy during the same year. For example, for 2016.AUG, the MONTHNUM is 8. The base member can be either a month or a day, depending on your cofiguration.

When optional dimensions such as Audit and Flow (S type dimension) do not exist, currency translation still runs successfully. However, if they do exist, they impact the translation process. In this case, the following properties in these dimensions are mandatory:

To run currency translation in reporting currency mode, the mandatory condition mentioned previously should be satisfied. If optional dimensions such as Audit and Flow (S type dimension) exist, the condition of the optional dimension is also necessary.

To run currency translation in group mode, beside the same requirement as reporting currency mode, the following additional conditions are mandatory:

• The Ownership model must be set up and referenced.

• In migrated consolidation models only, Group information must be maintained in a separate Group dimension (except for models migrated from previous versions, where Groups can be maintained in a Currency dimension).

  When using the Currency dimension, Currency and Group information resides in the same dimension. The following properties are needed in Currency dimension:

  • The ENTITY property can be blank or a valid Entity ID. It is used to define the link between the group and the entity and to indicate the entity where the aggregation should be stored. (Refer to the STORE_ENTITY property below.)

  • The GROUP_CURRENCY property can be used only on CURRENCY members with the property CURRENCY_TYPE= G. It must contain a valid ID from the Currency dimension with the property CURRENCY_TYPE = R.

  • The STAGE_ONLY property controls the way the converted values must be saved in case of a multilevel conversion of groups. This property can have the three values Y, E, or N (blank).

  • The STORE_ENTITY property can have the values Y or blank. It indicates whether the system copies the results of the currency translation for the current group into the entity specified in ENTITY property.

  • The STORE_GROUP_CURR property can have the values Y or blank. It indicates whether the system stores the currency translation result in the group currency. Otherwise, the system stores the result only in gGoup, not in currency.

  • The PARENT_GROUP property defines the group hierarchy. The value of this property should be a valid Group ID in the dimension.

  When currency and group reside in one dimension, make sure the script file is similar to the following before running currency translation for the group:

  *RUN_PROGRAM CURR_CONVERSION

  CATEGORY = %C_CATEGORY_SET%

  GROUP= %GROUPS_SET%

  TID_RA = %TIME_SET%

  RATEENTITY = GLOBAL

  ......

  *ENDRUN_PROGRAM

  Pay attention to the keyword GROUP. If running currency translation in group mode, the keyword GROUP should be used instead of CURRENCY.

  In SAP Business Planning and Consolidation, when building a consolidation, both a group dimension and a currency dimension are required. Therefore, consolidation group members and currency members are held separately.

  A new dedicated dimension, for example, Group, should be type G.

When maintaining time properties, note that consolidation-related programs are allowed to run against base members in the same year only. The four properties of 'TIMEID', 'YEAR', 'PERIOD' and 'MONTHNUM' of base members affect those programs.

• Properties of parent nodes have no effect on those programs, and the value for these 4 properties should not be empty.

• The value for 'TIMEID' should be unique for each base member.

• The value for 'YEAR' should be a four digit number for each base member.

• The value for 'PERIOD' should be unique for each base member in the same 'YEAR'. SAP suggests that 'JAN', 'FEB', and so on are used for Month members and that 'week01' or 'W01' for are used for week members.

• The value for 'MONTHNUM' should be unique for each base member in the same 'YEAR'. It should be a number that stands for the chronological sequence during the same year.

• Example for DAY members:

  ID	Period	TIMEID	MONTHNUM	PARENTH1
  2016.TOTAL	TOTAL		365
  2016.Q1	Q1		90	2016.TOTAL
  2016.JAN	JAN		031	2016.Q1
  2016.08.01	DAY1	20160801	213	2016.AUG
  2016.08.20	DAY20	20160820	232	2016.AUG

• In addition, the following is an example of a time dimension for Jan 12th 2016:

  ID	TIMEID	Year	Period	MONTHNUM	Base Period
  2016.1.12	20160112	2016	D12	012	012