Odoo Changelog — 2026-07-04

Saturday, July 4, 2026

4 changes · saas-18.3

Improvements(1)

Enhancements to existing features

[IMP] l10n_uk_reports: tax return filing to HMRC from the tax unit

Enterprisesaas-18.3l10n_uk_reportsMEDIUM

UK VAT returns now warn users when their company belongs to a tax unit and guide them to file from that tax unit. When a return covers a tax unit, the tax unit's VAT number is used for HMRC connection and submission, reducing filing errors.

Original PR description

BEFORE:
- Before this commit, when the current company is a member of the tax unit, there is no blocking level error for the user to select the tax unit.
- And the vat used while creating a connection to the HMRC or while sending a tax report to the HMRC is of the current company.

AFTER:
- After this commit, there is one blocking level error, which tells the user that the current company is part of a tax unit, and on confirmation, the tax unit will automatically be selected for the current report.
- And if the return contains the data of a tax unit, then the vat set on the tax unit will be considered while establishing the connection and sending the tax report to HMRC.

Task-5865605

Forward-Port-Of: odoo/enterprise#107253

#uk#vat#hmrc#tax-unit

Bug Fixes(3)

Resolved issues and error corrections

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

PR #273917

Coresaas-18.3point_of_saleMEDIUM

This update significantly improves the speed of closing Point of Sale sessions, particularly when multiple bank payments are involved. Previously, closing a session with many payments could take over 10 minutes, but now it completes in approximately 75 seconds. This enhancement reduces operational delays and improves the overall efficiency of the POS system.

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

[PERF] account: optimize _compute_made_sequence_gap

PR #274182

Coresaas-18.3accountMEDIUM

This update optimizes how Odoo identifies gaps in move sequence numbers, leading to significantly faster processing. The previous method was inefficient, consuming excessive resources when checking for sequence gaps. This change improves overall system performance and responsiveness.

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#optimization#account

[FIX] l10n_cz: update TSD while reversing an invoice

PR #274060

Coresaas-18.3l10n_czMEDIUM

This update resolves an issue where reversing invoices with credit notes in the Czech localization (l10n_cz) didn't correctly update the Taxable Supply Date (TSD). The fix ensures the TSD is accurately reflected during the reversal process, aligning with accounting requirements. This improvement impacts invoice accuracy and reporting for Czech-based businesses.

Original PR description

### Issue before this commit: When reversing an invoice with a credit note in the l10n_cz and l10n_sk only the invoice_date is updated with the reversal_date but not the TSD date. ### Steps to…

### Issue before this commit:
When reversing an invoice with a credit note in the l10n_cz and l10n_sk only the invoice_date is updated with the reversal_date but not the TSD date.

### Steps to reproduce the issue:
1. Download Accounting and l10n_cz (same steps can be done for l10n_sk)
2. Go to invoices and put as not invisible the Accounting Date field
3. Create and post the invoice setting as Taxable Supply Date (TSD) a previous date
4. Create a credit note for the invoice with reversal date as today for example and then click Reverse
5. See the dates (as taxable supply date and accounting date) are not updated

### Cause of the issue:
Prior to version 19, the taxable_supply_date (TSD) was a localization-specific field and did not exist in the core account.move model. Consequently, when the reverse_moves method:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/account/wizard/account_move_reversal.py#L110-L174
executed, the accounting date was recomputed but the TSD was left unhandled. Thanks to PR https://github.com/odoo/odoo/pull/225035, which natively integrates this field into the core account module in version 19, the fields are now properly aligned and the issue is no longer reproducible.

### Reason to introduce the fix:
The fix explicitly populates taxable_supply_date with the wizard's reverse_date during the reversal preparation process.

opw-6102869

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265016

#accounting#czech#tsd#reversal

BEFORE: - Before this commit, when the current company is a member of the tax unit, there is no blocking level error for the user to select the tax unit. - And the vat used while creating a connection to the HMRC or while sending a tax report to the HMRC is of the current company. AFTER: - After this commit, there is one blocking level error, which tells the user that the current company is part of a tax unit, and on confirmation, the tax unit will automatically be selected for the current report. - And if the return contains the data of a tax unit, then the vat set on the tax unit will be considered while establishing the connection and sending the tax report to HMRC. Task-5865605 Forward-Port-Of: odoo/enterprise#107253

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

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

### Issue before this commit: When reversing an invoice with a credit note in the l10n_cz and l10n_sk only the invoice_date is updated with the reversal_date but not the TSD date. ### Steps to reproduce the issue: 1. Download Accounting and l10n_cz (same steps can be done for l10n_sk) 2. Go to invoices and put as not invisible the Accounting Date field 3. Create and post the invoice setting as Taxable Supply Date (TSD) a previous date 4. Create a credit note for the invoice with reversal date as today for example and then click Reverse 5. See the dates (as taxable supply date and accounting date) are not updated ### Cause of the issue: Prior to version 19, the taxable_supply_date (TSD) was a localization-specific field and did not exist in the core account.move model. Consequently, when the reverse_moves method: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/account/wizard/account_move_reversal.py#L110-L174 executed, the accounting date was recomputed but the TSD was left unhandled. Thanks to PR https://github.com/odoo/odoo/pull/225035, which natively integrates this field into the core account module in version 19, the fields are now properly aligned and the issue is no longer reproducible. ### Reason to introduce the fix: The fix explicitly populates taxable_supply_date with the wizard's reverse_date during the reversal preparation process. opw-6102869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265016