openerp-expert-accounting team mailing list archive
Mailing list archive
Re: Floating point precisions, balanced entries and VAT included ref
> 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"
No, you can not have troubles with float numbers. (unless you have more
than 10^16 lines in your sale order, or prices bigger than
99,999,999,999,999.99) -> nobody have this. The turnover of Microsoft on
one year is only: 19,000,000,000. You have to do a sale order which is
1000 times bigger than Microsoft's annual revenue to risk a rounding
issue of 1 cent.
I think we should not move to decimal for several reasons:
* Decimal are slow
* Decimal is complex to manipulate
You can not do a Decimal * Float
You can not simply do Decimal * Decimal (you have to set the context
per thread first otherise you get a wrong number, In python:
>>> Decimal('13.12') * Decimal('12.32')
-> This is not what you expect in an accounting module. So, with
decimal, you also have to round like float after/before the
* XMLRPC does not support decimal, and crash if you try to send/receive
decimals. It means most of your methods can not return a dictionary
containing decimal objects.
It's the same for most standard web-services like SOAP.
* Decimal can not manage the rounding we need (example in CH: 0.05 FR),
so we need to call rounding methods on currency object to round
prices. We can not expect the decimal module to do it for us.
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)
I already changed the trunk to support float fields having dynamic
digits. (using numeric in postgresql and doing a decimal conversion
before writing to pgsql).
All modules have been adapted to be fully configurable per db:
- sale : 2 digits
- accounting : 2 digits
- stock weight: 4 digits
- purchase : 2 digits
-> You can configure this through the interface.
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 ?
CEO Tiny - OpenERP Editor
Chaussée de Namur 40
Great Achievements Start With Tiny Investments
-- Marty, 2005