openerp-india team mailing list archive

["Amit Parik \(OpenERP\)" <amp@xxxxxxxxxxx>]

Hello Greame,

Thanks for your reply!

Yes, you are right. The new_price is rounded based on currency's precision instead of "Purchase Price"
I have reproduce it at my end as well as faced the same problem. I have tried your patch and it's working fine.

Steps to reproduce.

First I have set a "Purchase Price" 's decimal 5 and Currency 's decimal
0.01 (As described).

I have created on product A with "Average" costing (1.00 qty and price 100.00). Creates a PO with price 100.2687 done the reception.
Now I have checked the cost of product which is 100.13500 instead of 100.13435 because it's rounded after two digits which is defined in currency's precision.

I have applied a patch and it's calculated correctly and gives proper
output(100.13435).

Thank you!


** Changed in: openobject-addons
   Importance: Undecided => Low

** Changed in: openobject-addons
       Status: Incomplete => Confirmed

** Changed in: openobject-addons
     Assignee: (unassigned) => OpenERP R&D Addons Team 2 (openerp-dev-addons2)

-- 
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):
  Confirmed

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