Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Asian (JPY) currency Decimal Places Issue

Former Member
0 Kudos

HI All,

Need your help, we have a program which creates a BDC session and when the user tries to process it it throws an errror for amount in asian currencies like JPY - no decimal places allowed for currency, in the background it calls the FBB1 transaction.

The original amount is in USD however after conversion when we store it back to amount field which is of type

"glpct-tslvt" it stores the amount in JPY currency with decimal places so for example :

USD amount = 93,214. 00

JPY amount = 115,021. 86

guess the amount is stored with decimals in BSEG table, so now when we try to process the session with the JPY amount with decimals it throws an error.

I have tried the

CALL FUNCTION 'CURRENCY_AMOUNT_SAP_TO_DISPLAY'

and

CALL FUNCTION 'BAPI_CURRENCY_GETDECIMALS'

it gives me the correct value for amount so for above example JPY amount = 115,021. 86 by using the mentioned two methods i am able to get the currency in this format 11502186.00 but still has two decimal places, i think it still will not work when we process the session for FBB1.

Need your help people, appreciate your co-operation.

1 ACCEPTED SOLUTION

ThomasZloch
Active Contributor
0 Kudos

Internally all currency amounts are stored with two decimal places. In order to fill your batch input field, you should try

WRITE <internal currency amount field> TO <external screen field> CURRENCY <currency code field>.

Thomas

5 REPLIES 5

ThomasZloch
Active Contributor
0 Kudos

Internally all currency amounts are stored with two decimal places. In order to fill your batch input field, you should try

WRITE <internal currency amount field> TO <external screen field> CURRENCY <currency code field>.

Thomas

0 Kudos

Thomas, your solution about WRITE is of course correct (it will set "11 502 186", without decimals) but your first phrase may be incorrectly interpreted (Zaro "TG" explained better 😞

> Internally all currency amounts are stored with two decimal places.

I would say:

> Internally all currency amounts are stored by right-aligning the amount, ignoring the decimal places of the database field. For example, 11 502 186 JPY will be stored 115 021.86 in a 2 decimals database field, and 11 502.186 in a 3 decimals database field

Sorry if my explanation is not clear

You are much less lazy than I am when it comes to delivering clear explanations

Thomas

Former Member
0 Kudos

Hi , there is ISO convention for the decimal per country it is obligatory and very important :

http://en.wikipedia.org/wiki/ISO_4217

For JPY there is 0 decimal places and it is a standard set up in table TCURX for JPY and it is 0

Do not change it but inclde logic to eliminate decimals during calculation as per the standard ISO and SAP set up.

I hope this helps.

Zaro

Former Member
0 Kudos

sorry to revive an old thread...but we are having an issue with JPY in our electronic bank statements.

the BAI format for our JPY account has for example 900 yen which according to our finance department is really 9 yen. the bank claims this is a known issue and the BAI format documentation seems to be confirming the bank's position in that the decimals are implied according to the currency code (whatever that means in SAP terms is a bit foggy to us).....

currently we wrote a custom code to suppress the last two zeros (when they are zeros) but i feel this error is caused either by a wrong setting in our currency or translation tables in SAP or something else since our feeling is that this should work right out of the box without any custom programming...any ideas???...where we shoudl start looking in our currency config....does the 100:1 or 1:1 translation ratio between JPY/USD make any difference...should we try and use a function module to convert the currency ...any ideas or hints are welcome

thanks
Ram

rssharma@hotmail.com