Can not change the product's UOM , If once I have save the product

Normally you should be able to change UoM for a product if there is no
transaction (in any state) with this product in sale_line, invoice_line,
stock_move, purchase_line, mrp_production, procurement_order, etc ...It
is too much and too risky to insert such a verification. It is therefore
safer to block change UoM in another category.
As a workaround, you can change temporarily category for PCE from Unit
to Weight, then change UoM of product from PCE to KG, and then change
back category for PCE to Unit. For safety, you must be the only user
connected to the database.
Thanks

On 25.11.2011 09:19, Amit Parik (OpenERP) wrote:
> Public bug reported:
>
> I have to create a one product with default UOM of "KG" with uom
> category "Weight".
>
> Steps:
> Create one product and By mistake I have save the record then set a default UOM as a "PCS".
>
> Now I have to change the default UOM to "KG" but it fires a constraint
> .
>
> "New UoM 'PCE' must belongs to same UoM category 'Weight' as of old UoM
> 'kg'" But I have none of the record belongs to UOM category of "Unit".
>
> Thank you!
>
> ** Affects: openobject-addons
> Importance: Low
> Assignee: OpenERP R&D Addons Team 2 (openerp-dev-addons2)
> Status: Confirmed
>
> ** Changed in: openobject-addons
> Importance: Undecided => Low
>
> ** Changed in: openobject-addons
> Status: New => Confirmed
>
> ** Changed in: openobject-addons
> Assignee: (unassigned) => OpenERP R&D Addons Team 2 (openerp-dev-addons2)
>

Hello Amit,
Thanks for reporting,

As filsys said, its needed and it only fires constraint when you have category of old and new UoM are different,
But beware, you also cannot change the UoM category of an existing UoM too,
the reason why we added constraint is well described in https://bugs.launchpad.net/openobject-addons/+bug/707287/comments/25 of lp:707287,

I think the problem you described is not a blocking one,
You have to take care of everything while creating a product at one time and don't do anything by mistake , (and if you commit any mistake just delete that product!)

So, for the problem raised in lp:707287 we did this fix, so this is not a bug.

I hope it helps,

Hello Rucha,

Thanks for your nice explanation..:)

And I have agreed that, this constraint put because of lp:707287 's issue.

But I have explain more here, As per filesys said this constraint will be fire, If we have those product's move have created.

In simply, If product's account move or stock move created then we can not change it's "UOM category" that is right.

But If I have new product and it has no move created then we have to allow to change product's UOM either it have same category on not in both case.

Because end user can be made a mistake and we have give him a chance to correct it..;-).
Here we are good aware of system, So we can't do a mistake..;-) but if the user is new then might be done such type of stupid mistake.
So we will give him a chance to rectify it.

That's why my suggestion is that, If product have no move created then we have allow to change it's category.

So I am again set to "New" status , please look in to this and give your suggestion on this.
Correct me I am wrong..:)

Thanks for consider it..

Thanks Rucha,
I forgettheconstraint added for Uom category.
Deletionandre-creationof the product isa better way.

Thanks

On 25.11.2011 10:48, Rucha (Open ERP) wrote:
> Hello Amit,
> Thanks for reporting,
>
> As filsys said, its needed and it only fires constraint when you have category of old and new UoM are different,
> But beware, you also cannot change the UoM category of an existing UoM too,
> the reason why we added constraint is well described in https://bugs.launchpad.net/openobject-addons/+bug/707287/comments/25 of lp:707287,
>
> I think the problem you described is not a blocking one,
> You have to take care of everything while creating a product at one time and don't do anything by mistake , (and if you commit any mistake just delete that product!)
>
> So, for the problem raised in lp:707287 we did this fix, so this is not
> a bug.
>
> I hope it helps,
>
> ** Changed in: openobject-addons
> Status: Confirmed => Invalid
>

Amit,
you are right but you know this is not an easy job,
We need to check record of each and every object which refer to product and/or product UoM which in turn responsible to create stock move, and restrict changing UoM having different category if even a single record found for that object,
this is less accurate and if we miss anything it will be erroneous,

so, even this is to improve for end user's ease, I am not agree to do it for now,
If you think you want to stick on your suggestion, you can contribute to fix this problem and I will be willing to test and review such a nice improvement,

Thanks for the contribution.

Hello Rucha,

Thanks for look in to this and considering it.
Yes you are right, and I am agree with you:-) .it's quite difficult to check all the moves.

As per your comment, this is a good Improvement, So I am considering this as a "Wishlist" and currently we can not fix it.

I will work on it and provide a patch soon, Currently I am setting this to "Won't FIX". When I will done it then set it again to "Confirmed".

Thank you!

Hello,

I want to stick my this suggestion that's why again I am confirming this issue, and my promise that I will provide a branch(with correct fix) for this soon.

Note: I completely look up on lp:707287 and I am sure that here no need to check the account move for that warning because If product have only account move (not stock move) then it doesn't effect to procurement.

That's only need to check that, If product have stock move then and then our product's uom (different category) don't allow to change. And this will solve my reported issue (I am able to change my product' uom).

I will come with branch :-)

Thank you!

Hello,

Finally this issue has been solved after some fluctuation of status on this bug report ;-).

This issue has been committed on lp:~openerp-dev/openobject-addons/trunk-bug-894648-amp branch with following rev no and rev ID.

rev No : 6766
rev ID : <email address hidden>

Thank you!

Dear Amit,
Thanks for your work on this. As I commented on your merge proposal, and to my big regret, I don't think you can simply check stock moves because other objects may need to be checked.
For example, sale order lines must be checked too, because confirming a quotation will create stock moves with the UoM of the Sale Order.
And custom modules may do something along those lines too and you can never know.
So if you want to relax the check it has to be generic enough to detect those cases but I don't see how that can be done.
Lionel Sausin.

Hello Lionel,

lp:~openerp-dev/openobject-addons/6.1-opw-576033-rgo 's fixes looks fine.And I don't think we have to check the SO line cause If SO is confirmed then its Stock move must created, and we don't have to consider draft SO, it will never effects.

Thank you!

Dear Amit,
Sales may be OK from a technical point of view but consider this:
- sale a service to customer A
- change the service's UoM to another category
- sale the service again to customer A
- make a grouped invoice
You get the same product with 2 UoMs (screenshot attached). How does that make sense ?

That's just an example of how the change you propose change is difficult to make right. you will miss something, and it will bite you as maintenance cases. Or you'll make a huge effort to make it right, and it's just not worth it.

I any case it's certainly not something to after a beta was just released.

Hello Lionel,

As per my Opinion, Service type products UOM is always as a "Hour" or "Day" and both have same category.

And in real scenario we don't have used another UOM rather than "Hour" or "Day" for Service type product.

If you have any real time use case then please provide us.

Thank you!

Le 19/11/2012 10:56, Amit Parik (OpenERP) a écrit :
> And in real scenario we don't have used another UOM rather than "Hour"
> or "Day" for Service type product.
Nonsense. Here, shippings are services with a fixed price, UoM is
PCE.Most carriers will sale transport services by weight (UoM=Kg), by
volume (UoM=m3) or by weight/volume ratio (UoM does not even exist in
the default dataset).
That's not even talking about users making plain mistakes. And that's
just sales, but who knows what else is affected?
Look for the big picture, play it safe.
Lionel.

This is still an issue in trunk as of today.

I have just imported a bunch of products to do some testing.

I am unable to change the the UoM or the "hack" of changing the UoM Category first.

Instead I must delete these products. I tried duplicating a product (as it now has more information that I did not get from the import) but the system will not let change the UoM of a duplicated product either. When setting up a new database this makes things very difficult/time consuming.

Perhaps an "admin" setting to say we are in "setup mode" or something could be added to enable these kinds of changes to be made. And that setting should only be able to be changed once and in one direction: setup->production, never backwards?

Just an idea...