General

Re: Calculation Bug with Addition?

Greg Collins — Thu, 27 Jul 2006 19:48:31 GMT

You can set a default value formula for each such field with the formula:
round(. * 100) div 100

But this seems to have the peculiar side-effect of changing a blank value to 0.0 (assuming a single decimal place) instead of leaving it blank. This effefct however, might be okay for your situation.

Good luck.

Re: Calculation Bug with Addition?

mbenbow — Thu, 27 Jul 2006 13:27:10 GMT

Hey,

That might work for a plain value or even a multiplication problem. But I have found that if you are adding a series of fields, you have to perform the (round(Field1 * 10) / 10) + (round(field2 * 10) / 10) + (round(field3 * 10) / 10) in order to get the correct result for the user.

The reason is this....if you set a field as a decimal with 1 decimal place, the user can actually type into the fields 1.856, 4.225 and 6.151 - but InfoPath will display the following to the user 1.9, 4.2 and 6.2 (the data file will actually hold the 1.856, 4.225 and 6.151 values). To the user the 1.9 + 4.2 + 6.2 = 12.3; when mathematically the result is actually 12.232

If you use the Round(value*10)/10 the result would be 12.2 and not 12.3

Ensuring that all values that the user can enter into a field and have the it function correctly mathematically is a pain to say the least in InfoPath. We have just rolled out 300+ forms in an enterprise environment and this is the biggest issue.

Argh!!!!

Re: Calculation Bug with Addition?

Greg Collins — Tue, 25 Jul 2006 23:43:26 GMT

Sounds like an issue. For a workaround, use the round() function:

round(value*100)/100

the 100 gives you two decimal places. For three, you would use 1000, and so on.

Calculation Bug with Addition?

mbenbow — Tue, 25 Jul 2006 21:25:43 GMT

Hey,

This has happened on a couple of forms and it took me a while to figure out the issue.

At the top of the form is a field for the user to enter the amount of the check (decimal - 2 decimal places). The form also has a repeating table that allows the user to enter the GL code and the amount to apply to the GL code(s). A validation calculation field is used to show whether the check amount equals the sum of the GL code amounts.

Here is the issue and I need to test further with other prime numbers for the cents.

If the user enters 250.23 for the check amount and enters 3 GL codes with amount 1 = 50.20, amount 2 = 100.03 and amount 3 = 100.00, the validation calculation will report that the sum of (50.20 + 100.03 + 100) does not equal 250.23 check amount.

All fields are set to decimal with 2 decimal places....but in determining where the error was being generated....the validation calculation is performing a rounding error and the sum of (50.20 + 100.03 + 100) in the field is actually 250.230000002 even though it displays 250.23

I know how to get around this issue but it appears to be a bug because if I put the check amount at 250.48 and the 3 GL amounts at 50.44, 100.04 and 100 there is no rounding error.

Anyone else experience this?

Thanks,
Mary