cancel
Showing results for 
Search instead for 
Did you mean: 

Handling Currency Formats in WebDynpro

Former Member
0 Kudos

Hi,

We have a scenario where we have to display different currencies in their own format.

The input structure is copied from a model node. The attribute is a simple type coming from the backend . When user enters the value ,an event is raised and some RFC s are called.

Finally, the input which the user is entered is formatted correctly based on the currency he has chosen.

When we debug, the node does not have the value in the proper format which is displayed. Its not a calculated attribute too.

So how is currency formatting handled for different currencies... in webdynpro ?

Here setR3NormalizingFormattingAttribute is used for the attribute. Does this handle this formatting ?

How is backend setting of currency formats in TCURX handled ?

Any idea on currency handling in WebDynpro would help.

Regards

Bharathwaj

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Bharathwaj,

see here:

http://help.sap.com/saphelp_nw2004s/helpdata/en/32/4fe741497b0b7fe10000000a155106/frameset.htm

hope this will help

kind regards

Stefanie

Former Member
0 Kudos

Hi Stefanie,

Thank you. Here they are using currency normalized by calling

setR3NormalizingFormattingService(true)

This , I guess handles the formatting. But when i try to access the value from the node attribute it's giving an incorrect value.. This is quite surprising .. If

If the currency specification is to correspond to the ERP system, will the attribute itself have a proper formatted value form R3 .Or is it that , we need some other handle to get the formatted value. ?

Was i clear about what the scenario is ?

Regards

Bharathwaj

uwe_reeder
Explorer
0 Kudos

Hi Bharathwaj,

Well, setR3NormalizedFormattingService (true) has exactly the described effect. In the context, all amounts will always have exactly two decimals, regardless of what the currency actually expects. Only when formatting for display and parsing user input, the real number of decimals is used. This is the same procedure as with CURRs in R/3.

The reason is that sometimes standard RFC and sometimes BAPIs are used for data transfer between Java and R/3. RFCs make no conversions of the transferred data, while BAPIs do. We are not able to do the conversion in the transfer, because neither Web Dynpro nor dictionary have the information whether the called RFC already has done it. So we decided to mark the attribute that it contains "R/3-normalized" values.

Regards,

Uwe

Former Member
0 Kudos

Uwe,

AFAIK it is not RFC vs BAPI question but rather the following: if ceratin data domain defines data conversion exit then it is applied, otherwise it's not.

VS

Former Member
0 Kudos

Hi Bharatwaj,

You can use the NumberFormat from java.text package to do currency formatting in this way.

NumberFormat nf = NumberFormat.getCurrencyInstance(<get user locale>);

nf.format(double or long);

Hope that helps,

Thanks,

Rajit Srinivas

Former Member
0 Kudos

Hi,

Its not locale based. Depending on the currency type it has to be formatted.

There might be more than one currency type in the same screen.. formatting would vary for each of them..

Plus.. this function mentioned.. usually adds a symbol .. in front of the currency.. which is not the required function..

Thanks for the help..

Regards

Bharathwaj