← Back to team overview

credativ team mailing list archive

Re: [Bug 910241] Re: [6.1/trunk] important: product inconsistent UOM checking is too strict! cannot change uom!

 

Fabien, I feel like needing to deactivate the product and create a new one
without using copy is a bit overkill. I really think lot's of people will
quickly create their product without paying to much attention to the unit
and feel frustrated to have to re do it all when they will think "cool I
created  all the products with their accounting properties, now I will
check their unit..."

I agree my patch doesn't work if no stock module. But then may be the
solution is to extract some modular check_unit_change method and override
it properly in the right modules, no?

Also if doing this is the write generic method would be bad in term of
perfperformance (is it if we check the presence of the field first?) Then a
dedicated wizard could be made.

What do you think?
On Dec 31, 2011 6:41 AM, "Kyle Waid - http://www.gcotech.com"; <
910241@xxxxxxxxxxxxxxxxxx> wrote:

> Raphael, im sorry I didnt read enough.
>
> You are right you should be able to change the uom if the product has no
> finalized moves. Makes perfect sense.
>
> --
> You received this bug notification because you are a member of OpenERP
> Committers, 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
>

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


References