Tryton - Issues

 

Issue8079

Title Uom in opportunity line is updated when creating the sale
Priority bug Status resolved
Superseder Nosy List ced, mrichez, pokoli, reviewbot, roundup-bot
Type behavior Components sale_opportunity
Assigned To ced Keywords review
Reviews 263231002, 279221004
View: 263231002, 279221004

Created on 2019-02-06.10:42:34 by mrichez, last changed by roundup-bot.

Messages
New changeset f11daeafba44 by Cédric Krier in branch 'default':
Ensure to set the same quantity and unit on sale line
https://hg.tryton.org/tryton-env/rev/f11daeafba44
New changeset 3d1a78feae4f by Cédric Krier in branch 'default':
Ensure to set the same quantity and unit on sale line
https://hg.tryton.org/modules/sale_opportunity/rev/3d1a78feae4f
New review279221004 at https://codereview.tryton.org/279221004/#ps267231002
msg48843 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-04-11.16:29:30
Here is review279221004 which ensures to keep the same unit and so raise en error if it is not compatible.
msg48771 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-04-09.10:00:33
Indeed according to msg46765, the unit is changed instead of having an error message.
msg48770 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-04-09.09:25:31
Ok, so if the error message is enough let's close the issue as there is nothing to fix.
msg48769 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-04-08.22:44:02
Well the proposed fix is not good enough for me. So I prefer to leave the error message which can be fixed anyway.
msg48768 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-04-08.19:34:13
I'm fixing an issue here. 

I think what msg48759  explains should be part of issue8239. 

Feel free to implement it and deprecate this issue.
msg48760 (view) Author: [hidden] (mrichez) Date: 2019-04-08.13:56:40
Totally agree.
msg48759 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-04-08.13:54:33
I think we are loosing a feature by adding a strict domain. Also with issue8239, we should be able to support different uom categories.
So I think the opportunity should evolve to allow to specify a uom rate/factor on the line if needed. The sale line creation should take care of that and fill the secondary unit and maybe fill/create it on the product customer.
review263231002 updated at https://codereview.tryton.org/263231002/#ps285091002
msg48315 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-04-02.10:27:31
Here is review263231002 that adds the default_uom_category restriction on opportunity line unit
msg46777 (view) Author: [hidden] (mrichez) Date: 2019-02-06.13:33:31
>So you enter 1000kg as it is what you will sell on the sale. 
That's what we do actually :-)
But you have to convert and knowing the factor between units. And it seems weird for to customer when you send him an offer with a quantity and a uom totally different.

> Tryton is not able to convert between uoms of diferent categories.
Indeed but it would be a nice feature :-)
msg46775 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-02-06.13:25:32
> Indeed, setting a domain on the category unit of the product default_uom seems more logical.
> But sometimes, and i think i could be the case in opportunity where you could switch from uom category. I mean you could offer your product with quantity in 'unit' even if your product is stored in Kg or the inverse. The customer requesting something doesn't know your storage uom...so he asks with the uom he wish.. 'Give me price for 10000 units of ...' 'Sorry our storage uom is in Kg'

So you enter 1000kg as it is what you will sell on the sale. 


> This would imply to have a secondary uom and a convert factor between uom from different categories...

Tryton is not able to convert between uoms of diferent categories.
msg46773 (view) Author: [hidden] (mrichez) Date: 2019-02-06.13:16:18
Indeed, setting a domain on the category unit of the product default_uom seems more logical.
But sometimes, and i think i could be the case in opportunity where you could switch from uom category. I mean you could offer your product with quantity in 'unit' even if your product is stored in Kg or the inverse. The customer requesting something doesn't know your storage uom...so he asks with the uom he wish.. 'Give me price for 10000 units of ...' 'Sorry our storage uom is in Kg'
This would imply to have a secondary uom and a convert factor between uom from different categories...
msg46769 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-02-06.13:00:10
As product is required on opportunity line I think we should enforce to use only a uom from the product default_uom category. So if product is defined on kg, we can not select Meters nor units

When creating the sale the unit used is the one from on_change_product [1] so that's why it's ignored. I think we should enforce the unit defined on the opportunity line. 

[1] http://hg.tryton.org/modules/sale_opportunity/file/4420dc7c5db3/opportunity.py#l494111
msg46765 (view) Author: [hidden] (mrichez) Date: 2019-02-06.10:42:34
On the sale_opportunity lines, there's no domain on the unit field allowing you to select any unit for a product. 
But when you create a sale for this opportunity, the unit on the sale line will be the product sale unit so your sale could be different of your opportunity if the unit choosen in the opportunity is not the sale unit. 
I mean product A has 'unit' as sale unit but you make an opportunity with product A and 'Kg' as unit and quantity:10. When you create the sale, product 'A' will get 'unit' as uom instead of 'Kg' because 'unit' is the sale_unit. But 10 Kg or 10 unit is totally different...
History
Date User Action Args
2019-04-23 09:14:26roundup-botsetmessages: + msg49159
2019-04-23 09:14:18roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg49158
2019-04-11 18:02:46cedlinkissue8239 superseder
2019-04-11 16:51:59reviewbotsetmessages: + msg48845
2019-04-11 16:51:59reviewbotsetreviews: 263231002 -> 263231002, 279221004
2019-04-11 16:29:30cedsetstatus: in-progress -> testing
messages: + msg48843
2019-04-11 16:24:58cedsetstatus: chatting -> in-progress
assignedto: ced
2019-04-09 10:00:34cedsetstatus: closed -> chatting
assignedto: pokoli -> (no value)
messages: + msg48771
2019-04-09 09:25:31pokolisetstatus: testing -> closed
messages: + msg48770
2019-04-08 22:44:02cedsetmessages: + msg48769
2019-04-08 19:34:13pokolisetmessages: + msg48768
2019-04-08 13:56:40mrichezsetmessages: + msg48760
2019-04-08 13:54:34cedsetnosy: + ced
messages: + msg48759
2019-04-02 10:41:11reviewbotsetnosy: + reviewbot
messages: + msg48316
2019-04-02 10:27:31pokolisetstatus: chatting -> testing
reviews: 263231002
messages: + msg48315
keyword: + review
assignedto: pokoli
2019-02-06 13:33:32mrichezsetmessages: + msg46777
2019-02-06 13:25:32pokolisetmessages: + msg46775
2019-02-06 13:16:18mrichezsetmessages: + msg46773
2019-02-06 13:00:11pokolisetstatus: unread -> chatting
nosy: + pokoli
messages: + msg46769
2019-02-06 10:42:34mrichezcreate