← Back to team overview

openerp-expert-framework team mailing list archive

Re: float errors propagating to 10^-2 in OpenERP v5...

 

Guys,

I think we are now a lot to agree that Dominique's argument on Float is
valid. I only wanted to show a real practical pathological example that
proves that OpenERP won't behave like traditional BCD accounting softwares.
It has not be as easy as you might think as sometimes Python rounding
was surprisingly right, but I think I have a simple real example:

let product unit price be 0.70 Euros
and apply a tax of 5%

When computing the tax, with Python Float we get:
>>> 0.7*0.05
0.034999999999999996
which is then rounded to 0.03 in OpenERP
BUT, in manual decimal accounting (or BCD accounting devices/softwares) we
have instead:
0.7*0.05 = 0.035 which is then rounded to 0.04 !!! (the law in France says,
when it ends with 5 at the 3rd digit you should round up)

I just tested it in OpenERP v5 an v6 and both make the error, you can test
it's easy.

Do we all agree this is our practical pathological case?

Then again, how annoying is that?
1) is that just annoying that it's different from traditional BCD accounting
software?
2) or is that illegal so accountants will refuse such numbers coming from
OpenERP? (would be frightening then)

In both case I think we could save our life by introducing some Decimal here
at VAT computation for instance specifically (an possibly elsewhere). But in
any case I would love to hear accountants and Tiny on this one. What do you
guys think of that case? Thanks.

NB: again, once this BCD "convention error" is made, there is no further
accounting error where sums wouldn't match or anything like that (at least
if we don't try to re-round the same computation but done a bit differently,
which requires care when coding, further errors don't happen).


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>



On Wed, Aug 18, 2010 at 9:41 PM, bounaberdi <dominique.chabord@xxxxxxxxxx>wrote:

>
> hi
> Raphaël Valyi wrote:
> >
> > I can read things like if 3rd decimal reaches 5 should
> > be rounded up, else down.
> >
> This rule is often ignored by non accountants, as the previous discussion.
> (0.101 was the right answer)
>
> Raphaël Valyi wrote:
> >  However, nowhere I can see if a 10^⁻17 epsilon is
> > tolerated in the computation before we do that rounding (it's hard for me
> > to
> > believe it's not tolerable as it would make simple daily accounting
> pretty
> > challenging and that's why I ask for legal texts or specialists
> > interventions upon this).
> >
> Reports must be "acurate", which means cents must be exact.
> In many audits, only cents are checked first because it is fast. If cents
> are not correct, then it's usually not needed to control any further. The
> report is rejected.
> There is no problem in daily accounting because all devices calculate in
> BCD
> for this reason. The first hand-held calculator since 70s, and any
> spreadsheet with the "finance" format does it. A cashier has to calculate
> in
> BCD.
> Accountants have never learnt one can calculate differently than in base
> ten, so you'll probably not find a law. Anyway, regarding French legals,
> there are more important reasons to be careful.
>
>
> --
> View this message in context:
> http://openerp-expert-framework.71550.n3.nabble.com/float-errors-propagating-to-10-2-in-OpenERP-v5-tp1175425p1217623.html
> Sent from the openerp-expert-framework mailing list archive at Nabble.com.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References