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|
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
- any program which displays the data (Classical / ALV reports)
- any program which transfers the data – either to Application server or presentation server
- any Form that prints amount
Update to Database:
- 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
- Use additional keyword NO GROUPING with WRITE to skip use of thousand separator (this will pass amount as 10000 instead of 10,000)
- 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)
- 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.
- It can be tricky with TYPE P having different decimals.
- 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.
- 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.