← Back to team overview

c2c-oerpscenario team mailing list archive

[Bug 847867] Re: [trunk][purchase]Seller quantity for procurements uses default UOM

 

Hello John,

Thanks for your reply with nice explanation and patch.

I have faced the problem because of the Supplier (seller_qty) qty can
not be converted in the Purchase UoM.

The problem appears when we have given the different Purchase UoM then
the default UoM which is "Bigger than the reference uom".

IN max(qty,seller_qty) function gives the wrong Quantity because of the here "seller_qty" doesn't converted.
According to function it should return maximum but qty is 0.2 and seller_qty is 1.0 (instead of 0.1).

I have attached the video which shows the problem(purchase_uom_bug).
After applying your patch it is working fine.(kindly check attached
videopurchase_uom_with_patch).


** Attachment added: "purchase_uom_bug.ogv"
   https://bugs.launchpad.net/openobject-addons/+bug/847867/+attachment/2411966/+files/purchase_uom_bug.ogv

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

Title:
  [trunk][purchase]Seller quantity for procurements uses default UOM

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  It appears that seller_qty is calculated using the default UOM rather
  than the purchase UOM. This might not be an issue for most things, but
  if the purchase UOM and default UOM are different, the quantity for
  PO's from procurements may be wrong.

  For a test case, create a product 'XYZ' with a default UOM of 'each'
  and a purchase UOM of 'each x 10'. Now add a procurement order for
  quantity 2 of XYZ. When the purchase order is created, the quantity
  will be 10.

  make_po() sets the qty to the supplier minimum (which uses the default
  UOM) or the procurement, whichever is higher. In this case it's the
  incorrect supplier minimum calc'd to be 10.

  I'm not sure the seller_qty should be using the default UOM, it might
  make more sense for it to use the Purchase UOM, but the attached patch
  updates make_po() to do the conversion on seller_qty instead. The
  alternative would be to update _calc_qty() and change the UOM used.

  Patch attached for latest trunk.

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


References