Exchange rate design for multi-country SAP implementations must take into account complex factors such as the exchange rate source, update frequency, and local statutory reporting requirements. I’ll explain the challenges and then present three design options to deal with them: an additional parallel currency definition, FI substitution and field exits, and alternate exchange rate types.

I’ll show you the key elements involved in foreign currency processing: currency type and exchange rate type. Then I’ll look at how country legal requirements introduce complexities in exchange rate design related to foreign currency processing. After you understand these key elements and challenges imposed by legal requirements, I’ll discuss the various design options available to meet these requirements.

Currency Types and Exchange Rate Types

An SAP system records amounts in an accounting document using the concept of currency types. Any accounting document would have amounts stored under a minimum of two currency types: the document currency 00 and the company code currency 10, also known as 1st local currency. You could use other currency types such as group currency (30), also known as 2nd local currency, to store amounts in various desired currencies for consolidation or reporting purposes. You can define additional currency types by using transaction code OB22 or following menu path Financial Accounting Global Settings > Company Code > Multiple Currencies > Define Additional Currencies (Figure 1).

Figure 1

Define additional local currencies

Document currency 00 stores the amount in the actual transactional currency, while company code currency 10 stores the amount translated to local currency equivalent. In the case of a document posted in local currency, the amount under company code currency is equal to the amount under document currency. On the other hand, for a document posted in foreign currency (i.e., in a currency that is not equal to the company code currency), the amount under company code currency is translated from the document currency using a specific exchange rate. This brings me to exchange rate type.

You derive this exchange rate from the foreign to local currency rate combination maintained in transaction code OB08 against an exchange rate type. You may need to maintain different exchange rates in the SAP system for the same currency combination for different purposes. You can separate them by defining them against relevant exchange rate types. To do this, follow menu path General Settings > Currencies > Check exchange rate types. In a standard SAP setup, you use exchange rate type M (standard translation at average rate) to translate the foreign currency into local currency.

You can translate to local currency by picking up the record for rate type M from transaction OB08 where the effective date is less than or equal to the posting date of the document (Figures 2 and 3). Rates under exchange rate type M typically derive from a financial markets data provider such as Reuters and are updated on a monthly basis. The system automatically determines exchange rate type M used for the translation based on the currency type 10 definition in transaction code OB22.

Figure 2

Foreign currency posting using rate type M

Figure 3

EUR (Euro) to PLN (Polish Zloty) exchange rate value for rate type M

Now that I’ve discussed currency types and exchange rate types, let’s see the challenges imposed by country-specific requirements on the exchange rate design for foreign currency processing.

Country-Specific Requirements

In certain countries, statutory requirements govern this translation from document currency to company code currency. Those requirements might mandate that the exchange rate source used for this translation be the country’s national or central bank or that exchange rates be updated on a daily basis. They would therefore affect the global design of the parameters of rate source and frequency of exchange rate update.

In a multi-country implementation, these requirements pose certain design challenges.

• You cannot maintain exchange rate types and corresponding exchange rates used to post foreign currency accounting documents at country or company code level in an SAP system. You have to maintain them at the client level. Note that you don’t use the country currency and rate type seen in transaction code OY01 for posting accounting documents. You only use that field when you need to do reporting in a currency other than the company code currency.
• You can use exchange rate type M to maintain rates from the mandated source and with the mandated frequency. However, not all countries would want to move to a daily exchange rate. They also may not want to use rates sourced from some other country’s national or central bank. Using daily exchange rates exposes countries to an unwanted exchange rate gain or loss due to daily fluctuations in exchange rates.
• An SAP system hard codes 1st local currency definition to default to currency type 10 (company code currency) and exchange rate type M. This eliminates the option of setting up a unique exchange rate type per company code and using it while defining currency type 10. SAP strongly recommends that you not modify this default exchange rate type.

Design Options

Now I’ll explain the three design options and give pros and cons for each.

Additional Parallel Currency Definition

You need to define an additional parallel currency to hold the local currency value calculated per the local exchange rate requirement. You set up this additional currency with an exchange rate type setup to hold the new exchange rate requirements, using these steps:

• Step 1. Create a new rate type to hold the desired local exchange rate
• Step 2. Define additional local currency in transaction code OB22
• Step 3. Define additional local currency ledger in transaction code OBS2

Step 1. Create a new rate type to hold the desired local exchange rate (Figure 4). Follow menu path General Settings > Currencies > Check exchange rate types to get to this screen and create a rate type with the appropriate information, as shown in Figure 4.

Figure 4

Definition of exchange rate type POL

Step 2. Define additional local currency in transaction code OB22. You define the appropriate currency type as the 2nd or the 3rd local currency, linking it to the desired exchange rate type that would hold the desired exchange rate.

In Figure 5, I set up the 3rd local currency using currency type 40 and exchange rate type POL. This setup also requires you to define the hard currency in country settings under transaction code OY01 or menu path General Settings > Set countries > Define countries in R/3 systems (Figure 6).

Figure 5

3rd local currency defined with currency type 40 and rate type POL

Figure 6

PLN defined as hard currency

Figure 7 is an example of a foreign currency accounting document posted using this setup. The additional field in the accounting document is titled Hard crcy amt. You calculate this field using rate type POL, which is expected to hold rates per the country’s legal requirements.

Figure 7

3rd local currency calculation using POL rate type

Figure 8 shows the EUR-POL exchange rate prevalent in transaction OB08 at the time of posting the above document. The SAP system has posted the document using this rate. To summarize, for the document posted in Figure 7, the prevailing exchange rates in the system are as shown in Table 1.

Figure 8

EUR to PLN exchange rate value for rate type POL

Step 3. Define additional local currency ledger in transaction code OBS2. The additional parallel currency solution would also need a ledger defined with transaction code OBS2 or by following menu path Financial Accounting Global Settings > Company Code > Multiple Currencies > Define Additional Currencies for Ledgers. You need this ledger to store currencies other than company code currency and group currency.

The biggest downside of this option is that most existing SAP reports are equipped to show the local currency value based on the 1st local currency (currency type 10). You need to modify these reports to show the value from the 3rd local currency. Depending on the reports needed for reporting, this could be a big change. Currently these reports would directly show the local currency value stored in the company code currency type (10) field. You need to modify these reports to show the value from the 3rd local currency (i.e., currency type 40) through a code change. You need to individually analyze each report for impact and for a solution so you don’t have to modify any SAP-supplied code directly. You also need to evaluate clearing because the realized gain or loss would be posted in this additional currency field and Asset Accounting for possible addition of depreciation areas. You should also evaluate the Material Ledger because material movements are not possible in plants that have the Material Ledger activated and that have existing material movements if you changed the setup to add the 3rd local currency. You can fix this only with special programs through a consulting service with SAP.

FI Substitutions and Field Exits

This process involves manipulating the exchange rate on the accounting document header and changing it from the global rate to the local rate. Technically, you would need a substitution step to change the accounting document header fields BKPF-KURSF (exchange rate) and BKPF-WWERT (translation date) at the time of posting. This ensures that the 1st local currency field has the local currency calculated at the daily rate even though in configuration it is defined to calculate at exchange rate type M. You should set this up only for countries requiring daily exchange rates.

Follow this sequence of steps:

• Step 1. Create a new rate type to hold the desired local exchange rate
• Step 2. Make fields BKPF-KURSF (exchange rate) and BKPF-WWERT (translation date) substitutable by modifying table GB01
• Step 3. Create a substitution in FI (transaction code OBBH) to substitute fields BKPF-KURSF (exchange rate) and BKPF-WWERT (translation date)
• Step 4. Write a substitution user exit to manipulate these two fields during posting

Step 1. Create a new rate type to hold the desired local exchange rate (Figure 4). This step is the same as step 1 in the first option.

Step 2. Make fields BKPF-KURSF (exchange rate) and BKPF-WWERT (translation date) substitutable by modifying table GB01. The fields BKPF-KURSF (exchange rate) and BKPF- WWERT (translation date) are not available as standard substitutable fields in transaction OBBH. You need to make changes to these fields using table GB01 (Figure 9). Refer to SAP Note 42615 for details on how to make these fields substitutable.

Figure 9

Table GB01 showing KURSF and WWERT as now included

Step 3. Create a substitution in FI (transaction code OBBH) to substitute fields BKPF-KURSF (exchange rate) and BKPF-WWERT (translation date). You can do this through transaction code OBBH or by following the menu path Financial Accounting > General Ledger Accounting > Business Transactions > G/L Account Posting > Carry Out and Check Document Settings > Substitution in Accounting Documents (Figure 10).

Figure 10

FI substitution to manipulate exchange rate and translation date

Figure 10 shows a substitution created in transaction OBBH for this purpose. The code in the Prerequisites section — BKPF-BUKRS IN SPECIFIC CO_CODES — makes sure that the user exit kicks in only for company codes defined in the set SPECIFIC CO_CODES. The Substitutions (if prerequisite is met) section replaces the value in the Exchange rate and Translation date field by the value calculated by user exits U001 and U002, respectively.

Step 4. Write a substitution user exit to manipulate these two fields during posting. Link this to the substitution defined above. You do this by defining the source for the fields KURSF and WWERT as a user exit and mapping these user exits as the source value (Figure 10). In addition, you may need to use similar coding logic as a field exit if you need this manipulation for documents flowing from Materials Management (MM).

The substitution should kick in at the time of posting an accounting document for a specific set of company codes defined in set SPECIFIC CO_CODES. You can define the set using transaction GS01 or by following the menu path Financial Accounting > Special Purpose Ledger > Tools > Set Maintenance > Maintain Sets.

You define two user exits, one for the translation date and the other for the exchange rate. The user exit code for the translation date would substitute the translation date (by default posting date) with the document date. If this is not a requirement, then you need only the user exit for the exchange rate. The user exit code for the exchange rate would pick up the exchange rate type to be used for the country in question, fetch the exchange rate corresponding to the translation date, and overwrite the field BKPF-KURSF with this information.

This substitution user exit works only for transactions originating from FI. This substitution step would not be triggered for transactions originating out of other modules, such as MM. The reason why the exchange rate substitution does not work for MM is the piece of code shown in Figure 11.

Figure 11

SAP substitution code

After calling the substitution, the system copies all changes in BKPF into the fields of structures ACCHD_FI and ACCIT_FI. These two fields (KURSF and WWERT) are not defined in these structure definitions.

You can use field exits on the KURSF field in certain transactions originating from MM to achieve the desired transaction specific results — for example, transaction MIRO for MM invoice posting. Unlike a substitution user exit, whose output feeds into a well-defined substitution configuration in SAP (set up in transaction code OBBH), a field exit is essentially associated with a data element used by a particular screen field. Further discussion on the difference between these two is beyond the scope of this article, but note that though it is possible to create a field exit in R/3 4.7, SAP has ceased supporting it since this version. Refer to SAP Note 29377 for more details.

You can write code similar to that for the user exit above in a field exit for transactions originating from MM. The prerequisite would be to identify the exchange rate field in MM transaction screens into which you would put the code. Program RSMODPRF gives access to the field exit (Figure 12).

Figure 12

Define a field exit

Alternate Exchange Rate Types

This method involves pointing the exchange rate M currency translation ratio record to the desired exchange rate type depending on the currency in question. As with the first two types, you start by creating a new rate type to hold the desired local exchange rate.

Then use transaction OBBS or follow menu path General Settings > Currencies > Define translation ratios for currency translation to maintain translation ratios between foreign and local currencies and define the alternate exchange rate type (Figure 13). This points such records corresponding to rate type M to an alternate exchange rate type. It forces the SAP system to automatically pick up the exchange rate from the newly defined exchange rate type while posting foreign currency transactions. Note in Figure 13 that for rate type M, EUR – PLN has been pointed to rate type POL. You don’t need any other setup to make this work. This offers the least downside for meeting the requirement of local exchange rates provided that you do not run into a situation in which the same currency is used as a local currency in two countries that have different requirements for foreign currency posting.

Figure 13

Translation ratios for EUR – PLN for rate types M and POL

See Figure 14 for an example of a foreign currency document posted using this method. This method works only if you have defined the exchange rate type M neither with a reference currency nor with inverse ratios. Further, a conflict could arise if multiple countries have the same local currency but have conflicting requirements. For example, one country may require a daily exchange rate while others may require monthly, or both may require daily exchange rates but from different sources. In such cases, you might need to use the option of manipulating the exchange rate with substitution instead. You would also need to modify custom reports, if they are hard-coded to run with rate type M, to now pick up the alternate rate type for calculations. You need to evaluate function modules READ_EXCHANGE_RATE and BAPI_EXCHRATE_GETCURRENTRATES for a possible solution.

Figure 14

Foreign currency posting using rate type POL

Valuation Based on Document Date

Some countries, such as the Czech Republic, Poland, and Italy, also require that you do local currency valuation (currency type 10) for invoices based on the document date, instead of SAP standard valuation based on the posting date. You can achieve this by implementing Business Add-In (BAdI) FI_TRANS_DATE_DERIVE, which SAP has made available for this purpose (Figure 15). For more information, see SAP Note 575249 (MIRO: Derivation of value date via BAdI).

Figure 15

BAdI implementation for document date

Because the system now determines the exchange rates according to the document date, ensure that exchange rates are maintained with a history of at least one to two months at the time of going live. At go-live, you normally start maintaining values under the newly set-up exchange rate types effective from the go-live date. This means that the first rate combinations maintained for this exchange rate type in transaction OB08 would have Effective from date as the date of go-live and beyond. Even if you have documents being posted with a document date before the go-live date (which is likely), it would not matter because the translation basis is the posting date. However, for cases in which the document date forms the basis of local currency translation, it would start to matter. You would then need to maintain historical rates going back as long as the document dates of the pending documents would require. Without these rates, foreign currency documents would not post because the SAP system would not be able to calculate the local currency equivalent. This is because during go-live conversion, converted documents could have document dates from the past.

Siddharth Priolkar

Siddharth Priolkar is a senior FI/CO consultant with Infosys Technologies. He has more than 10 years of experience in the consulting space including more than seven years with SAP systems. The majority of his SAP experience comes from working across the globe in multi-country SAP implementations with clients in the consumer electronics and automotive industries. Siddharth holds a bachelor’s degree in mechanical engineering along with a post-graduation degree in business administration (finance).

You may contact the author at siddharth_priolkar@infosys.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.