credativ team mailing list archive

["Kyle Waid - http://www.gcotech.com" <910241@xxxxxxxxxxxxxxxxxx>]

Hi,

I have a rather large customer with many units of measure. A solution we
implemented was to alter the stock moves unit of measure. For example,

UPDATE stock_move SET product_uom = product_template.uom WHERE ...
statement.

And there are a few other tables as Fabien has mentioned, but it is
manageable.

Now granted this is a direct database manipulation, consider when we had
this problem there was no check for corruption. The problem becomes
noticeable when you have many BOM.  I know that many other OpenERP users
will have this same problem. The solution has worked well for us and I
recommend anyone else to use it once, and then never change a products
uom.

Also I would note that this customer has over 1 million stock moves. No
issues after modification.

This being said, raphaels statement/concern is valid as in customers
already have this corruption and they need a solution that works for
them. Fixing the problem abruptly fixes new installations, or
installations where corruption has not yet occurred, but it is sort of
an injustice for customers that already have this problem and will now
have a bigger issue.

Deactivating and creating a new product will work, but if the customer
has many products(tens of thousands), or products that link to an
external sale system, or other reasons it could become a major data
management issue. I believe the best solution is to alter the database
directly to make all moves and references conform to the standard
defined unit of measure.

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

Title:
  [6.1/trunk] important: product inconsistent UOM checking is too
  strict! cannot change uom!

Status in OpenERP Addons (modules):
  Fix Released

Bug description:
  Hello

  on trunk from today:

  Try to create some new product with default PCE unit. Save it.
  Now try to change it's sale or purchase unit to Kg for instance. You'll get an error because the old and new units are not convertible.

  In 6.0 we had the issue that this was never checked and people would
  screw their inventory and add orange and apples when changing a
  product unit.

  So checking is good the issue is that on 6.1 you are being too strict. Here I propose a patch to check if the product has been moved already or not. If the product has never been moved, it's fine to accept people fixing its UoM.
  What happened to us is that we imported the product catalog from the customer previous ERP. The issue is that soon the user spo that the unit was wrong before even using the system. In that case he should be able to change it without requiring some SQL or coding maintenance intervention.

  Please see if my attached patch help.

  Regards and happy 2012!

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