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: 

How to avoid rounding off the values of NETWR to 2 decimal places?

Former Member
0 Kudos

Hi all,

I have the below problem:

I have a value related to currency for which I need to avoid round off (after a calculation involving multiplication and division) and display the value with 4 decimal places.

Example,

currently the value is rounded off to 49.41 from 49.4099999999.

I need it as 49.4099.

I have tried changing the data element to 4 decimals but that does not work and the value comes out to be 49.4100.

Please help.

1 ACCEPTED SOLUTION

horst_keller
Product and Topic Expert
Product and Topic Expert

Read the documentation about arithmetic expressions, calculation type and conversion rules.

As an ABAP developer you should know that.

10 REPLIES 10

horst_keller
Product and Topic Expert
Product and Topic Expert

Read the documentation about arithmetic expressions, calculation type and conversion rules.

As an ABAP developer you should know that.

0 Kudos

Also don't use a currency amount type if you don't want to respect the number of decimals associated with the currency code (Never change this one!) The remainder is only affair of rounding calculation that can be find in online documentation (and your Abap Course material)

0 Kudos

Thanks for the reply Horst Keller.

I had read the documentation about arithmetic expressions, but as the calculation formula involved had some variables with 2 decimal places, the output was with 2 decimals only.

Thanks anyways!!

Former Member

Try below sample code. You will see the desired result.

CONSTANTS c_val TYPE c LENGTH 50 VALUE '49.4099999999'.
DATA lv_result TYPE p DECIMALS 4.
DATA(out) = cl_demo_output=>new( ).

lv_result = round( val = c_val dec = 4 mode = 5 )."ROUND_DOWN

out->write( lv_result ).
out->display( ).

0 Kudos

Thanks for your reply, but the value mentioned in my question is calculated using a formula, so I think we cannot declare it as constant.

Thanks anyways!

Sandra_Rossi
Active Contributor
0 Kudos

It would be very interesting to know why you need to do this apparently-weird rounding on a currency amount.

Former Member
0 Kudos

🙂

Yes, it is a little interesting, given that we are not always sure what the client will ask for.

But I need to fulfill the requirement anyways.

Actually there is a conversion based on the currency and this value is being printed in the form.

The conversion is little complicated and the decimals are converted to comma (,) in the output due to this conversion. Also, due to this conversion no decimal places are shown in the output.

Example, 49.41 is converted to 4,941.

Now, the requirement is to display two decimal places in the output as the decimal is converted to comma.

Something like this: 4,940.99

I had added '.00' externally but they want to display some value instead of '.00'. So to fulfill this requirement, the team has decided to display 4 decimal places after the value is calculated and they change it back to 2 decimals. This will hopefully remove the problem of '.00'.

Hope you got it!

😄

Thanks for commenting.

Former Member
0 Kudos

I got the output. I had to break the formula to 3 parts and store the value in a local variable with 4 decimal places.

This was done because the formula contained some variables which were declared as 2 decimals.

Because of this the final value was coming out to be with 2 decimals.

The local variable now displays the value with 4 decimals.

Thanks everyone for the help!

🙂

Lakshmipathi
Active Contributor
0 Kudos

Not sure, whether you have gone through OSS note 403254 where it explains how rounding works

easygoer61
Discoverer
0 Kudos

I had sort of the opposite problem, where a series of discounts resulted in a condition value that did not divide evenly into the unit price. Our customers would never accept an invoice where the math didn't extend out correctly. I checked the standard pricing procedure and found that applying the NETP condition type with the requirement 2 / calculation type 6 / basetype 3 takes care of rounding the condition value for you, so the math will work and customers will not complain.