openerp-expert-accounting team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

> 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')
       Decimal('161.6384')
    -> This is not what you expect in an accounting module. So, with
   decimal, you also have to round like float after/before the
   operations.
* 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 ?

-- 
Fabien Pinckaers
CEO Tiny - OpenERP Editor
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com

Great Achievements Start With Tiny Investments
  -- Marty, 2005