Daily updates from Odoo
Sunday, July 5, 2026
2 changes · saas-19.1
Resolved issues and error corrections
A recent test within the account module was failing due to an outdated approach to clearing demo data. This update correctly reuses a proven test method and includes a necessary step to ensure data is properly processed, resolving the error and improving test reliability. This ensures accurate reporting and stability.
Original PR description
The test introduced by d60564a42b7c7b16d1d975146291835b65a19461 was using the field `deferred_move_ids` which is defined by account_accountant. As it is used to clear the pre-existing moves (typically demo data), we are re-using the same conditional as test_tour.py to check whether this field is available. By the way, we also add a missing flush_recordset that caused errors in test_kpi_summary_reports_unreconciled_bank_statements. Runbot-error: [939986](https://runbot.odoo.com/odoo/error/939986) Forward-Port-Of: odoo/odoo#271218
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 that the forecast accurately reflects the actual movement of materials, resolving inconsistencies between the forecast header and detail lines.
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