[16.0][IMP]stock_warehouse_flow#1144
Open
AdrianaSaiz wants to merge 3 commits into
Open
Conversation
AdrianaSaiz
force-pushed
the
16.0-imp-stock_warehouse_flow
branch
2 times, most recently
from
a54646f to
d7f6417
Compare
sergiobstoj
reviewed
Mar 16, 2026
| all_siblings = self.search( | ||
| [ | ||
| ("sale_line_id.order_id", "in", order_ids), | ||
| ("state", "!=", "cancel"), |
Member
There was a problem hiding this comment.
should state be present on api.depends?
Author
There was a problem hiding this comment.
Hello Sergio, the state we filter on (!= cancel) belongs to sibling moves fetched via search(), not to the record itself.
| for line in order.order_line: | ||
| moves |= self._create_move(line, self.wh1) | ||
|
|
||
| for move in moves: |
Member
There was a problem hiding this comment.
missing determinism. If moves is empty tests will silently pass, consider using mapped() + set().
self.assertEqual(len(moves), 2)
self.assertEqual(set(moves.mapped("wh_total_products")), {18.0})
AdrianaSaiz
force-pushed
the
16.0-imp-stock_warehouse_flow
branch
2 times, most recently
from
884f72b to
4495306
Compare
sergiobstoj
approved these changes
Mar 16, 2026
AdrianaSaiz
force-pushed
the
16.0-imp-stock_warehouse_flow
branch
3 times, most recently
from
3c124aa to
13e5d9f
Compare
…k.move Add a computed field that sums product_uom_qty of sibling moves from the same sale order and warehouse. This allows flow domains to evaluate per-warehouse quantities instead of global SO totals, which is critical when a single SO is split across multiple warehouses. Without this field, all warehouses see the same total_products from the SO, causing incorrect flow routing (e.g., a warehouse handling 10 units gets routed as B2B because the SO total is 25).
AdrianaSaiz
force-pushed
the
16.0-imp-stock_warehouse_flow
branch
from
13e5d9f to
194b8d1
Compare
…_products compute
[FIX] stock_warehouse_flow : exclude not outgoing moves from wh_total…
jbaudoux
requested changes
Mar 27, 2026
Contributor
jbaudoux
left a comment
jbaudoux
left a comment
There was a problem hiding this comment.
The new field doesn't bring value to the engine itself.
It should be in a separate module.
If you have one delivery per warehouse, why you need to go back to the SO to count the total quantity per warehouse. Why don't you just sum the quantity of all the moves in the delivery?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add a computed field wh_total_products on stock.move that sums product_uom_qty of sibling moves sharing the same sale order and warehouse, excluding cancelled moves.
This allows flow domains to evaluate per-warehouse quantities instead of the global sale.order.total_products, which is critical when a single SO is split across multiple warehouses.
Problem
When SO lines are routed to different warehouses, flow domains referencing sale_line_id.order_id.total_products still see the global SO total. For example, a warehouse handling 10 units gets routed as B2B because the SO total is 25.
Solution
New field wh_total_products (Float, compute, non-stored) on stock.move
Helper method _get_wh_sibling_moves() returns moves from the same SO + warehouse
Compute batches all involved orders in a single query grouped by (order_id, warehouse_id) to avoid N+1
Falls back to the move's own product_uom_qty when there is no sale_line_id
Flow domain usage
No new dependencies added
Compatible with single-warehouse scenarios (same value as total_products)
Field is computed on-the-fly during _action_confirm(), when moves already have warehouse_id and sale_line_id set by procurement
Tests
All moves in one warehouse (total = full SO sum)
Moves split across 2 warehouses (each one sees only its qty in the new field)
Move without sale_line_id (fallback to own qty)
Cancelled moves excluded from total
_get_wh_sibling_moves() returns correct subset
Integration: SO confirm generates moves with correct field value