[18.0][FIX] ddmrp: fix _calc_incoming_dld_qty and _calc_qualified_demand#567
[18.0][FIX] ddmrp: fix _calc_incoming_dld_qty and _calc_qualified_demand#567gurneyalex wants to merge 1 commit intoOCA:18.0from
Conversation
In OCA#535 a fix was introduced to take info account moves which have the stock.buffer's location in their final destination. This introduced a bug when different chained moves are moving a product towards its buffer location, as all the moves will be counted, resulting in a wrong net flow position (among others). I propose to fix this with the following check: if a move with the final destination under the buffer's location has a matching final destination, and there are pending chained moves with the same final destination, these moves will be in our list: the current move needs to be disregarded. We may still have a problem if the there are some cancelled moves and the total quantity does not match the original expected quantity, but this should be rare, so I'm not considering this in the current PR.
|
Hi @LoisRForgeFlow, @JordiBForgeFlow, |
|
@gurneyalex It makes sense but I have a doubt: how do you get the final location that way in a route without push rules? For instance, in an interwarehouse in which the 2 transfers are pre-created the final location of the first step is not WH2/Stock, it is the transit one. 
Just wondering to understand the full context. Also, if possible, I would like a test covering the case. |
LoisRForgeFlow
changed the title
LoisRForgeFlow
left a comment
LoisRForgeFlow
left a comment
There was a problem hiding this comment.
waiting feedback to my comment #567 (comment)
|
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
4 participants
In #535 a fix was introduced to take info account moves which have the stock.buffer's location in their final destination. This introduced a bug when different chained moves are moving a product towards its buffer location, as all the moves will be counted, resulting in a wrong net flow position (among others).
I propose to fix this with the following check: if a move with the final destination under the buffer's location has a matching final destination, and there are pending chained moves with the same final destination, these moves will be in our list: the current move needs to be disregarded.
We may still have a problem if the there are some cancelled moves and the total quantity does not match the original expected quantity, but this should be rare, so I'm not considering this in the current PR.