openerp-india team mailing list archive

[Graeme Gellatly <922947@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

This is hard to describe in terms of steps to reproduce.  All testing on
latest sources.  It is quite related to all the workarounds that people
need to implement due to weaknesses in decimal precision (see the
multiple other reported bugs over the past 18 months).

Basically when a products cost field has a decimal precision that is
different to the currencies decimal precision, the average cost
calculation uses the currency's precision.  This causes average costs
for precisions different than the currency to be rounded incorrectly.

In our case we have a decimal precision of unit, set to 5 places (so
over riding the 'Account' precision setting) for all unit type fields
and an account and currency precision of 2.

The fix is very simple and should not affect in any way standard
implementations, as all the callers of this function are passing in
appropriately rounded numbers already from the picking wizards and stock
moves all of which have precisions set.

Patch attached.

** Affects: openobject-addons
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/922947

Title:
  [trunk] Rounding bug in average price computation

Status in OpenERP Addons (modules):
  New

Bug description:
  This is hard to describe in terms of steps to reproduce.  All testing
  on latest sources.  It is quite related to all the workarounds that
  people need to implement due to weaknesses in decimal precision (see
  the multiple other reported bugs over the past 18 months).

  Basically when a products cost field has a decimal precision that is
  different to the currencies decimal precision, the average cost
  calculation uses the currency's precision.  This causes average costs
  for precisions different than the currency to be rounded incorrectly.

  In our case we have a decimal precision of unit, set to 5 places (so
  over riding the 'Account' precision setting) for all unit type fields
  and an account and currency precision of 2.

  The fix is very simple and should not affect in any way standard
  implementations, as all the callers of this function are passing in
  appropriately rounded numbers already from the picking wizards and
  stock moves all of which have precisions set.

  Patch attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/922947/+subscriptions