c2c-oerpscenario team mailing list archive

[mrockel <707923@xxxxxxxxxxxxxxxxxx>]

Marco,
please read,
http://docs.python.org/tutorial/floatingpoint.html#tut-fp-issues

Other surprises follow from this one. For example, if you try to round the value 2.675 to two decimal places, you get this
>>> round(2.675, 2)
2.67
The documentation for the built-in round() function says that it rounds to the nearest value, rounding ties away from zero. Since the decimal fraction 2.675 is exactly halfway between 2.67 and 2.68, you might expect the result here to be (a binary approximation to) 2.68. It’s not, because when the decimal string 2.675 is converted to a binary floating-point number, it’s again replaced with a binary approximation, whose exact value is
2.67499999999999982236431605997495353221893310546875
Since this approximation is slightly closer to 2.67 than to 2.68, it’s rounded down.

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/707923

Title:
  [6.0 and 5] invoice tax - rounding issue

Status in OpenERP Modules (addons):
  Won't Fix

Bug description:
  see attachment

  due to rounding of the calculated tax for each position we get totals
  which are wrong.

  In Austria we usually group the basis per tax rate and calculate the
  tax from this basis to avoid such errors.

  in account/invoice.py
  class account_invoice_tax  - 
  def compute must be modified 

  actually only some lines of code to group the invoice lines before
  calculating the tax

  probably this has been discussed (but not solved) already