c2c-oerpscenario team mailing list archive

["Rucha \(Open ERP\)" <716705@xxxxxxxxxxxxxxxxxx>]

Hello Kyle,
I have checked the line you provided, the fix is already there in latest trunk branch,
Check http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/product/product.py, it is the latest trunk revision.
merged revision: http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/revision/4493/product/product.py
So I set it fix released for trunk version,
Kindly update your code if you are using trunk,

** Changed in: openobject-addons
       Status: New => Fix Released

** Also affects: openobject-addons/6.0
   Importance: Undecided
       Status: New

** Changed in: openobject-addons/6.0
       Status: New => Confirmed

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

Title:
  Product UoM conversion error needs definition

Status in OpenERP Modules (addons):
  Fix Released
Status in OpenERP Addons 6.0 series:
  Confirmed

Bug description:
  It is known that it is not possible to convert UoM PCE to ft. When you
  incorrectly make a BOM it will show this error

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

  Makes sense. However this error is not indicative of what actually happened. When this error is returned it is general and not what units of measure are actually being converted. If I have a manufacturing order for a product defined properly as ft, but I configure it incorrectly as PCE it will show this exact error but it should look like this
  "Conversion from Product UoM ft to Default UoM PCE is not possible as they both belong to different Category!."
  Correctly stating the error and showing the user their mistake. How could I possible know what the problem is when it does not properly state the error.

  This case is especially true while running the manufacturing scheduler. This is not a normal scenario but consider I have 9,000 procurement exceptions and while the scheduler is processing them lets say it encounters just this exact problem. The scheduler gives no indication it is running at all but if it encounters this problem it will show this error in the server log.
  "Conversion from Product UoM m to Default UoM PCE is not possible as they both belong to different Category!."
  So consider not only does this not provide the correct UoM conversion error, it does not state which product is causing this issue which would force the person to manually sort through all 9,000 exceptions on an individual basis to find the problem. SO if this error happens it should say the error correctly,
  "Conversion from Product UoM ft to Default UoM PCE is not possible as they both belong to different Category!."
  PRODUCT ID :name of product MOVE ID: Relation to database.

  Putting the error this way provides a much more solid experience and
  diagnosis, telling the user exactly what they did wrong and where to
  fix the problem. Consider again, the error and its context is too
  broad to be useful in almost any way.