Skip to Content
Technical Articles

Currency Decimal issue – JPY, KRW, VND | Localization | Rollout – Japan, Korea, Vietnam

Although, this is an existing system behaviour in SAP which many of you might be knowing already, I feel that having detailed information on this may help some of the new consultants, new customers, existing customers who are planning to expand SAP template in countries having decimals other than 2.

Background

In real world, there are currencies with different decimals.

For example, USD, EUR, AUD, NZD, SGD, INR – have 2 decimals, which mean we have 25.50 USD as a valid amount.

On the other hand, JPY, VND, KRW has 0 decimals, which means these currencies do not have any amounts like 25.50 JPY, they are either 25 or 26 JPY.

 

How it impacts in SAP

Most of the SAP table amount fields are with 2 decimals and hence, amount in SAP tables in general is stored in 2 decimals (for DB with 2 decimals). Reason is very simple : at table level amount field has fix attribute which is by default set as 2 decimals. Now, to store different currencies, we cannot change the field attribute as it has to support multiple currencies. Thus, SAP architecture is to store all amounts in 2 decimals by converting amount into 2 decimals before storing.

Similarily, amount need to be converted to correct value after picking it from DB tables with help of corresponding currency.

To give a better idea, this is how amount with a 0-decimal currency will be stored in SAP tables:

Actual Amount (KRW/JPY/VND) SAP Table stores as
100 1.00
1250 12.50

Now, if we have a Z-program which normally picks data from SAP table and simply use it for display/transfer (without use of CURRENCY) then 100 KRW will be reported as 1.00 which is wrong. The impact becomes huge when we talk about real world scenario of reporting of 1 Million KRW as 10000.00 KRW.

*Information – These Z-programs have been working perfectly for years for 2-decimal currencies, but fail to report correct amounts with a currency having different decimal count.

*Fact – 1) SAP Table TCURX holds details about number of decimals used in a Currency within SAP.

2) SE16(Std List and ALV list)  shows 100 KRW as 1.00 while SE16N shows it as 100. Basically SE16N or any other standard transaction(ME23N, VF03, VA03, etc) do a decimal conversion using relevant Currency before display and hence display the correct amount in relevant currency. Funny part is that SE16(Std List and ALV list) also if you double click on an entry, amount will be shown correctly.

 

Solution

Before going into solution, we need to understand the various points where this can impact. Important thing is that this works fine in all Standard programs as SAP has already taken care of below explained solutions, so this impact and solution is for Z-programs, FMs, Forms.

Read from Database

  1. any program which displays the data (Classical / ALV  reports)
  2. any program which transfers the data – either to Application server or presentation server
  3. any Form that prints amount

Update to Database:

  1. any program that reads data and updates in SAP tables

 

Solution for all the above scenarios is as below based on the keyword:

  • If TRANSFER is used for for AL11 functionality
  • If WRITE is used for classical report
  • If GUI_DOWNLOAD or any other method is used for downloading of file to local system
  • If Forms (Script, Smartform, Adobeform) print an amount field
    • Solution – while passing amount in final structure using WRITE, additionally use keyword CURRENCY <curr> so that amount is first converted according to currency and then passed to target structure.

 

  • If ALV is being generated
    • Solution Pass 2 additional field catalogue fields as below

<fieldcatalogue>-cfieldname = <corresponding Currency Field in Output Structure>.

<fieldcatalogue>-datatype = ‘CURR’.

 

Basically, the KEY is that, provide corresponding currency whenever transferring an amount.

 

Few additional points

  1. Use additional keyword NO GROUPING with WRITE to skip use of thousand separator (this will pass amount as 10000 instead of 10,000)
  2. We can also use standard FMs CURRENCY_AMOUNT_SAP_TO_DISPLAY (before output) and CURRENCY_AMOUNT_DISPLAY_TO_SAP (before input) – These FM may not be available in all type of systems(SRM, CRM, etc)
  3. If you are modifying an existing Z-program ALV which doesn’t has Currency field in final structure, make sure to add field catalogue for Currency field also. You can use Field catalogue parameter NO_OUT if you do not wish to display this additional field, but it is always better to display relevant currency for each Amount.
  4. It can be tricky with TYPE P having different decimals.
  5. Whenever passing reference currency, it is utmost important that we use correct currency against each amount field, otherwise the value may get changed completely. Few tables have amounts in multiple currencies(Document Currency, Local Currency), so developer should be careful to use correct currency as reference currency otherwise it will report wrong amounts.
  6. Best practice is to use above explained additional keywords even if your requirement is for a currency having 2-decimals. This was your code will be future ready to support all currencies.

 

Do let me know in comments if there is anything which can be added in this document for benefit of everyone.

4 Comments
You must be Logged on to comment or reply to a post.
  • Currency amounts are not always defined in the DDIC with 2 decimals, it’s just a big recommendation; what is very important (that you mention in your conclusion) is that all DDIC fields used by a same application have the same number of decimals so that assignments between the variables corresponding to those DDIC fields can be done simply, otherwise that would be a mess for the developers to convert between one variable with 2 decimals and a variable of 3 decimals. Note that here, I was only talking about the decimals in the DDIC, not the number of decimals of currency keys.

    NB: if I’m not wrong, the SD module of SAP ERP has some DDIC fields with 3 decimals.

    You don’t explain how SAP converts 1.00 KRW into display 100 KRW in SE16N. This is because the DDIC “CURR” field of a structure or a table is assigned to another DDIC “CUKY” field in transaction SE11.

    I just checked, SE16 displays the decimal point at the right place (according to the currency key) if you choose the ALV display type except “ABAP list” (the one I prefer is the mode “ALV grid”).

    In your post, it’s not clear that CURRENCY <curr>, for statements TRANSFER, GUI_DOWNLOAD and Forms, is a word of statement WRITE (might think that it’s a word or parameter pertaining to the concerned statements), and that NO GROUPING pertains to WRITE also.

    CURRENCY_AMOUNT_SAP_TO_DISPLAY and CURRENCY_AMOUNT_DISPLAY_TO_SAP only exist in SAP ERP (R/3, S/4).

    More information below about how the currency amounts are stored and displayed:

    And in the following SAP notes:

    And in these blog posts (also partially describing the general concept):

     

    • Thanks Sandra. I really appreciate your efforts in providing constructive feedback. I’ve updated the blog with recommendations.

      Regarding ‘how SAP converts 1.00 KRW into display 100 KRW in SE16N’ – Main reason behind SE16N displaying amount correctly is still use of reference currency. If Standard program doesn’t use the reference currency, then amounts will not be displayed correctly even if data(Read CUKY field) is there. Obviously, it won’t work if reference Currency is not available 🙂

      Thanks for adding different references which will be helpful for all readers.

      Though ‘Dynamic handling of decimal places for amounts’ is for a specific requirement, but it was a good read.

      Happy learning!