Tryton - Issues



Title Set origin to null when clone a stock move
Priority bug Status resolved
Superseder Nosy List albertca, ced, pokoli, resteve, reviewbot, roundup-bot
Type feature request Components stock_consignment
Assigned To ced Keywords review
Reviews 64531002
View: 64531002

Created on 2018-08-29.12:18:20 by resteve, last changed by roundup-bot.

New changeset 2247486feb05 by Cédric Krier in branch '5.0':
Clear origin when copying move

New changeset fdf9bb48edc4 by Cédric Krier in branch '4.8':
Clear origin when copying move
New changeset 1cf2d46756c5 by Cédric Krier in branch 'default':
Clear origin when copying move
New changeset 6720c66ab49c by Cédric Krier in branch 'default':
Clear origin when copying move

New changeset 03536aeca1e7 by Cédric Krier in branch 'default':
Add test scenario to clear origin when copying move
msg45923 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-01-11.19:36:10
I do not think it should be back-ported because there is a work around which is to not duplicate such shipment (which should anywhere never be duplicated).
But I do not find using default is enough reliable to enforce the behavior because call could have already a default value for origin.
msg45922 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-01-11.18:58:48
Is this considered as a bug or as a feature? Do we plan to backport? 

I'm asking because if we do not plan to backport I'm wondering if it's possible to use the callable feature of copy default to avoid the extra call of save and clearing the values directly with the copy call.
review64531002 updated at
msg45641 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-12-31.00:52:10
Here is review64531002 that fix this behavior.
msg43152 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-08-29.15:20:16
We are not going to delay the creation of the invoice line. This has been already discussed.
msg43151 (view) Author: [hidden] (albertca) (Tryton committer) Date: 2018-08-29.15:00:04
The module stock_split allows splitting a stock.move also when it is in assigned state and stock_consignment creates the invoice line in the assigned state, so it is possible that the user splits the move when the invoice line has already been created and removing the origin in this case would probably be wrong.

One option would be to create the invoice line once the move is in "done" state (which I think is a better workflow for the user), though that requires to add a mechanism to prevent the warning that the move has no origin when it's assigned.
msg43148 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-08-29.12:58:29
For me, the origin should be reset only for move for which the origin is the invoice line from the stock_consignment.
msg43147 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-08-29.12:40:16
stock split also uses the copy method, but I think it makes sense to preserve the origin when spliting a move.
msg43146 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-08-29.12:39:33
Not sure if it should be part of the stock module. Another scenario
msg43143 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-08-29.12:21:52
Patch is welcome.
msg43142 (view) Author: [hidden] (resteve) Date: 2018-08-29.12:18:20
In stock.move model has not copy() method to reset origin field to null when duplicate a shipment


1- Install stock_consignment module and configure locations to create invoice lines.
2- Create a shipment internal and assign => create account invoice lines from stock moves.
3- Duplicate the shipment => stock.move has the origin of the previous stock.move (account.invoice.line) 
4- Assign duplicated shipment => not generate  new invoice lines because has an origin
Date User Action Args
2019-02-10 23:49:05roundup-botsetmessages: + msg46915
2019-01-24 21:40:26roundup-botsetmessages: + msg46241
2019-01-24 21:40:18roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg46240
2019-01-11 19:36:10cedsetmessages: + msg45923
2019-01-11 18:58:49pokolisetmessages: + msg45922
2018-12-31 01:13:34reviewbotsetnosy: + reviewbot
messages: + msg45642
2018-12-31 00:52:11cedsetstatus: in-progress -> testing
reviews: 64531002
messages: + msg45641
keyword: + review
2018-12-31 00:38:30cedsetstatus: chatting -> in-progress
assignedto: ced
2018-08-29 15:20:16cedsetmessages: + msg43152
2018-08-29 15:00:05albertcasetnosy: + albertca
messages: + msg43151

Showing 10 items. Show all history (warning: this could be VERY long)