Odoo Changelog — 2026-04-23

Thursday, April 23, 2026

4 changes

Branch: saas-19.3

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] account, account_edi_ubl_cii: attach imported XMLs

PR #260938

Coresaas-19.3accountaccount_edi_ubl_ciiHIGH

Imported XML files are now kept attached to the related record instead of being detached during import. This prevents access errors in certain invoice workflows, including Mexican electronic invoicing, when users open bills later.

Original PR description

When importing files (manually or from email alias),
we unattach the xml files, it can lead to access error in some flows
like with l10n_mx_edi

Steps to reproduce the flow that triggered the bug:

- Install l10n_mx_edi and select MX company
- Create an email alias for purchase journal
- Receive email with xml file
- Create a user with 'group_user' role, 'Administrator' accounting
  access rights
- Login with this user and open the created bill
-> Access Error

This is because we unattach xml attachmentss when importing them, by setting
`res_id` to 0 and `res_model` to False.
The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via
`_get_mail_thread_data_attachments` which lead to an access error during the
`fetch` method

opw-5953578

closes odoo/odoo#260545

X-original-commit: 7023bb316ca266a18abccc7e8c13069deafc562b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

#invoice import#email alias#attachments#access error#e-invoicing

[FIX] payment_adyen: fix capture issues caused by creating child tx

PR #260649

Coresaas-19.3payment_adyenHIGH

This update resolves a critical issue preventing successful capture or voiding of Adyen payments. The fix ensures the necessary payment provider reference is included in transactions, allowing the payment gateway to process requests correctly. This improves payment processing reliability for Adyen users.

Original PR description

Issue 1:
---
Capturing/voiding transaction is failing with the error:
`The payment provider rejected the request. Original pspReference required for this operation`

Steps to reproduce:
1- Setup Adyen payment provider.
2- Enable `Capture amount manually`.
3- Create a SO and confirm.
4- Generate a payment link and pay.
5- In SO, capture the full amount.

Cause:
---
After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created.
However the child tx is missing the `provider_reference` required to send the payment provider.


Issue 2:
---
The child tx created for capture/void is always remains in draft state.

Cause:
---
This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed.

opw-6120846
opw-6120071

Forward-Port-Of: odoo/odoo#259223

#adyen#payment#capture#void

Branch: saas-19.2

1 change

Bug Fixes(1)

Resolved issues and error corrections

[PERF] l10n_es_reports: optimize memory usage for VAT Books report

PR #113684

Enterprisesaas-19.2l10n_es_reportsHIGH

This update resolves a critical issue causing crashes and slow performance when generating the VAT Books Excel report for large invoices. By optimizing memory usage and query execution, the report now runs efficiently even with extensive data, significantly improving user experience and system stability.

Original PR description

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance…

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414

### Description of the issue/feature this PR addresses:
Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process.

### Current behavior before PR:
When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes.

### Desired behavior after PR is merged:
The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically:
- The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration.
- The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries.

### Benchmark:
The model is iterating through ~1.1M journal items when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 1.4GB| 202 MB |
| ~32,000 journal items | MemoryError | 278 MB |
| ~141,500 journal items | MemoryError | 760 MB |
| ~1.1M journal items | MemoryError | 1.4 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 2 min | 1.5s |
| ~32,000 journal items | MemoryError | 4s |
| ~141,500 journal items | MemoryError | 12s |
| ~1.1M journal items | MemoryError | 56s |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#112230

#performance#reporting#VAT#Excel

Branch: saas-19.1

1 change

Bug Fixes(1)

Resolved issues and error corrections

[PERF] l10n_es_reports: optimize memory usage for VAT Books report

PR #113671

Enterprisesaas-19.1l10n_es_reportsHIGH

Original PR description

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance…

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414

### Description of the issue/feature this PR addresses:
Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process.

### Current behavior before PR:
When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes.

### Desired behavior after PR is merged:
The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically:
- The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration.
- The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries.

### Benchmark:
The model is iterating through ~1.1M journal items when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 1.4GB| 202 MB |
| ~32,000 journal items | MemoryError | 278 MB |
| ~141,500 journal items | MemoryError | 760 MB |
| ~1.1M journal items | MemoryError | 1.4 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 2 min | 1.5s |
| ~32,000 journal items | MemoryError | 4s |
| ~141,500 journal items | MemoryError | 12s |
| ~1.1M journal items | MemoryError | 56s |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#112230

#reporting#vat#performance

When importing files (manually or from email alias), we unattach the xml files, it can lead to access error in some flows like with l10n_mx_edi Steps to reproduce the flow that triggered the bug: - Install l10n_mx_edi and select MX company - Create an email alias for purchase journal - Receive email with xml file - Create a user with 'group_user' role, 'Administrator' accounting access rights - Login with this user and open the created bill -> Access Error This is because we unattach xml attachmentss when importing them, by setting `res_id` to 0 and `res_model` to False. The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via `_get_mail_thread_data_attachments` which lead to an access error during the `fetch` method opw-5953578 closes odoo/odoo#260545 X-original-commit: 7023bb316ca266a18abccc7e8c13069deafc562b Signed-off-by: Laurent Smet (las) <las@odoo.com> Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen payment provider. 2- Enable `Capture amount manually`. 3- Create a SO and confirm. 4- Generate a payment link and pay. 5- In SO, capture the full amount. Cause: --- After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created. However the child tx is missing the `provider_reference` required to send the payment provider. Issue 2: --- The child tx created for capture/void is always remains in draft state. Cause: --- This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed. opw-6120846 opw-6120071 Forward-Port-Of: odoo/odoo#259223

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process. ### Current behavior before PR: When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes. ### Desired behavior after PR is merged: The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically: - The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration. - The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries. ### Benchmark: The model is iterating through ~1.1M journal items when generating the full report. For Memory: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 1.4GB| 202 MB | | ~32,000 journal items | MemoryError | 278 MB | | ~141,500 journal items | MemoryError | 760 MB | | ~1.1M journal items | MemoryError | 1.4 GB | For Speed: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 2 min | 1.5s | | ~32,000 journal items | MemoryError | 4s | | ~141,500 journal items | MemoryError | 12s | | ~1.1M journal items | MemoryError | 56s | ### Reference opw-6037414 ----------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#112230