← Back to team overview

openerp-expert-accounting team mailing list archive

Re: Floating point precisions, balanced entries and VAT included ref

 

2010/3/6 <geoff.gardiner@xxxxxxxxx>

> ...
> > That's cool to see we then seem to agree on every points!...
>
> :-)
>
> > > But OpenERP SA are already changing things to Decimal anyway, aren't
> they?
> > Iv'e seen nothing in that direction yet. ...
>
> I just saw "We started the implementation of this feature, to be released
> in two weeks in trunk." at the top of
> https://blueprints.launchpad.net/openobject-addons/+spec/generic-accuracy-improvement,
> but I wasn't sure when that was written.
>
> Geoff



Geoff,

On my side, I got confirmation from Cedric Krier (Tryton lead) on twitter
that they use Decimal for accounting indeed: "#tryton uses #Decimal since
the beginning because we know this is the only way to do accounting"

Now, let's keep focused in this thread:
the original issue Sebastien demonstrated here is nothing related to Python
Decimal or anything that technical, it's just it seems there is a logic
mistake mixing both methods 1) and methods 2) when computing VAT in OpenERP
that shows up with the unbalanced entries bug as soon as you have some VAT
excluded price with more than 2 digits.
Reasons you would use a VAT excluded price with more than two decimal can
be:
- because you need that pricing accuracy (the original purpose of
price_accuracy)
- or be it because you would like to match a VAT included price given by
some external system such as our ecommerce (using or not some tax_include
module).

May be I come up with a summary in a next post, where I'll aggregate the
other points that have been made here but are unrelated to Sebastien's mail.
Hopefully I also have time to test some patch prototype and submit it for
evaluation, we are indeed stuck with 2 ecommerce integrations because of
this and need to come up urgently with a working patch. Sebastien suggest an
option to allow choice between method 1) and method 2). Well, I suggest we
first try to get only method 2) working, for us it would do the job (we
would have a cents variation between the VAT total of the ecommerce order
and the VAT total of the OpenERP invoice then, but VAT included price would
all match and entries would be balanced, I believe this will be good enough;
as we've seen, method 1) has its own drawbacks: the cents delta would be
this time between the account move lines and the invoice lines, which at
least is forbidden here in Brazil. And again we believe those cents
variation have nothing to do with Python floating precision, they are
entirely resulting from the legal accounting limited precision (see
Sebastien's example), I personally don't see why Python floats wouldn't have
sufficient precision here. Please if some disagree with that, try to
demonstrate it with a simple example (message for Cedric Krier: feel free to
send me a message to r-v-a-l-y-i-@xxxxxxxxx to forward here if you like).

Regards,

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

Follow ups

References