credativ team mailing list archive

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

Hi,

I originally brought up the corruption problem much earlier, which has
led to this checking on uom. I believe that it should not allow changing
of uom at all if there is a past stock move, even in your circumstance.

The reason, is that, if it allows changing of the uom at all, aside from
corrupting the database in this conversion manner, you are also
corrupting the ability to calculate stock correctly. Each time it
calculates the stock it goes through all of the moves. If you have an
incompatible move then it cannot possibly calculate the stock correctly
and you are doomed.

additionally, you will never be able to use this product in any bom
because of this. Eventually, the customer will have a major problem and
it should be addressed immediately.

I would suggest, that there be either an automated tool that users can
run which will change all past stock moves to conform to the default
uom, as a reconciliation for a long overdue fix

that after a move is done and cannot be reversed, that uom not be
allowed to be changed to an incompatible uom family.

Sure it is a huge pain that this has become a neglected issue for such a
long time, but it is critical to have a database that is not corrupted

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

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