Hi, Not really, if the system allows it, then it is unfair to blame the user in this case IMO. Ultimately it is the fault of the way OpenERP calculates stock balances. Interestingly, I wonder what happens if we change the currency of an account that already has account.moves? It is the same concept. Anyway back to UoM.
Case 1. The UOM is accidentally sent to PCE (which by the way the system defaults to), a single order is created and while the system will allow change it causes problems. Recommendation: UOM should not have a default by default. In this case the user made no initial error but to overlook a field in product creation. If it isn't defaulted then he cannot make this error. This is the major source of the issue, and by merely getting rid of the default value from the module you are fixing most instances of this error. While we are at it, supplier UOM should not default to PCE either on the suppliers tab, ESPECIALLY when the UOM for the product is in a different category. If there is to be a default then it should be the product purchase UOM. This cause so many procurement exceptions. Case 2. The UOM of a product changes. We used to buy by the kg and now we buy by the PCE. This is not the users fault, it probably isn't even the company's fault. But it is pretty rare luckily and can be handled as follows. Recommendation: If you aren't going to fix it, then at least raise an exception, in write call of product.template something like - "You cannot currently change the UoM for a product where stock moves exist as this affects internal accounting. It is recommended you duplicate this product, and set this one to inactive" - Not perfect, but it works. Implement both of these and until you improve the other parts, or choose to support it, the problem at least has a good workaround and a minimal chance of occuring. On Mon, Jul 4, 2011 at 7:17 PM, Vinay Rana (openerp) <[email protected]>wrote: > Hello Kyle, > > As for I think It's ultimately a user fault to changing the UOM which > already have a stock move in another UOM. > For more clarification and discussion I am setting this as opinion. > @experts: Would you please share your view. > > Thanks. > > ** Changed in: openobject-addons > Status: New => Opinion > > -- > You received this bug notification because you are subscribed to OpenERP > Addons. > 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 > -- 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 _______________________________________________ Mailing list: https://launchpad.net/~c2c-oerpscenario Post to : [email protected] Unsubscribe : https://launchpad.net/~c2c-oerpscenario More help : https://help.launchpad.net/ListHelp
