openerp-expert-framework team mailing list archive

["Borja López Soilán (Pexego)" <borjals@xxxxxxxxx>]

Raphaël Valyi wrote:
>  (the law in France says, when it ends with 5 at the 3rd digit you 
> should round up)

That is also what is usually done in Spain; but:

   * I couldn't find a legal requirement to do so on a general case
     (though there exists such a requirement on specific cases like
     currency conversions between the outdated "peseta" and euros).
   * It seems that countries in the European Union have the right to
     decide themselves whether to apply such rule or not when
     calculating VAT taxes:  http://www.fiscal-impuestos.com/node/2921
     (sorry, link on spanish). So maybe that rules does not even apply
     on all the EU countries!




Anyway, now that we have some attention on the rounding problems, I 
would like to comment that OpenERP rounding problems were (are?) worse 
than what you might think! (and I'm not talking about "float vs Decimal")...

It was already reported (long time ago) that on some places OpenERP was 
not rounding as it should. There were checks like "if abs(amount) < 
10**-int(config['price_accuracy']):", when they should be the much 
clearer "if round(abs(amount), int(config['price_accuracy'])) <= 0:" (as 
Ferdinand stated once).

On 2010-04-10 Olivier commited a patch that solved this for the 
_validate method of the account moves. So, on versions 5.0.9 and lower 
it was possible to create a non-balanced account move that would get 
validated anyway!

But anyway, as an example of inconsistence, this is the current state 
for that single check:

   * On >=5.0.10 it has been replaced with "if abs(amount) < 10 **
     -(int(config['price_accuracy'])+1):"
   * On 6.0 it has been replaced with hard-coded limit "if abs(amount)
     < 10 ** -4:"   (Yeah, I want to hear a big "WTF!")



Some examples using python code:

>>> config = { 'price_accuracy': 2 }

/# First case (non significative difference):/

>>> round(0.001, 2)                                          # This 
difference shouldn't matter (< price_accuracy after rounding)
0.0
>>> 0.001 < 10**-int(config['price_accuracy'])               # OpenERP 
<=5.0.9 check - Good
True
>>> 0.001 < 10**-int(config['price_accuracy']+1)             # OpenERP 
>=5.0.10 check - *Bad?*
*False*
>>> 0.001 < 10**-4                                           # OpenERP 
>=6.0 check - *Bad?*
*False*
>>> round(0.001, int(config['price_accuracy'])) <= 0.0       # 
Ferdinand proposed check - Good
True


/# Second case (significative difference):/

>>> round(0.0099999, 2)                                      # This 
difference should matter (>= price_accuracy after rounding)
0.01
>>> 0.0099999 < 10**-int(config['price_accuracy'])           # OpenERP 
check - *Very bad!**: An unbalanced move with a 0.01 amount difference 
(one cent) could be validated by OpenERP!*
*True
*>>> 0.0099999 < 10**-int(config['price_accuracy']+1)         # OpenERP 
>=5.0.10 check - Good
False
>>> 0.0099999 < 10**-4                                       # OpenERP 
>=6.0 check - Good
False*
*>>> round(0.0099999, int(config['price_accuracy'])) <= 0.0   # 
Ferdinand proposed check - Good
False
/
/
This kind of checks where also used on some financial reports; so as you 
can see OpenERP would not always work "as expected" with values close to 
0.01:

   * Previously (<=5.0.9) unbalanced moves with a ~0.01 amount
     difference could get validated by OpenERP! Or accounts with a
     balance of ~0.01 could be ignored on financial reports.
   * Currently (>=5.0.10) accounts with a balance of >=0.001 and less
     than the price accuracy might get displayed on financial reports
     even if the user selects to print "only accounts with balance"
     (they might get printed, but they would still print as 0.00).


Conclusion: Bad coding might be a far worse problem than the "float vs 
Decimal" one.

--
Borja López Soilán
borjals@xxxxxxxxx

Pexego Sistemas Informáticos S.L.
Avenida de Magoi 66 - 27002 Lugo (España)
Tel./Fax 982801517
http://www.pexego.es 


AVISO LEGAL - CLÁUSULA DE PRIVACIDAD
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda informado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.