c2c-oerpscenario team mailing list archive

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

Hello Kyle,

Form your scenario it is working as expected in trunk 6.0.

Follow this steps.

1) create a three different product A,B,C Set UOM as a PCE and create a minimum stock rule then create a BOM like
    A (UOM-PCE)
        ->B (UOM-PCE)
        ->C (UOM-PCE)
2) Create a sale order of A.
3) Run the scheduler. Now you have a real stock available of product A and stock moves also.
4) Go to product view and change the UOM (FT).
5) Create a MO and you Got this Error: 
         "Conversion from Product UoM m to Default UoM PCE is not possible as they both belong to different Category!." 
      which is proper because you can not create a MO if BOM and product's UOM is not same.
6) Now go to product A 's BOM and change the UOM (Same as product's UOM)
   Now BOM like
       A (UOM-FT)
        ->B (UOM-PCE)
        ->C (UOM-PCE)
7) Create MO , it will successfully created. So Stock moves are not affect it.

Now the all are working as expected. So, would you check it again and
tell me where you face the problem.

Thanks

-- 
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/707287

Title:
  Manufacturing orders broken UOM

Status in OpenERP Modules (addons):
  Incomplete

Bug description:
  We have around 5,000 products. We have custom UOM like ft, OZ and
  Pound. On certain products we cannot make manufacturing orders with
  this error

  Conversion from Product UoM m to Default UoM PCE is not possible as
  they both belong to different Category!.

  It is extremely frustrating because it doesnt make sense. We do not
  have a single product with UoM 'm'. The error only happens with
  certain products, not in any specific instance except that mabe the
  category UoM but not every item in that category. If we created new
  products then we dont have the issue.

  I discovered many of the products were having problems base on an
  inventory we did with the stock_move table. Deleting entries fixed
  many of the issues but we still have this problem and it makes no
  sense to us.