openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello Fabien,

2010/3/6 Fabien Pinckaers <fp@xxxxxxxxxxx>

> [...]
>
> I think we should not move to decimal for several reasons:
>

OK, good to know. If somebody as a counter example where Float are not
enough, please shout, as for now, we seem to agree, Float are far enough for
the examples Fabien provided given that accounting need only 2 digits (or
are there countries where much more is required, like 4?).

>
> [...]
>
> I confirm that, the computation mistake is a bug in the tax computation
> on the invoice, that appears if you change the price_accuracy bigger
> than 2. (not related to the type but to the way we compute the tax)
>

All right, it seems we all agree then.

>
> [...]
>
> We plan to write YAML scenario within the next two weeks and then, fix
> this issue in trunk. Do you have a scenario that emphasizes this problem ?
>

This is the original mail from Sebastien, at the end of it when he
reproduced the OpenERP computation with price_accuracy=4. But now that we
seem to all agree on that we will try to clean up the test-case. Hopefully I
get time to try a fix too.

And by the way, an example where more than 2 decimal digits are required for
OpenERP to give same VAT included prices as an external sale system is:
VAT included price = 9 euros and VAT rate = 19.6% (French TVA), indeed with
2 digits you can only have:
7.52*1.196 ~=  8.99
7.53*1.196 ~=  9.01
so here you need 3 digits for VAT excluded price accuracy and then run into
the unbalanced entries bug. I think the required price accuracy increase
should somewhat be implied by the VAT included computation method otherwise
you get rounding errors, such as we reported here:
https://bugs.launchpad.net/openobject-addons/+bug/510726 .

We should talk about that too for the VAT included method refactoring
because in that case we only want increased precision on the VAT excluded
price and nowhere else. So I mean it should increase accuracy, but not the
same way than the price_accuracy does (example: you want both VAT included
prices and price accuracy of 3, then you need VAT excluded price accuracy to
be 4 this time and VAT included price accuracy to be 3). And as Cloves
suggested, we also would may be better no hardcode the 2 precision limit for
accounting but let it be a parameter as it might be different than 2 in some
countries like Japan.

Raphaël Valyi
http://www.akretion.com