Related Bug: https://bugs.launchpad.net/openobject-addons/+bug/532728
Description:
Stephane (Open ERP) a écrit :
> I propose to remove the product.group_uos group on these fields.
>
That renders product.group_uos mostly useless. That is not a solution -
but if that's all you'll do in 5.0 then it's better that nothing.
Now, if only we were allowed to keep uos quantity empty, and have the
system use uom quantity by default, we would not need this client-side
workaround in the first place. That would be much cleaner, and I humbly
suggest it be done this way in the trunk.
To sum it up:
- don't change uos_quantity when uom_quantity is changed
- allow uos and uos_quantity to be empty
- use uom when uos is empty, and uom_quantity when uos_quantity is empty
Lionel
Hello,
I agree with those remarks about the on_change that prevent from double unit system to be used properly as explained in the OpenERP book ("ham" example).
In general, there are wider issues than just this on_change issue with the double unit:
- no double unit consideration in purchases (but you probably need it too).
- no double unit stock monitoring
As a workaround, for some customers we developed an alternative module for 5.0.x:
https:/
The specification is here: https:/
Actually we are not proud of what we did and that's why we don't communicate a ton about it, we think the right way is to fix OpenERP to be able to use a second unit, but we were afraid that wouldn't be possible to fix it properly in 5.0.x without introducing new regressions/API changes and we had more important issues with accounting so we didn't want Tiny to loose focus and that's why we kept quiet about it. Now, we agree, it would be cool to take advantage of the 5.2 release to finally make it work. There is something good eventually in our module, it's the second unit stock monitoring, it could be reused, eventually as a module or in the core if refactored.