Odoo Changelog — 2026-09-14

Monday, September 14, 2026

2 changes · 19.0

Improvements(2)

Enhancements to existing features

[PERF] stock_account: Get manual value qty at date faster

Core19.0stock_accountMedium

Inventory validation is optimized for products with manual valuation entries on different dates. This reduces repeated stock movement lookups, helping large databases validate inventory operations faster with fewer system queries.

Original PR description

**Problem:** When products have manual values on different dates, it is necessary to run `_compute_quantities_dict` for each date, increasing the number of queries to `stock.move`. **Solution:**…

**Problem:**
When products have manual values on different dates, it is necessary to run `_compute_quantities_dict` for each date, increasing the number of queries to `stock.move`.

**Solution:**
Instead of retrieving the `qty_available` for each date, the done moves can be batch read up to the oldest manual value date then deducted from today's `qty_available` for each product.

**Performance:**
Performance was profiled on `button_validate` of a `stock.picking` where 10 AVCO & perpetual valued products each with manual values on different dates.

Before, `_compute_quantities_dict` runs 10 times and searches done `stock.move` 2 times each. After, done `stock.move` are only searched twice and fetched once regardless of the number of relevant manual value dates.

Below, the case is the number of `stock.move` in the database, increasing the time it takes to search `stock.move` and therefore the time to validate.

| Case | Before (Time) | Before (Queries) | After (Time) | After (Queries) |
|---|---:|---:|---:|---:|
| 10000 | 390 ms | 563 | 403 ms | 303 |
| 100000 | 565 ms | 559 | 450 ms | 376 |
| 1000000 | 720 ms | 654 | 495 ms | 418 |



opw-6058455

#performance#inventory#valuation

[PERF] pos_preparation_display: avoid slow stageless-order query

PR #130925

Enterprise19.0pos_preparation_displayMedium

The preparation display now finds relevant POS orders much more efficiently, especially in databases with a large sales history. This reduces long waits from seconds to milliseconds in tested scenarios, improving responsiveness for kitchen or preparation workflows.

Original PR description

The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`. On…

The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`.

On databases with many POS orders, PostgreSQL materializes that complete subquery and rescans it for every preparation-display order. Replace it with a correlated `EXISTS`, allowing the linked POS order to be checked
through its primary key instead.

#### Speedup

Database with 2,114 preparation-display orders. Each value is the average of five calls after invalidating the Odoo ORM cache.


POS orders | Before | After (10 runs)
-- | -- | --
5,481 | 148 ms | 6.767 ms (5.334–17.292 ms)
184,904 | 292 ms | 3.680 ms (3.395–4.275 ms)
320,493 | 23.228 s | 4.437 ms (4.187–4.964 ms)
565,685 | 39.950 s | 4.342 ms (3.356–5.258 ms)

After the rewrite, execution time is effectively independent of the eligible
POS-order cardinality in this dataset.



opw-6438446

Forward-Port-Of: odoo/enterprise#130529
Forward-Port-Of: odoo/enterprise#128806

**Problem:** When products have manual values on different dates, it is necessary to run `_compute_quantities_dict` for each date, increasing the number of queries to `stock.move`. **Solution:** Instead of retrieving the `qty_available` for each date, the done moves can be batch read up to the oldest manual value date then deducted from today's `qty_available` for each product. **Performance:** Performance was profiled on `button_validate` of a `stock.picking` where 10 AVCO & perpetual valued products each with manual values on different dates. Before, `_compute_quantities_dict` runs 10 times and searches done `stock.move` 2 times each. After, done `stock.move` are only searched twice and fetched once regardless of the number of relevant manual value dates. Below, the case is the number of `stock.move` in the database, increasing the time it takes to search `stock.move` and therefore the time to validate. | Case | Before (Time) | Before (Queries) | After (Time) | After (Queries) | |---|---:|---:|---:|---:| | 10000 | 390 ms | 563 | 403 ms | 303 | | 100000 | 565 ms | 559 | 450 ms | 376 | | 1000000 | 720 ms | 654 | 495 ms | 418 | opw-6058455

The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`. On databases with many POS orders, PostgreSQL materializes that complete subquery and rescans it for every preparation-display order. Replace it with a correlated `EXISTS`, allowing the linked POS order to be checked through its primary key instead. #### Speedup Database with 2,114 preparation-display orders. Each value is the average of five calls after invalidating the Odoo ORM cache. POS orders | Before | After (10 runs) -- | -- | -- 5,481 | 148 ms | 6.767 ms (5.334–17.292 ms) 184,904 | 292 ms | 3.680 ms (3.395–4.275 ms) 320,493 | 23.228 s | 4.437 ms (4.187–4.964 ms) 565,685 | 39.950 s | 4.342 ms (3.356–5.258 ms) After the rewrite, execution time is effectively independent of the eligible POS-order cardinality in this dataset. opw-6438446 Forward-Port-Of: odoo/enterprise#130529 Forward-Port-Of: odoo/enterprise#128806