Problem with ABS Arithmetic Function

[former_member185751]

Hi,

I'm doing a SUM(precision of two decimal places) of array of values. I collate the Idocs and then do the sum of that absolute value of AMT field available in the IDoc.

My mapping is simple:

AMT>ABS(XI supplied)>myFUNC_SUM-->TOTAL

When i run a test and investigate the queues of AMT and ABS, I noticed that XI supplied ABS function actually manuplates the decimal part value.

For e.g.

if AMT is 2848275.98 on applying ABS it becomes 2848276

if AMT is 351428.73 on applying ABS it becomes 351428.72

I find it really strange since ABS should only remove the sign.Has anyone experienced this problem before?

I also tested using my own adv.java function (using Java's Math.abs())to do ABS. In this case the decimal part value are not manuplated.

AMT>myFUNC_ABS>myFUNC_SUM-->TOTAL

if AMT is 2848275.98 on applying user-defined ABS it becomes 2848275.98

if AMT is 351428.73 on applying user-defined ABS it becomes 351428.73

Regards,

Sridhar

[Former Member · Accepted solution]

Hi Sridhar,

As a first workaround you could try to use the folowing:

AMT --> FormatNum (0000000000000) --> ABS(XI supplied)

>myFUNC_SUM>TOTAL

I'll check in the meantime why the the ABS function does not work correctly.

Best regards

Joachim

[Former Member · Accepted solution]

Hi,

We believe the problem is the use of float or double, thise have only a limited number of ciffers. We normaly use BigDecimal for mathmatical operations, unless we now that values are not above 1.000.

/daniel

[former_member185751 · Accepted solution]

Hi Dr.Joachim Orb,

Thank you very much for your reply.

I already have a work around in place:

my own adv.java function (using Java's Math.abs())to do ABS.

AMT>myFUNC_ABS>myFUNC_SUM-->TOTAL

The values that i have shown in the first post are the exact values from our test. I have screen shots of the problem scenario and i have also built a test case just to test the ABS function. This may be helpful when SAP wants to dial in and have a look.

Let me know if the screen shots will help you. I can forward to your email ID.

PS:I liked the BPM examples in your book

Regards,

Sridhar

[former_member185751 · Accepted solution]

Hi Daniel,

I'm giving you full points.... because we got the same reply from SAP

The following is SAP's reply:

<i>

...tested this on a SP12 system and I get the same issue

...

...Floating point calculations are not precise - this is point is well-described in Java specification. As a workaround you can create a set of own arithmetic functions which use class java.math.BigDecimal for calculations. The BigDecimal class provides the ability to perform absolutely precise calculations on very big numbers.</i>

you can take a look at the advanced user-defined function for computing ABS() that i have written, here:

https://weblogs.sdn.sap.com/weblogs/images/23292/ABS.gif

Regards,

Sridhar

[thorsten_nordholmsbirk]

Hi Sridhar,

You still risk losing precision or rounding incorrectly with the function you created. This is because you convert the BigDecimal to a double before formatting it.

A better way to output a BigDecimal as a string with 2 decimal places is as follows:

BigDecimal d1 = new BigDecimal("12345.6789"); // original number
BigDecimal d2 = d1.setScale(2, BigDecimal.ROUND_HALF_DOWN); // "normal" rounding rule
String result = d2.toString();

Regards,

Thorsten