c2c-oerpscenario team mailing list archive

[Graeme Gellatly <804353@xxxxxxxxxxxxxxxxxx>]

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)
<vra@xxxxxxxxxxx>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