Daily updates from Odoo
Sunday, July 5, 2026
1 change · saas-18.3
Resolved issues and error corrections
This update corrects a discrepancy in the manufacturing order forecast report. Previously, the forecast incorrectly showed incoming quantities for finished products destined for a different warehouse. The fix ensures the forecast accurately reflects the actual movement of materials across warehouses, resolving a reporting inconsistency.
Original PR description
Version: ---------- - 18.0+ Steps to reproduce: ---------------------- 1. Install `mrp`, create two warehouses A and B. 2. Create a storable product with Track Inventory True. 3. Create a…
Version: ---------- - 18.0+ Steps to reproduce: ---------------------- 1. Install `mrp`, create two warehouses A and B. 2. Create a storable product with Track Inventory True. 3. Create a Manufacturing Order for 10 qty with(Miscellaneous tab): - Components location = Warehouse A (raw materials) - Finished product Location = Warehouse B 4. Confirm the MO. 5. Open the Forecast report for the product. Issue: ------- - Warehouse B forecast shows the MO under the replenishment detail lines (correctly, via `location_dest_id`) but the header displays "0 Incoming", "0 Outgoing", "0 Forecasted". - Warehouse A forecast incorrectly shows "10 Incoming" in the header, even though no finished product is going there. Cause: ------- - When we create MO for finished Product move is created if there no `location_final_id` then it set mo.warehouse_id.lot_stock_id` as the `location_final_id`. https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/stock_move.py#L466-L467 which is introduce in this [commit](https://github.com/odoo-dev/odoo/commit/95ce0ed97a160e3465c313ed6b9bef938d61586b) - The problem is that `mo.warehouse_id` is a related field computed from `mo.location_src_id.warehouse_id` https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/mrp/models/mrp_production.py#L110 - this warehouse that supplies the **raw materials** (Warehouse A). When the user sets `location_dest_id` to Warehouse B's stock, `mo.warehouse_id` is still Warehouse A, so `location_final_id` is stamped with Warehouse A's stock location. - `product.incoming_qty` (used by the forecast header) evaluates non-done moves using `location_final_id` first (if set), falling back to `location_dest_id` only when `location_final_id` is False: https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/models/product.py#L331-L335 - Because `location_final_id` is set (to WH-A) and non-False, the second clause (which would pick up `location_dest_id` = WH-B) is never evaluated. The result: the move is counted as incoming in Warehouse A and ignored in Warehouse B. - The forecast detail *lines* use only `location_dest_id` to classify moves, so they correctly show the MO as incoming for Warehouse B — producing the inconsistency the user observes. https://github.com/odoo/odoo/blob/f958a323fd652af9251215b1b5a2fadc3bccba42/addons/stock/report/stock_forecasted.py#L42-L46 Fix: ---- - Replace `mo.warehouse_id.lot_stock_id.id` with `mo.location_dest_id.id`: - `location_final_id` is meant to track where the product ultimately ends up when the immediate destination is intermediate. The correct "final" location for a finished-product move is exactly what the user chose as `location_dest_id` on the MO — not the stock location of the warehouse that happens to supply the raw materials. - For the standard single-warehouse case, `mo.location_dest_id` equals `mo.warehouse_id.lot_stock_id`, so the behaviour is unchanged. For cross-warehouse MOs (destination = WH-B), `location_final_id` is now stamped with WH-B's stock, making `product.incoming_qty` and the forecast header consistent with the detail lines. ---- opw-6294479 Forward-Port-Of: odoo/odoo#270089