credativ team mailing list archive

[Graeme Gellatly <922947@xxxxxxxxxxxxxxxxxx>]

currency_obj.compute method is called.  By default this method rounds
to use currency precision.  Therefore, the precision is set to the
currency field for that calculation.  It is pretty obvious if you
looked at the patch.  But if you really want to test change your
account precision to 5 and call the method with a currency rounded at
0.01.

On Thu, Feb 2, 2012 at 7:23 PM, Amit Parik (OpenERP)
<amp@xxxxxxxxxxx>wrote:

> Hello Graeme,
>
> Yes, you are right we have used a "Account" 's decimal precision for
> unit price which is correct.
>
> But I don't agreed with you that you have specified we have used a
> currency 's decimal accuracy for cost field.
>
> That's why here we need a more information, So would you please provide
> us.
>
> Thanks and waiting for your reply!
>
>
> ** Changed in: openobject-addons
>       Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/922947
>
> Title:
>  [trunk] Rounding bug in average price computation
>
> Status in OpenERP Addons (modules):
>   Incomplete
>
> 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
>

-- 
You received this bug notification because you are a member of OpenERP
Framework Experts, 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):
  Incomplete

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