c2c-oerpscenario team mailing list archive

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

Your saying ultimately it is a user fault, and it may be true that the
user is the cause of the corruption. That is not the point of the bug
report. You freely allow the user to corrupt the database with no
warning of any kind that doing so will corrupt the database. Why would
you allow this? I believe this has been overlooked.

In many business environments there could be any number of reasons why
someone would need to change the UOM and they are not technical experts
and have no clue whatsoever that they are destroying their ability to
compute stock and manufacturing orders by doing so. In my customers
environment they changed UOM many times because they have heavy
manufacturing and use many different UOM. Sometimes the product is just
configured incorrectly which is not caught until later. I had to debug
and discover why I could not compute manufacturing orders that were
properly configured. It took me much time that could have been saved
with simple checks and procedures.

I truly believe this is a serious flaw.
I do not understand your response.

Would you allow someone to delete products that have sold, or allow
canceling sales orders that are confirmed? No, because there are
constraint violations. I find it very frustrating to cancel even a sale
order because of the level of checking in the program, and to completely
ignore taking action on this particular problem does not make any sense
to me.

Even aside the problem with computing stock and manufacturing, it
entirely single handed breaks the ability to run the scheduler as I have
demonstrated in my bug report, and your saying that it is the users
fault, but also that you freely allow the user to perform the action
with no warning of any kind.

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

Title:
  Changing UOM can corrupt database

Status in OpenERP Modules (addons):
  Opinion

Bug description:
  I have a product. Its uom by default is PCE. I sell this product but
  didnt know about UOM. Later I configure them correctly as a Ft, or
  length measurement. I also create a BOM for the product. OpenERP
  cannot compute properly the value of the stock, nor compute a
  manufacturing order because in the history of the stock_move table
  there is entries of uncompatible conversion factors. This is due to
  the field of stock value being a function field. It calculates the
  value of stock based on all past purchases and sales, but it cant
  because there exists entries that are not compatible.

  OpenERP freely allows anyone to change the UoM in the program with
  ease, with no warning of any kind that doing so could potentially
  corrupt the database, break the scheduler entirely, and prevent that
  product from ever being able to use a BOM. This bug references the
  problem in detail.

  https://bugs.launchpad.net/openobject-addons/+bug/707287

  Propose,
  You should if a person changes the UoM from a compatible to incompatible factor alter all of the previous records UoM in the database to match so the conversion is compatible,

  rewrite the function field and manufacturing methods,

  not allow the person to change the measure due to integrity violations

  or place a warning when the attempt to change it telling them they
  could corrupt their database.

  This is a serious problem and should not be ignored

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