When configuring the SAP FI module for projects based in such countries as the United States, not much has to be done to accommodate the decimal places for the currency. The U.S. dollar (USD), like many of the world's currencies including the euro (EUR), uses two decimal places, which — not surprisingly — is the default setting for R/3. When you roll out your SAP functionality across geographies, however, you may run in trouble coping with currencies with other decimal-place demands.

I have found that users are generally unaware of how their SAP systems deal with various monies, or how to enable the functionalities available specifically for handling differing currencies. Often, when doing custom programming, many turn to clumsy — and unnecessary — solutions such as hard-coding currency codes or multiplying values by some factor, particularly when creating custom ABAP reports or using the ALV for reporting. To make matters worse, most users do not fully appreciate the possibilities of misinterpreting values for currencies such as the Japanese yen (JPY), South Korean won (KRW), and other currencies that require no decimal point, or the Kuwaiti dinar (KWD) and those that that need three or more decimal places.

Not paying attention to local currency requirements when setting up a system for doing business in a country like Japan can not only irritate or confuse your end users, it can result in miscalculated or misprinted invoices being sent to customers. If your R/3 configuration does not accommodate the yen, for example, it could result in a 100-fold error (see Figures 1 and 2).

Figure 1

Correct JPY invoice with zero decimal places

Figure 2

Incorrect JPY invoice with decimal places — values are 100 times too small!

In this article, I will offer some technical tips and explain how and where to configure your system. I will also examine how mistakes can occur when viewing or working with various currencies as well as how to prevent them. I'll take a look at the risks associated with viewing raw data using the popular transaction code SE16 and show you how values can be accurately displayed in standard and custom SAP reports as well as those provided using ALV.

Note that while this article is relevant for any currency requiring other than two decimal places, I have focused on currencies that do not use decimals, because after currencies with two decimal places, those with no decimal places are the most commonly encountered.

Configuring the System

1. Where to configure a currency's decimal places. Table TCURX is the so-called exception-only table where the decimal place settings for various currencies are defined in R/3. Any currencies not in TCURX will default to two decimal places. Using transaction OY04, you can confirm that your current settings are correct and add new currencies to the system. You can see in Figure 3 that table TCURX uses the ISO standard 4217.

Figure 3

Decimal place settings in TCURX, transaction OY04

Decimal Places in Reports

2. Using standard function modules in your ABAP reports. The biggest problems that I have encountered rolling out an implementation to a new company that uses currencies without a decimal place has been making sure that programmers use a currency reference when outputting data in custom reports. The lack of a currency reference in a program can lead to bogus values and inaccurate reporting.

Use the ABAP editor, transaction SE38, to verify currency references via an extended syntax check. Currency references allow SAP to automatically look up the correct number of decimal places and format the value correctly, and I'll discuss this in more detail later. For example, the ABAP code WRITE BSIS-WRBTR USING CURRENCY BSIS-WAERS is a write statment using a currency reference field. The reference eliminates the need for the various workarounds such as custom ABAP rules, hard coded logic to multiply or divide, or special formats for printing. If your custom program needs to know how many decimal places a currency has, use function module G_DECIMAL_PLACES_GET.

When creating custom programs, there are two other function modules you should be aware of, CONVERT_ TO_LOCAL_CURRENCY and CONVERT_TO_FOREIGN_ CURRENCY. These modules are designed to make currency conversions go more smoothly and allow you to avoid some of the snares associated with taking data directly from the currency tables, which I will discuss later. Never create your own routines directly reading the currency tables TCURR and TCRUX, because you are likely to miss the many special currency conversion rules required by your system such as those that pertain to changing values from one of the old European currencies into another, like Italian lira (ITL) into French francs (FRF).

The only time you are likely to run into problems with decimal places when creating a new custom report from a copy of an older standard SAP report is when you use reports that originated in the R/2 system and were migrated over to R/3 by SAP when the new technology was initially released. Although they are generally rare, such reports can exist in all versions of SAP R/3, and they have the Fixed point arithmetic flag switched off in the program attributes (Figure 4).

Figure 4

Some older SAP programs have the Fixed point arithmetic checkbox off

3. Using the ALV Grid for reports. If you are using the ALV Grid for reporting, make sure to include the currency code field in your data table, and cross-reference the currency value field to the currency code field in the field catalog. The ALV Grid uses the field catalog information to display values correctly. Note in Figure 5 that it also has the functionality to sub-total columns with values in multiple currencies correctly.

Figure 5

ALV reports can provide sub-total amounts in multiple currencies

4. Some standard reports need special care, too. In general, SAP standard reports render currency values without decimals correctly. However, some do need special care when entering selection values. In particular, when generating a costing run comparison with report RKKBCAL2 in report tree CK81, make sure to adjust for the decimal place when you set the threshold values. When running a costing run comparison in JPY, for example, divide the values by 100 before you enter them to adjust for the decimal places. In the example in Figure 6, the default values of 100.00 and 1.00 will be interpreted as JPY 10,000 and JPY 100.

Figure 6

The default threshold values are interpreted as being 100 times greater for JPY

5. Configure your system for proper printing with SAPscript. Because you probably use SAPscript to print customer invoices, it is quite likely that your US-based invoice formats will not smoothly transition to currencies that do not have the same decimal requirements as the U.S. dollar. If your custom APscript is based on a SAP standard SAPscript and displays data using one of the standard data communications structures such as KOMK, VBDPA, or VBDPR, you can configure the system to format correctly without much effort.

Make sure you populate the currency reference field, e.g., KOMK-WAERK, VBDPA-WAERK, and VBDPR-WAERK, in the SAPscript driver program and such currency values as VBDPR-NETPR and VBDPR-NETWR will be correctly formatted (Figure 7). If you use a custom com- munication data structure to send data to your SAPscript, then follow the advice for custom tables and include a currency reference field in the structure, which you populate in the SAPscript driver program (Figures 8 and 9).

Problems with SE16

6. Take care viewing raw data. Often people use transaction SE16 to display raw data in the SAP system such as that found in the open-item index table BSIS. While this transaction code acts as a good back- end tool and eliminates the need to generate time-consuming reports, using it with raw data related to money can be problematic. Because of the way in which R/3 stores the data internally, values are often displayed using SE16 with two decimal places, regardless if the currency uses decimal place or not! (See the sidebar, "How SAP Stores Currencies.")

Values viewed in the SE16 row overview screen (Figure 10), for example, always appear with two decimal places, while in SE16 row detail screen, values may or may not be displayed with two decimal places, depending on how the reference field for the currency field was defined.

Figure 10

In the SE16 row overview screen, values are always displayed with two decimal places

In Figure 11, the SE16 row detail screen shows the general ledger postings for a company with a JPY currency code. The row detail screen offers the Amount (WRBTR) field for amounts in the document currency, and is correctly presented without decimal places because it is referenced to field BSIS-WAERS in the BSIS table. The Amount in LC, however, displays the amount in company code currency, and, like the overview screen in Figure 3, presents values with two decimal places. This is because Amount in LC is referenced to field T001-WAERS, which is not contained in BSIS, instead of BSIS-WAERS. You can check where fields are referenced using transaction SE12 (Figure 12), which displays the data dictionary definition of a table.

Figure 11

For this example, the Amount (WRBTR) field in the

Figure 12

Display of currency reference fields in the data dictionary, transaction SE12

If you enter currency-based selection values in the SE16 selection screen, make sure you adjust for the default setting. In the above example, to search for a JPY 200,000 value, the user must enter 2000.00 in the selection screen (Figure 13). 2000.00 is held internally in SAP in the same way as JPY 200,000.

Figure 13

When searching for values using SE16 for currencies that do not use decimal places, remember to adjust amounts

7. Downloading from SE16 to the LSMW. When using the Legacy System Migration Workbench (LSMW), a convenient source of input data is a table download from SE16. The download is accomplished by selecting a list of FI documents from table BSIS in SE16 that, for example, require the allocation field to be updated using LSMW. Remember, however, that the SE16 overview values are for currencies without decimals and may be incorrect. To resolve the issue, add the code in Figure 14 into your LSMW.

Figure 14

LSMW code to convert SE16 input value to correct decimal place

In the example, the input data structure is called BSIS_SE16 and the BDC data structure is called REPOST_CLR. Note that if you use a period rather than a comma as your thousands separator, then you need to edit the line of code TRANSLATE BSIS_SE16-WRBTR USING ‘, ‘ so that it reads TRANSLATE BSIS_SE16-WRBTR USING ‘. ‘. Change the structure names to match your own LSMW.

Precision

8. Rendering dollar values with more than two decimal places. In SAP modules such as HR, MM, PP, and FI-TR, there may be requirements to calculate currency values to more than two decimal places of precision. For these types of calculations, a new currency code with more decimal places must be defined. For example, to allow USD values to be recorded with four decimal places, create the custom currency code US4 in table TCURX. It can then be used just like any standard currency codes such as USD or JPY, but with four decimal places. You define the value as having a 1:1 exchange rate with USD in the exchange rate table TCURR via transaction OB08.

Hourly payroll rates sometimes require four decimal places in order to calculate an employee's total annual pay with an hourly rate. A figure such as $12.1385 per hour, for example, would be required so that when the hourly rate is multiplied by the actual number of annual hours worked, the correct annual pay is calculated. Normally when using the standard currency code USD, the value would be entered as $12.14. However, with the custom currency code US4, the $12.1385 rate can be entered in infotype 0008, in the Wage type amount for payments field in the Basic Pay screen with all four decimal place values.

9. Accommodating low-value currencies. Another place where accuracy by way of the addition of significant figures becomes an issue is when accommodating units of currencies with very low values such as the Indonesian Rupiah (IDR), which has an exchange rate of approximately 1 USD = 8,000 IDR, or the Vietnamese Dong (VND) (1 USD = 15,000 VND). These currencies are problematic because the largest number you can enter in transaction FB01 is 99,999,999,999.99 for a two decimal place currency — or 9,999,999,999,999 for a zero decimal place currency. Low-value currencies may require more significant figures when being converted to higher-value units such as the dollar or euro.

I recommend that when setting up a system to handle low-value currencies, configure it with no decimal places. I should also point out that while the number of decimal places for low-value currencies defined in the ISO standard may recommend two decimal places, the value is so low that in practice, the decimal places are not used.

Rohana Gunawardena

Rohana Gunawardena heads the SAP practice division at Exium Inc. Exium is a leading business and technology consulting firm that enables companies to achieve their strategic business goals. Exium specializes in delivering superior IT solutions using ERP systems, with a special focus on SAP products. Rohana has been working with SAP since 1992. During his career he has assisted multiple clients on detailed system correction projects, such as correcting inventory balances, controlling area reorganizations, retrospectively activating group currency, and optimizing inter-company accounting transactions. He has spoken at many SAP conferences and has published more than 20 articles in Financials Expert, SCM Expert, and SAPtips on various aspects of SAP. His presentations have focused on Financials module selection, the order-to-cash process, global rollouts, business segment reporting, cross-module integration, and the financial impact of SCM transactions. Rohana is widely acknowledged as a leading SAP expert. Rohana is a Fellow of the Institute of Chartered Accountants in England & Wales. Previously Rohana has worked with the consulting practices of Accenture, Deloitte, and PwC.

Rohana will be presenting at the upcoming SAPinsider Financials 2018 conference October 16-18 in Prague. For information on the event, click here.

You may contact the author at Rohana@Exium.com .

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