Re: [Fwd: Re: [ubl-dev] ExchangeRate amounts]

[Graham Leggett <minfrin@sharp.fm>]

Roberto Cisternino wrote:

> can you make a sample of rounding errors ?
> 
> In my country the rounding of amounts has precise rules so it is implicit.
> 
> I am aware of rounding errors on some big amounts when developers are
> erroneously using double or float numbers instead of using special numeric
> types suitable for big numbers (e.g. in Java this is solved using the
> BigDecimal class)

BigDecimal doesn't solve the rounding problem, which is caused by the
limitations in which computers process maths.

All BigDecimal buys you is support for numbers which larger numbers of
decimal places than you get with the fixed width float and double
formats, and gives you full control over rounding behaviour. What
BigDecimal cannot do is store the number 1/3 (you need infinite RAM to
store this number, 0.333...).

> Thanks for any sample of this issue

A simple example:

Customer agrees to settle an GBP300 000 bill by paying EUR400 000. The
exchange rate is 1.333333... a number that cannot be stored in a BigDecimal.

As the exchange rate wants to be limited to 4 decimal places, you end up
with a rounded off exchange rate of "1.3333".

Because UBL doesn't (yet) have a way to store the target amount, you try
and calculate it from your exchange rate: GBP300 000 * 1.3333 = EUR399 900.

Your target currency amount has a rounding error of EUR100.

If this target currency amount is being used to reconcile against a bank
statement, the reconciliation will fail. If the target currency amount
is being used a decrement a statement balance, the balance will show an
outstanding amount, leading to unnecessary queries.

Regards,
Graham
--