Sunday, March 29, 2009

Internal Storing Formats of Typical Currencies Viren Devi

Fundamentals:

Many of us are aware of how the concept of currency translation works in BW, in terms how it fetches exchange rates and where we can perform the translation. However it is unlikely to know how some of the currencies like HUF, KRW are stored in the underlying tables. This blog sheds some light on these currency related fundamentals, issues and implemented solutions.

In cases of some typical currencies like JPY, KRW, HUF etc. there is a difference in how values are stored in the SAP tables and how they are displayed to the users. This depends on the number of decimals maintained in the TCURX tables against that corresponding currency. In the case of JPY, KRW and HUF it is maintained as 0 which indicates that it is not supposed to have any decimal places after the actual value. But in BW most of the currency value fields are of data type CURR (mostly 2 decimal places). This means during the storing process, it should store the values with two decimal places which violets the above statement!

How SAP tackles this can be simply explained through the below example,

Currency: HUF

E.g.

I. Entered value in VK11 (Pricing transaction): 329186
II. Stored value in the table KONP: 3,291.86
III. Stored value in the DSO table of BW: 3291.86
IV. Displayed value to the users in reports build on the DSO: 329186

In the event that entry is not maintained for the currency in table TCURX, it is done by default to two decimal places (GBP, EUR etc). As external representation depends on the decimal places maintained against the currencies in ‘TCURX’ table, value stored and displayed is same in case of GBP, EUR.


Practical Issue : The question is how does this internal format affects us? Please see below as an example.


Example:

In the case where values are passed from a DSO to the APD by using a Query, above fundamentals are not taken care of by the system,
Flow Chart

Currency: HUF

E.g.

I. Entered value in VK11 (Pricing transaction): 329186
II. Stored value in table KONP: 3,291.86
III. Stored value in BW table of DSO1: 3291.86
IV. Stored value in the direct update DSO2, and DSO3 : 329186.00
V. Displayed value in the report based on the DSO3 : 32918600

Stored values in the directly update DSO2 look incorrect which indicates the APD is not intelligent enough to understand internal/external formats. The query reads the value and stores it to directly update DSO2 as 329186.00 considering it has 0 decimal places. In case any other data flow loops on the DSO3, it will fetch 32918600 instead of 329186.

Solution:

To resolve the issue either we need to introduce a routine in between to check decimal places in the TCURX table and divide the value in multiples of 10 or find a standard SAP function module. We actually found a standard SAP function module ‘/POSDW/CURRENCY_DECIMALS_IN’. This module divides the passed input with multiples of 10 as per the number decimal places maintained in the table.


Declaration:

DATA: wa_CURRENCY TYPE /BI0/OICURRENCY,
wa_round(16) TYPE p DECIMALS 0,
wa_result type /posdw/amount,
wa_round1 TYPE char17.

Code :

CALL FUNCTION 'ROUND'

EXPORTING
decimals = 0
input = Price

IMPORTING
output = wa_round

.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

WRITE wa_round TO wa_round1.

REPLACE ALL OCCURRENCES OF ',' IN wa_round1 WITH SPACE.
CONDENSE wa_round1.


wa_CURRENCY = Currency.

CALL FUNCTION '/POSDW/CURRENCY_DECIMALS_IN'

EXPORTING
PI_AMOUNT = wa_round1

IMPORTING
PE_AMOUNT = wa_result

CHANGING
pc_currency = wa_CURRENCY


* result value of the routine
RESULT = wa_round1.

All the steps before calling module /POSDW/CURRENCY_DECIMALS_IN’ are to convert data type CURR to CHAR.


Corrected output would look like below,

Currency: HUF

E.g.

I. Entered value in VK11 (Pricing transaction): 329186
II. Stored value in table KONP: 3,291.86
III. Stored value in table DSO1 of BW: 3291.86
IV. Stored value in the directly updated DSO2 : 329186.00
V. Displayed value in the report based on the directly updated DSO2 : 32918600
VI. Output of routine which includes function module : 3291.86
VII. Displayed value in the report based on the directly updated DSO3 : 329186


Note:

We faced above mentioned issue while we were on support package 8. After upgrading the package to 16, problem is resolved. This means that, it may not stand true in all the cases.

In case above routine doesn’t exist in your system; please let me know on viren.devi@capgemini.com Id.