Thursday, July 2, 2026
2 changes · saas-18.3
Enhancements to existing features
This change removes technical e-reporting fields from standard invoice views, making invoices easier to read for regular users. The key e-reporting details and blocking issues are now shown in the chatter with a link to the related flow, and unnecessary address validation warnings are no longer shown on B2C invoices.
Original PR description
E-reporting technical fields were displayed directly on invoices, adding noise for regular invoicing users. Hide the e-reporting status columns and technical block from the standard invoice views. Log the relevant e-reporting flow, status and blocking errors in the invoice chatter instead, with a link to the related flow. Also avoid reporting address validation errors on B2C invoices, as they are not required for Flux 10 e-reporting. Task-6273226 Forward-Port-Of: odoo/odoo#271865
Backorder creation when validating very large receipts is now much faster and more reliable. The change reduces unnecessary processing and avoids database memory issues, helping large warehouse operations finish without timeouts.
Original PR description
## The Problem Validating receipts with a large number of operations by creating a backorder was timing out due to $O(N*M)$ filtering inside `_get_qty_received_without_self`, where N is the number of…
## The Problem Validating receipts with a large number of operations by creating a backorder was timing out due to $O(N*M)$ filtering inside `_get_qty_received_without_self`, where N is the number of moves in the picking, and M is the number of moves being processed for valuation. This happened while computing price units for moves one by one: each move filtered all picking moves to find the ones with the same `product_id`. Another issue was a PostgreSQL `"memory exhausted"` error caused by generating a large number of OR'ed conditions, equal to the number of processed moves. ## The Solution The massive filtering was fixed by filtering moves of the `purchase_line` instead of the `picking`, which is typically associated with only a few moves. This is still correct as the loop just after already ignores moves that don't have the same `purchase_line_id` of `self` anyways. The PostgreSQL error was fixed by grouping moves by `location_dest_id` and generating one condition per location using an `in` clause, which is typically much smaller than generating one condition per move. ## Benchmark Benchmark on a customer database, validating a receipt with 10k+ operations by creating a backorder: ```text Time: timeout -> 6 min ``` OPW-6272667 Forward-Port-Of: odoo/odoo#272603 Forward-Port-Of: odoo/odoo#269350