Odoo Changelog — 2026-07-04

Saturday, July 4, 2026

2 changes · saas-18.4

Improvements(2)

Enhancements to existing features

[PERF] account: optimize _compute_made_sequence_gap

Coresaas-18.4accountMedium

This update improves how accounting entries are checked for sequence gaps after changes. By looking up only the specific nearby entries needed, it reduces unnecessary database work and can make some accounting updates faster without changing user-facing behavior.

Original PR description

The function _compute_made_sequence_gap is designed to determine if an updated move created a sequence gap. This is currently done with several performance issues.

Firstly, the search domain simply uses a min/max sequence number of the updated moves. However, we only ever need the sequence number that comes before each changed move.

Example:
Let's say we updated 3 moves.
Move A: sequence_number = 27
Move B: sequence_number = 235
Move C: sequence_number = 100342

The search domain then becomes:
('sequence_number', '>=', min(moves.mapped('sequence_number')) - 1),
('sequence_number', '<=', max(moves.mapped('sequence_number')) - 1),

('sequence_number', '>=', 26),
('sequence_number', '<=', 100341),

The search domain can now return up to 100315 moves! Since we then loop over each updated move (Move A,B,C) and check if the previous sequence number exists, we are never using 100312 of the records from the search.

Instead, we can compute what sequence numbers we are looking for ahead of time, and specifically search for those.

We can also convert this to a search_read to retrieve only sequence_number.

|  | Two Moves 35,000 apart | 1000 sequential moves |
| --------- | ------ | ------ | 
| Queries Before |129 | 4,300|
| Queries After | 24|4,291|
| Time Before |0.90 seconds |2.92 seconds|
| Time After | 0.11 seconds|2.69 seconds|

opw-6330731

Forward-Port-Of: odoo/odoo#273124

#performance#accounting#sequence

[PERF] point_of_sale: batch split bank payments on session close

PR #273975

Coresaas-18.4point_of_saleMedium

Closing Point of Sale sessions with many customer-identified bank payments is now much faster. The system processes these payments and reconciliations in batches, reducing long waits and avoiding timeout errors during session close.

Original PR description

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order.
3. Close the session.

With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed".

Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too.

Benchmark
---------
These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database:
- before: the close did not finish after more than 10 minutes.
- after: the close takes around 75 seconds.

opw-6242303

Forward-Port-Of: odoo/odoo#269306

#performance#pos#payments#session closing

The function _compute_made_sequence_gap is designed to determine if an updated move created a sequence gap. This is currently done with several performance issues. Firstly, the search domain simply uses a min/max sequence number of the updated moves. However, we only ever need the sequence number that comes before each changed move. Example: Let's say we updated 3 moves. Move A: sequence_number = 27 Move B: sequence_number = 235 Move C: sequence_number = 100342 The search domain then becomes: ('sequence_number', '>=', min(moves.mapped('sequence_number')) - 1), ('sequence_number', '<=', max(moves.mapped('sequence_number')) - 1), ('sequence_number', '>=', 26), ('sequence_number', '<=', 100341), The search domain can now return up to 100315 moves! Since we then loop over each updated move (Move A,B,C) and check if the previous sequence number exists, we are never using 100312 of the records from the search. Instead, we can compute what sequence numbers we are looking for ahead of time, and specifically search for those. We can also convert this to a search_read to retrieve only sequence_number. | | Two Moves 35,000 apart | 1000 sequential moves | | --------- | ------ | ------ | | Queries Before |129 | 4,300| | Queries After | 24|4,291| | Time Before |0.90 seconds |2.92 seconds| | Time After | 0.11 seconds|2.69 seconds| opw-6330731 Forward-Port-Of: odoo/odoo#273124

Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order. 3. Close the session. With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed". Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too. Benchmark --------- These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database: - before: the close did not finish after more than 10 minutes. - after: the close takes around 75 seconds. opw-6242303 Forward-Port-Of: odoo/odoo#269306