credativ team mailing list archive

[Graeme Gellatly <910241@xxxxxxxxxxxxxxxxxx>]

Another way to avoid this problem happening most of the time is to remove
the UOM defaults.  That way the user is forced to enter a value which will
more than likely be the right one.

On Tue, Jan 31, 2012 at 5:12 AM, Raphaël Valyi - http://www.akretion.com <
910241@xxxxxxxxxxxxxxxxxx> wrote:

> exactly, employees of a wholesaler company with different UOM, is calling
> us like 4x per week because of that: they saved a product without
> specifying the right UOM and kaboom, we need to tweak the database. In the
> case they already set up a BOM, or a purchase order with a reception,
> telling them they should de-activate the product and re-do all is not a
> very welcome solution...
> Nothing like urgent, but certainly worth fixing. Technically speaking it
> should be some modular checking where additional modules like stock or
> purchase do additional checking.
>
> --
> You received this bug notification because you are 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
>

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