Skip to Content
Technical Articles
Author's profile photo Shyam Agrawal

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.


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.



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.


How to adjust currency keys in SAP in case you have brought them to live, but unfortunately with wrong decimals. There can be cases when due to various reasons, number of decimals were marked incorrect in SAP system(TCURX table) and postings were also done. Refer below SAP Note on how to handle such scenarios:

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

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Michelle Crapo
      Michelle Crapo

      I haven't had to do this before.  Perhaps I will have to at some point.  I'll bookmark this post.

      Nice information.

      Author's profile photo Shyam Agrawal
      Shyam Agrawal
      Blog Post Author

      Thanks Michelle. Definitely it is a different kind of exposure within same system. All the best 🙂

      Author's profile photo Sandra Rossi
      Sandra Rossi

      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.


      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):


      Author's profile photo Shyam Agrawal
      Shyam Agrawal
      Blog Post Author

      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!

      Author's profile photo Diran Shetty
      Diran Shetty

      Nice article Sir

      Author's profile photo Uwe Kaiser
      Uwe Kaiser

      Dear Agrawal,

      I think we should also add a little hint on sap note 434349  which is the 'classic hard DB conversion' approach, how to adjust currency keys in SAP in case you have brought them to live, but unfortunately with wrong decimals.

      Very important for anyone who likes to make use of a new currency key for a new company code: Don't do it just like that.

      Make sure what is in use in your system landscape, also in other systems, be sure you follow actual ISO standards, and that all connected SAP systems in question do this as well.

      Make sure that you know how the decimal is actually defined per system in question.

      Be aware that the 'defaullt' SAP setup is not mandatory also the correct one!!! We live in a modern changing world, where actual legal or country specific changes on decimals are nothing that SAP can reflect in a live system, where SAP can also not make this subject to a patch or update. We are talking here always about a customer individual situation!

      It is and it was customer responsibility only to make sure, that you activate a currency key with the actual correct setting. And if this changes during system lifetime, you might come back to that note as to search for the DB conversion solution approach.

      Hope this helps, Uwe


      Author's profile photo Shyam Agrawal
      Shyam Agrawal
      Blog Post Author

      Thanks Uwe for highlighting this important note.

      As you rightly mentioned, "We live in a modern changing world", it is quite possible to have this tricky situation in a project. Hopefully no one need to face this situation, but if it comes, then they can refer the mentioned SAP Note.