Re-configure JPY currency

Hello peeps,
Good evening!
I want to ask again your help regarding currency configuration specifically for 'YEN'.
Is it possible to set the JPY currency to 2 decimal place just like the USD currency? If possible, how? Is there any effect with the existing data or transactions in the system?
Hope you can give me a bit of advise..
Thank you very much..
April =)

OY04 is the tcode where you make this change.
Here is an extract of the warning that SAP posts for such changes :
In the R/3 System tables currency fields are stored as decimal figures with a variable number of decimal places. The decimal point is not stored in the field in the database. Instead, each currency field refers to a currency key field. In this transaction you assign the number of decimal places to this currency key uniquely.
Example: If you have set currency USD to have two decimal places and you post an amount of 100 USD, an amount of 10000 USD is stored in the currency field in the database. Not until this amount is processed further or is output does the system use the currency key from the reference field to determine the number of decimal places via this table. In this way the table content can be interpreted correctly for further processing or formatted for output with the correct Punctuation.
If after posting you changed the number of decimal places for USD, for example, to 3, the existing field content of 10000 would be interpreted for futher processing or output as 10 USD (10.000). This would mean that the contents of tables across the system would, for all currency fields containing an amount in USD, be interpreted incorrectly by 10 per cent. To change the number of decimal places for a currency already in use, you must convert all the tables in the R/3 System that contain currency fields, so that the data integrity
remains. This cannot, however, for both organizational reasons and under the runtime aspect be carried out in a productive system.
The following changes to the TCURX table can thus lead to the loss of data integrity if you make the changes in a productive system or transport them into a productive system:
o Change to the number of decimal places of an existing currency
o Deletion of an entry from the TCURX table
o Deletion of an entry from the TCURX table   (corresponds to changing the decimal places to the standard value of two decimal places)
o Insertion of an entry in the TCURX
(corresponds to changing the standard value of 2 decimal places to a different value), if this is a currency code that already exists
Uncritical changes are any made to this table during the Customizing of a new installation or the insertion of TCURX even during operations, if the currency codes have just been entered in the TCURC table using transaction OY03, signifying that no postings to these currency codes can have been carried out yet.

Similar Messages

JPY Currency issue in SRM 5 Limit Items

Hi
We are having an issue JPY Currency issue in SRM Limit Items (550 SP 13).
Basically the currencies like JPY, KWR where there are no decimals causes value to be multiplied by 100.
There are lot of notes and threads on JPY currency issues.
But I have not found one that helps fix SRM Limit Items.
Let me know if there is a note or thread that talks about it.
We are on SRM 550 SP 13.
Thank You
Nikhil

see MDM forum

Purchase Order with JPY Currency

Hi Friends,
While raising PO with currency JPY, there is an unusual issue noticed in all POs. The netprice is getting truncated by 02 zeros in the end always.
For ex, if a PO with JPY currency is raised with netprice as 98000.00 (Ninety Eight thousand), table EKPO is getting updated with Netprice as 980.00 (Nine hundred eighty) only. This is happening for all POs raised with currency as JPY. But this is not the case for POs with INR, USD or EUR currency. This issue is happening for all POs with currency with JPY.
Can you pl proivde your expertise as to why this is happening?
Regards
Amitava

from OSS note 1176399:
SAP format for amounts
In an SAP system, amounts (data type CURR) are always stored in the database using exactly two decimal places. It does not matter how many decimal places are actually allowed for the relevant currency.
However, amounts are displayed on screens as converted in accordance with their number of decimal places. The number of decimal places, and therefore the shift of the decimal point, is stored in the table TCURX.
Example
The currencies JPY (Japanese Yen) and TWD (Taiwanese Dollar) do not have any decimal places. An amount of 123456 JPY is stored on the database as 1234.56 JPY; however, on the screen (for example, in the PSA maintenance, in the query or in the LISTCUBE) it is displayed as 123,456 JPY (when using the comma as the thousand separator).

Problem with JPY Currency

Hello Experts,
We are facing problem with values which are related to JPY Currency.
In the DSO out put for Key figure Amount in doc currency it is showing 110,43 when you double click it is showing actual value that is 11043.
Because of wrong valus we are getting negative values in the Query.
For other currecies values are correct.
Can any body share why it is displaying wrong values.
Regards
Ram

Hi,
I understand your problem,
You can multiply your values by 100 in the transformation start routine to transfer correct valeus.
Hope this helps.
Regards
Venkat

PO Price in 'JPY' Currency.

Hi Everybody ,
I have the problem in 'JPY' Currency , I print PO Price in 'JPY' on po form but this price removed decimal places.
eq. Po Price is 100. but Po Form Print 1. What is that problem?
   I want Print PO Price 100.
How I print this price?
anybody tell me.
Thanks
S.Muthu,

Hi Narendra,
But only the item price in the printout is wrong, the total amount below is correct. for example:
qty              unit price         subtotal
8pc               70.00             560.00
                         total   =    56,000

Asian (JPY) currency Decimal Places Issue

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.

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
[email protected]

Configuring Global Currencies in BI Apps 7.9.6 for EBS 11.5.10 Source

Hi All,
After reviewing the Configuring Common Areas and Dimensions section of the Oracle BI Applications document [Oracle Business Intelligence Applications Configuration Guide for Informatica PowerCenter Users Version 7.9.6 E14216-01|http://download.oracle.com/docs/cd/E14223_01/bia.796/e14216.pdf] I have a question regarding section +3.1.2 How to Configure Global Currencies+.
Background
OLTP Source: Oracle E-Business Suite 11.5.10
OBI Apps: Financial Analytics 7.9.6
We have 49 enabled Currencies and multiple Sets of Books (SOBs) each with a different Functional Currency and I am concerned with the limitations of the Global Currencies configuration within OBI Apps. From the documentation it states that:
Global currencies. Oracle BI Applications provides three global currencies, which are the common currencies used by the Oracle Business Analytics Warehouse. I'm keen to know if the 3 standard Global Currencies can be extended by adding further custom parameters in the Source System Parameters e.g. $$GLOBAL4_CURR_CODE, $$GLOBAL5_CURR_CODE, etc. and corresponding Exchange Rate parameters $$GLOBAL4_RATE_TYPE, etc.
From the documentation definition of Document, Local and Global currencies, the following configuration for the Global currencies does not make much sense:
$$GLOBAL1_CURR_CODE (for the document currency).
$$GLOBAL2_CURR_CODE (for the local currency).
$$GLOBAL3_CURR_CODE (for the global currency).Presumably these should be the 3 standard Global Currency definitions. If so, I want to confirm that the Document and Local currencies get picked up automatically depending on your EBS configuration?
Thanks for your time, all input greatly appreciated... and points duly awarded :-)
Have a great day.
Kind Regards,
Gary.

Hi,
The 3 Global currency codes are different from functional , local currency.
All the transactions are brought into the warehouse and there is no limitation to the number of currencies that can be brought in but for reporting purpose you want to convert all these transactions in multiple currencies to a single currency ...lets say US$ and at a monthly rate or GBP at a spot rate etc..
So in a nutshell the document and local currenclies do come in and there is no configuration needed but translation to a global reporting currency and the rates at which its converted is determined by what you provide in DAC.. the conversion is done by mplt_currency_conversion which is present in each and every fact mapping.

JPY Currency problem

Hi all,
I have created an Import PO with rate 62500 JPY (decimal places are are not allowed in PO),
But in table level the rate is stored as 625.00 (with 2 decimal)
due to which during GR goods are validated for 625.00 instead of 62500.
Kindly suggest some idea.
Rgds
Srini

Hi Yogi,
I’m facing decimal places problem with the field BSEG-WRBTR for the currency
JPY as no decimals are allowed in standard system. Error: Formatting error in
the field BSEG-WRBTR & Decimal places are not permitted
Our client is posting accounting document through frontend system (interface).
It comes to SAP in xml format.
I have debugged and noticed that it’s taking 2 decimals even the amount in
the xml has no decimals. I’m trying to restrict
decimal for JPY in the interface program.
I have checked in OY04, but for
JPY currency not maintained any decimals.
Kindly share your valuable suggestions.
Thanks,
Rajasekhar S

JPY Currency wrong calculation through BAPI

Hi SAP Gurus,
If i try craete Purchase order by BAPI_PO_CREATE for JPY currency,
For Ex : If we input 1 JPY as net price in BAPi and after creating PO
it is reflecting 100 JPY
Suggest on this how take a call
Regards,
Vinod

hi
JYP currency dont have dcimals so if u have value of 1.00 then it will get read as 100 only
so either u give decmals in jpy currency or try some abaping for this
go to OY04 here give the decimals
regards
KI

Inforecord Net price issue JPY currency

Hi Experts
I am facing an issue in Inforecords Net price when net price is mainatined in JPY currency
The data maintained and as can be seen using ME13 for Net Price for example is 1 JPY
Where as when I fetch this data using EINE table the value is shOWNn as 0.01
( Same is the case when Net price is maintained as 232,687 JPY. In EINE table NET price field this is shown as 2326.87JPY
Please advice why the system behaviour is as mentioned above . Also how can we overcome this issue.
Thanks and Regards
Vikrant

This is because the field is technically defined as currency field with 2 decimals.
Please read OSS Note 53206 - Processing of currency fields.
it explains whatyou have to do in your programs

Decimal places for JPY currency in change documents

Hi Gurus,
For opportunities in SAP GUI the change documents for JPY show incorrect numbers.
The number is divided by 100 (two decimal places added).
Checked the CDPOS table and found the values already divided (two decimal places added).
SPRO->General Settings->Currencies->Set decimal places for currencies is set for 0 decimals for JPY.
Is there any way I can get correct values in the change documents?
Please advice. Any hint is useful.
Thx,
Martin Kuma

Hi Naren,
Thank you for the tip, however the TCURX table is changed via customizing and should be changed only during the system initialization.
What I would like to do, is to assure that the system displays the values in change documents correctly. It should apply the currency conversion for the data displayed the same way it does for all the tables.
Do you have any idea, how should I do this?
Regards,
Martin Kuma

Sending Mail with HUF / JPY currency in Workflow

Hi Friends ,
I have the below requirement .
I have to send PO for approval throug Workflow . I am using " SO_NEW_DOCUMENT_SEND_API1" inside one method to send mail through Workflow .
My Requirement - For JPY / HUF currency PO , Price of PO has to be sent to the Approver which has to be displayed in the Format of Approver's User settings in the mail . Decimal Notation should be as per Approver's User settings.
My Issue - When the workflow triggers user WF-BATCH takes care of fetching the PO price as per its format .( Decimal notaion mentioned for WF-BATCH user ) . Now this has to be changed as per the Approvers formal ( decimal notation ) in the mail that is being sent to Approver after the method execution .
Brief clarification of the issue is mentioned below -
My WF-BATCH user has format of decimal notaion - (1.234.567,89) ,
Approver's has format of decimal notation - X (1,234,567.89)
The PO price in HUF currency is being picked by WF-BATCH user in the method as per its decimal notation .
This formal has to be changed to Approver's decimal notaion format in the method so that same format can be sent in the mail .
If any one has come across this type of requirement , guidance to solve this will be highly appreciated .
Thanks
Prabhudutta

Hi,
You can solve in two ways.
1. Transfer the the value WF-INITIATOR to the method. Then update the Sy-uname start of the method or before the calling the " SO_NEW_DOCUMENT_SEND_API1".
SY-UNAME = lv_user ( where lv_user holds the wf-initiator value[leading US must be removed] )
( background user will be changed from WF-BATCH to wf initiator )
2. convert the date format by using the follwing methods before calling the FM " SO_NEW_DOCUMENT_SEND_API1".
/MRSS/RMOR_USER_CONVERT_DATE
CONVERT_DATE_TO_External
CONVERT_DATE_TO_INTERNAL
Hoping that this might help you.
Thanks and regards,
SNJY
Edited by: Sanju.pal on May 19, 2011 7:17 PM

Import po JPY currency issue

Dear All,
We have a Import PO where the currency of that vendor is JPY which is having 4 decimals. The strange thing is in PO we have 2500 qty while we received the first schedule system is allowing to do GRN for any no of qty.
But for second schedule system is not allowing GRN and throwing Dump error at the tme of 105.
For eg:
PO no: 45000023 has 2500 qty but we did grn only for 100 qty then there is no issue it allowed to do GRN
Second time for 100 qty if we try system is throwing dump error
We created new po there also only for one tme system is allowing to do gr other wise it is not allowing. We did debugging but could not able to find.
Please suggest.

DEar Sir,
Please find the below dump error. I could not able to attach it as document
Category
ABAP Programming Error
Runtime Errors
MESSAGE_TYPE_X
ABAP Program
SAPMSSY0
Application Component BC-ABA-LA
Date and Time
27.03.2014 10:10:12
Short text
The current application triggered a termination with a short dump.
What happened?
The current application program detected a situation which really
should not occur. Therefore, a termination with a short dump was
triggered on purpose by the key word MESSAGE (type X).
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
administrator.
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
Error analysis
Short text of error message:
COMMIT WORK during ON COMMIT or ON ROLLBACK
Long text of error message:
Technical information about the message:
Message class....... 00
Number.............. 085
Variable 1.......... " "
Variable 2.......... " "
Variable 3.......... " "
Variable 4.......... " "
How to correct the error
Probably the only way to eliminate the error is to correct the program.
If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"MESSAGE_TYPE_X" " "
"SAPMSSY0" or "SAPMSSY0"
"%_BEFORE_COMMIT"
If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:
1. The description of the current problem (short dump)
To save the description, choose "System->List->Save->Local File
(Unconverted)".
2. Corresponding system log
Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".
3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".
4. Details about the conditions under which the error occurred or which
actions and input led to the error.
System environment
SAP Release..... 731
SAP Basis Level. 0006
Application server... "msqas"
Network address...... "192.168.140.89"
Operating system..... "Linux"
Release.............. "2.6.32-220.el6.x86_6"
Hardware type........ "x86_64"
Character length.... 16 Bits
Pointer length....... 64 Bits
Work process number.. 12
Shortdump setting.... "full"
Database server... "msqas"
Database type..... "ORACLE"
Database name..... "QAS"
Database user ID.. "SAPSR3"
Terminal.......... "C1031"
Char.set.... "C"
SAP kernel....... 720
created (date)... "Aug 15 2011 20:19:20"
create on........ "Linux GNU SLES-11 x86_64 cc4.3.4 use-pr101110"
Database version. "OCI_112, 11.2.0.3.0, V1, default"
Patch level. 100
Patch text.. " "
Database............. "ORACLE 10.1.0.*.*, ORACLE 10.2.0.*.*, ORACLE 11.2.*.*.*"
SAP database version. 720
Operating system..... "Linux 2.6"
Memory consumption
Roll.... 0
EM...... 37708272
Heap.... 0
Page.... 237568
MM Used. 1309640
MM Free. 2877528
User and Transaction
Client.............. 900
User................ "ADMIN"
Language key........ "E"
Transaction......... "MIGO "
Transaction ID...... "5331516F2A4E2866E1000000C0A88C59"
EPP Whole Context ID.... "5CF3FCE6DD4C1EE3ADABD70ED2D199C7"
EPP Connection ID....... 00000000000000000000000000000000
EPP Caller Counter...... 0
Program............. "SAPMSSY0"
Screen.............. "SAPMS380 0100"
Screen Line......... 3
Debugger Active..... "none"
Information on where terminated
Termination occurred in the ABAP program "SAPMSSY0" - in "%_BEFORE_COMMIT".
The main program was "SAPMS380 ".
In the source code you have the termination point in line 196
of the (Include) program "SAPMSSY0".
Source Code Extract
Line
SourceCde
166
rb_orders_wa-i_level = i_level.
167
insert rb_orders_wa into rb_orders index sy-tabix.
168
endif.
169
endif.
170
endform.
"%_order_form_for_rollback
171
172
173
174
* %_COMMIT_PREPARE
175
* Set date and time for aRFC
176
177
form %_commit_prepare using date time.
"#EC *
178
179
%_sys000-arfc-send_time = time.
180
%_sys000-arfc-send_date = date.
181
182
endform.
"%_commit_prepare
183
184
185
* FORM %_BEFORE_COMMIT
186
* called from RSYN commit.rs1
187
188
form %_before_commit.
"#EC *
189
data: l_oncom like sy-oncom.
190
data: txend type c.
191
192
* forbid COMMIT if already in ON ROLLBACK handling
193
* allow COMMIT during ON COMMIT for backward compatibilty
194
call 'GET_SWITCH_TXEND' id 'STATE' field txend.
195
if txend = 'R'.
>>>>>
message x085(00).
197
endif.
198
199
* COMMIT during CALL DIALOG/SUBMIT, POC, Update task
200
* or End Transaction event?
201
check sy-oncom <> 'N' and sy-oncom <> 'P' and
202
sy-oncom <> 'E' and sy-oncom <> 'V'.
203
* change sy-oncom to avoid recursion
204
l_oncom = sy-oncom.
205
sy-oncom = 'E'.
"E = Event Handling
206
207
* no escape out off this form other than ENDFORM
208
system-call state_limit set.
209
* Hook for Process Information Infrastructure
210
call function 'SPI_AGENT_COMMIT'.
211
* Raise event 'Commit Requested' for Object Manager
212
call method cl_os_transaction_end_notifier=>raise_commit_requested.
213
* restore sy-oncom
214
sy-oncom = l_oncom.
215
Contents of system fields
Name
Val.
SY-SUBRC
0
SY-INDEX
0
SY-TABIX
0
SY-DBCNT
0
SY-FDPOS
0
SY-LSIND
0
SY-PAGNO
0
SY-LINNO
1
SY-COLNO
1
SY-PFKEY
SY-UCOMM
SY-TITLE
ABAP Runtime Error
SY-MSGTY
X
SY-MSGID
00
SY-MSGNO
085
SY-MSGV1
SY-MSGV2
SY-MSGV3
SY-MSGV4
SY-MODNO
1
SY-DATUM
20140327
SY-UZEIT
101011
SY-XPROG
SY-XFORM
Active Calls/Events
No.   Ty.
Program
Include
Line
Name
4 FORM
SAPMSSY0
SAPMSSY0
196
%_BEFORE_COMMIT
3 FORM
SAPMS380
MS380F10
1287
DELETE_OLD_SNAP_RECORDS
2 FORM
SAPMS380
MS380F10
15
INIT
1 MODULE (PBO) SAPMS380
MS380O10
14
PBO_100_MAIN
Chosen variables
Name
Val.
No.
4
Ty.
FORM
Name
%_BEFORE_COMMIT
DP_J2EE_INACTIVE
0
4
04
TXEND
R
5
2
0
0
5200
%_SYS000-ARFC-DONTSEND
2
0
0
0
2000
%_PRINT
000
0###
2222333222222222222222222222222222222222222222222222222222222222222222222222222222222222223000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2000200020002000300030003000200020002000200020002000200020002000200020002000200020002000200020
SY-REPID
SAPMSSY0
5454555322222222222222222222222222222222
310D339000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
5300410050004D00530053005900300020002000200020002000200020002000200020002000200020002000200020
SY-MSGID
00
33222222222222222222
00000000000000000000
00000000000000000000
00000000000000000000
30003000200020002000200020002000200020002000200020002000200020002000200020002000
%_SYS000
00000000000000
2333333333333332222222222222222222222222
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
2000300030003000300030003000300030003000300030003000300030002000200020002000200020002000200020
RST_VB_DISPATCHING_INFO
0
A
0A
SPACE
2
0
0
0
2000
SY-MSGNO
085
333
085
000
000
300038003500
%_TIME_CONFIRMED
001000
333333
001000
000000
000000
300030003100300030003000
SY-MSGV1
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-MSGV2
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-MSGV3
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-MSGV4
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-ONCOM
N
4
E
0
0
4E00
SYST-REPID
SAPMSSY0
5454555322222222222222222222222222222222
310D339000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
5300410050004D00530053005900300020002000200020002000200020002000200020002000200020002000200020
TH_BOOL
0
0
00
%_DUMMY$$
2222
0000
0000
0000
2000200020002000
No.
3
Ty.
FORM
Name
DELETE_OLD_SNAP_RECORDS
DELT-DATUM
00000000
33333333
00000000
00000000
00000000
30003000300030003000300030003000
%_DUMMY$$
2222
0000
0000
0000
2000200020002000
DELT-UZEIT
000000
333333
000000
000000
000000
300030003000300030003000
SY-REPID
SAPMS380
5454533322222222222222222222222222222222
310D338000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
5300410050004D00530033003800300020002000200020002000200020002000200020002000200020002000200020
DELT-AHOST
22222222222222222222222222222222
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SYST-REPID
SAPMS380
5454533322222222222222222222222222222222

JPY Currency Decimal Places

Hi All
Today we noticed a difference in the way SAP handles a PO which has document currency JPY. The price displayed on screen for the PO was 790 JPY, but the value stored in the tables was 0.79. Any reason why this like this ? How does standard SAP handles such cases ?
Regards
Kasi

Hi
There are certain currencies like JPY/Yen for which amounts are automatically handled by SAP. Currency JPY has 0 decimals. Refer TCURX table for the details of decimal places for currencies.
In the case of JPY, system automatically multiplies values when displayed from table to screen and divides vice versa.
FM 'CURRENCY_AMOUNT_SAP_TO_DISPLAY' is used for this conversion.
Amount 7900 JPY on screen will be stored as 79 in SAP tables.
Also, in the case of exchange rate conversions, the rate maintained are for 1:100 to USD (ex). while other currencies would hold 1:1 conversion rate.
You can also check with FI consultants for more details
Thanks
E.Avudaiappan

JPY Currency decimals in SQ01 output

Hi Sap Gurus,
My SQ01 query output has JPY values with decimals. In normal report, we can get appropriate values thru function module BAPI_CURRENCY_CONV_TO_EXTERNAL. But how to achieve this result in ABAP Query?
Thanks in advance...
Best regards,
Madhu

I've introduced an additional field and added code as below
    CALL FUNCTION 'BAPI_CURRENCY_CONV_TO_EXTERNAL'
      EXPORTING
        currency        = bkpf-HWAER
        amount_internal = faglflexa-hsl
      IMPORTING
        AMOUNT_EXTERNAL = zhsl.
It worked.

Re-configure JPY currency

Similar Messages

Maybe you are looking for