Skip to content

[16.0][FIX] stock_available_to_promise_release: improve returnable qty calculation #1145

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nicolas-delbovier-acsone wants to merge 1 commit into
base: 16.0
Choose a base branch
from
Open

[16.0][FIX] stock_available_to_promise_release: improve returnable qty calculation #1145

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion stock_available_to_promise_release/models/stock_move.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -828,7 +828,7 @@ def unrelease(self, safe_unrelease=False):
# in case of canceled origin_moves, the quantity to return must
# 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
Copy link
Copy Markdown
Contributor

@jbaudoux jbaudoux Mar 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you ellaborate the issue you are facing?

Suggested change
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.

Copy link
Copy Markdown

@mt-software-de mt-software-de Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

@nicolas-delbovier-acsone nicolas-delbovier-acsone Mar 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

)
returnable_qty = sum(done_moves.mapped("product_qty")) - sum(
done_dest_moves.mapped("product_qty")
Expand Down
Loading