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/>
<http://www.akretion.com.br/>
On Wed, Aug 18, 2010 at 9:41 PM, bounaberdi
<dominique.chabord@xxxxxxxxxx <mailto: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
<https://launchpad.net/%7Eopenerp-expert-framework>
Post to : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
<mailto:openerp-expert-framework@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openerp-expert-framework
<https://launchpad.net/%7Eopenerp-expert-framework>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
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
