[16.0][FIX] stock_available_to_promise_release: improve returnable qty calculation#1145
Conversation
nicolas-delbovier-acsone
changed the title
nicolas-delbovier-acsone
changed the title
lmignon
left a comment
lmignon
left a comment
There was a problem hiding this comment.
LGYM. Can you take a look at the failing tests? I would like to avoid to have this PR stuck by issues not related to your change.
| # be limited to the quantity not consumed | ||
| done_dest_moves = done_moves.move_dest_ids.filtered( | ||
| lambda m: m.state == "done" | ||
| lambda m: m.state == "done" or m.product_uom_qty == m.quantity_done |
There was a problem hiding this comment.
Can you ellaborate the issue you are facing?
| lambda m: m.state == "done" or m.product_uom_qty == m.quantity_done | |
| lambda m: m.state == "done" or m.picking_id.printed |
From what I remember, the purpose was to allow to pick for multiple packs (you pick for all SO and then distribute on multiple SO). When one SO gets canceled, then the over-picked quantity had to be returned back to the stock.
There was a problem hiding this comment.
Could you write a test for this? Because i don't quite understand the purpose of this change.
If you want to exclude not done but already picked/reserved dest moves, shouldn't be the change like J-E suggested and update the returnable_qty? By considering the quantity_done?
Because it could be that not the full product_qty is picked.
There was a problem hiding this comment.
The bug we had is because of some interaction with a custom module of ours. Because of the cancelling of some moves happening at the same time as the validation of the picking, I found myself needing this new condition because in some special case we tested, the state on the move was not updated "at the right time".
I'll try to reproduce this error in a unit test that does not depend from our custom module when I have the time.
sbidoul
force-pushed
the
16.0-fix-stock_available_to_promise_release-returnable-qty
branch
2 times, most recently
from
ad6bca3 to
3574e0b
Compare
…ulation Correct the identification of consumed moves by checking done quantities in addition to the move state. The previous logic only considered moves in the 'done' state. However, during certain validation flows, a move might have its `quantity_done` fully set while its `state` hasn't yet been updated. This caused the returnable quantity to be over-calculated, incorrectly preventing the cancellation of moves. By including moves where `product_uom_qty == m.quantity_done`, we accurately capture moves that are effectively finished, regardless of their transient state.
nicolas-delbovier-acsone
force-pushed
the
16.0-fix-stock_available_to_promise_release-returnable-qty
branch
from
3574e0b to
46790bc
Compare
4 participants
Correct the identification of consumed moves by checking done quantities in addition to the move state.
The previous logic only considered moves in the 'done' state. However, during certain validation flows, a move might have its
quantity_donefully set while itsstatehasn't yet been updated. This caused the returnable quantity to be over-calculated, incorrectly preventing the cancellation of moves.By including moves where
product_uom_qty == m.quantity_done, we accurately capture moves that are effectively finished, regardless of their transient state.