Odoo Changelog — 2026-04-28

Tuesday, April 28, 2026

8 changes · 17.0

Bug Fixes(8)

Resolved issues and error corrections

[FIX] l10n_mx_edi: allow out_refund to be PPD

Enterprise17.0l10n_mx_ediMedium

This update resolves a discrepancy between Odoo and the Mexican SAT portal's requirements for electronic invoicing. Previously, credit notes couldn't utilize the 'payment_policy_payment_due' (PPD) setting. Now, credit notes with an 'out_refund' move type can correctly utilize PPD, ensuring compliance with Mexican tax regulations.

Original PR description

Currently, credit notes cannot be PPD (payment_policy), however, SAT portal allows it.

**STEP TO REPRODUCE**
1. Install the l10n_mx_edi module.
2. Create an invoice with PPD (either changing it or through payment terms).
3. After send CFDI, generate a credit note and try to set PPD

**FIX**

Allow move_type = 'out_refund' to be PPD.

Task-6049654

#tax#mexico#edi#credit note

[PERF] web: respect limit during onchange fetch

PR #259983

Core17.0webMedium

This update fixes a performance issue where Odoo was fetching excessive product quantities during certain on-change events. The change ensures that the system respects the specified limit when retrieving quantities, resulting in significantly faster response times. This improves the user experience, especially when dealing with products with many associated quantities.

Original PR description

## Problem:
During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests.

## Solution:
Enforce the `limit` when fetching if it is present.

## Steps to reproduce:
- Have a product with many quant records
1. Open a picking for this product in Barcode
2. Change the lot/serial

The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve.

## Benchmark:
<table>
	<thead>
		<tr>
			<th># of quants</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>17193</td>
			<td>~9s</td>
			<td>~400ms</td>
		</tr>
	</tbody>
</table>

opw-6041705

#performance#frontend#stock

[FIX] l10n_se_reports: round sales report values when exporting to KVR

PR #114292

Enterprise17.0l10n_se_reportsMedium

This update resolves an issue where the Swedish EC Sales Report exported to KVR (a key reporting format) displayed decimal values instead of the required integer format for Swedish tax reporting. The fix ensures that all sales report values are rounded to integers, aligning with Swedish reporting regulations and improving data accuracy.

Original PR description

**PROBLEM**
EC Sales Report in Sweden needs to be reported with integer values.

**STEP TO REPRODUCE**
1. Install l10n_se
2. On the se company, create a invoice with lines with EU tax and confirm it.
3. Go to Accounting/Reporting/EC Sale List and export to KVR.
4. Notices the KVR uses numbers with decimals places.

opw-6045289

#reporting#Sweden#tax#KVR

[FIX] l10n_de_reports: avoid recomputing amount_currency in Datev exports

PR #114477

Enterprise17.0l10n_de_reportsMedium

This update fixes an issue where Datev exports were displaying incorrect currency amounts due to recomputing exchange rates. The change ensures that the original exchange rate used when creating the journal entry is consistently applied during export, aligning with the Odoo interface and improving data accuracy for financial reporting.

Original PR description

Currently, during the general ledger export to Datev format, the total price in currency and currency_rate information are recomputed using the current exchange rate at the line's date.

When rates have been added or modified after the creation of entries for the same date, the account_move_lines are not recomputed to match the new rate.

It results in exporting different values than what is indicated in the report from the Odoo interface.

We propose to use the same exchange rate as the one originally used to convert the journal item to ensure consistency with the database.

This is a backport of https://github.com/odoo/enterprise/pull/101910

opw-6096686

#reporting#currency#Datev#financials

[FIX] l10n_be_codabox: Prevent singleton error during CODA fetching flow.

PR #114787

Enterprise17.0account_bank_statement_importMedium

This update resolves a bug that prevented bank statement imports (like those from CodaBox) from completing successfully when multiple journals shared the same bank account number. The fix ensures accurate journal identification and prevents import failures, improving the reliability of financial data synchronization.

Original PR description

Behavior before: When running the CodaBox transaction fetch (via cron or manual trigger), the process would crash with an "Expected singleton: account.journal(id1, id2)" error if multiple journals…

Behavior before:
When running the CodaBox transaction fetch (via cron or manual trigger), the process would crash with an "Expected singleton: account.journal(id1, id2)" error if multiple journals were found sharing the same sanitized bank account number. This made the automated import flow unusable for users with duplicate numbered bank accounts.

Behavior after:
The CodaBox import flow completes successfully even if multiple journals share the same account number. The system now correctly identifies and binds to a single journal record, preventing the crash and allowing the statement creation to proceed.

Root Cause:
In _find_additional_data(), the search for a journal based on the sanitized_account_number lacked a record limit. If a database contained multiple journals for the same IBAN, the search returned a recordset containing multiple IDs. When the flow subsequently attempted to call instance methods or access fields on this recordset, the ORM triggered a ValueError because it expected a singleton.

Fix:
Added limit=1 to the search in _find_additional_data(). This ensures that even if the criteria match multiple journals, only a single record is returned and used for the statement import, maintaining consistency with Odoo's singleton requirements for journal-based operations.

opw-5462037

#bank statements#CodaBox#accounting

[PERF] account_reports: Reduce memory usage when exporting GL to PDF.

PR #114076

Enterprise17.0accountMedium

This update resolves a previous issue where exporting large General Ledger reports to PDF caused crashes due to excessive memory usage. The fix now processes data in smaller chunks, ensuring stable PDF exports even with extensive financial data. This improves the reliability of a key business reporting function.

Original PR description

Behavior before:
Exporting reports relying on _get_aml_values() (e.g., General Ledger) to PDF on large datasets caused high memory consumption and could lead to out-of-memory (OOM) errors. The export process would sometimes fail due to excessive RAM usage.

Behavior after:
PDF exports complete successfully even with large volumes of account move lines. Memory usage remains stable during the export process, preventing crashes.

Root Cause:
The method _get_aml_values() used dictfetchall(), which loads the entire query result set into memory at once. During PDF export, where all lines are typically fetched without pagination, this resulted in a massive memory footprint and eventual OOM.

Fix:
Replaced dictfetchall() with dictfetchmany(1000) to process results in chunks. This ensures that only a limited number of rows are loaded into memory at a time, significantly reducing memory usage during PDF generation while preserving the existing logic and behavior.

opw-6065292

#reporting#performance#account

[FIX] auth_signup: validate email on signup

PR #258967

Core17.0auth_signupMedium

This update fixes a security vulnerability by ensuring that users entering their email addresses during signup are validated. Previously, any string could be used, now the system enforces email format validation, enhancing data integrity and security. The update also adds autocomplete attributes to the signup form for a better user experience.

Original PR description

**Problem**
Before this commit, the email address typed in the signup form was not validated. Consequently, the user could use whatever string as email address.

**How to reproduce**
1. Activate "free sign up" ("Settings"->"Website"->"Customer Account")
2. While being signed off, navigate to "/web/signup"
3. No validation is enforced on the email field

**Fix**
The email field is correclty marked as "required", but its type was set as "text" instead of "email". This commit fixes the problem by changing the type to "email".

task-6094631

#security#signup#validation

[FIX] account_peppol_selfbilling: Put right id for Credit Note

PR #260941

Core17.0account_peppol_selfbillingMedium

This update resolves an issue where self-billing invoices weren't correctly identified as credit notes when generating UBL documents for Peppol. By ensuring the correct document type is used, the system now accurately processes self-billing transactions. A demo setup has also been added for testing.

Original PR description

To reproduce:
- Activate Peppol
- Activate selfbilling on your purchase journal
- Create a Vendor Refund
- Generate the UBL

=> The InvoiceTypeCode is 389, meaning it's considered a selfbilling invoice, not a selfbilling credit note. 
The issue is that we never put the document type of credit_note for selfbilling documents as it wasn't expected.
invoice was, due to a else encompassing invoices and bills. 
Also add a handle demo to be able to create selfbilling documents in demo mode.

opw-6132226



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

#account#peppol#selfbilling#credit note

Currently, credit notes cannot be PPD (payment_policy), however, SAT portal allows it. **STEP TO REPRODUCE** 1. Install the l10n_mx_edi module. 2. Create an invoice with PPD (either changing it or through payment terms). 3. After send CFDI, generate a credit note and try to set PPD **FIX** Allow move_type = 'out_refund' to be PPD. Task-6049654

## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705

**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289

Currently, during the general ledger export to Datev format, the total price in currency and currency_rate information are recomputed using the current exchange rate at the line's date. When rates have been added or modified after the creation of entries for the same date, the account_move_lines are not recomputed to match the new rate. It results in exporting different values than what is indicated in the report from the Odoo interface. We propose to use the same exchange rate as the one originally used to convert the journal item to ensure consistency with the database. This is a backport of https://github.com/odoo/enterprise/pull/101910 opw-6096686

Behavior before: When running the CodaBox transaction fetch (via cron or manual trigger), the process would crash with an "Expected singleton: account.journal(id1, id2)" error if multiple journals were found sharing the same sanitized bank account number. This made the automated import flow unusable for users with duplicate numbered bank accounts. Behavior after: The CodaBox import flow completes successfully even if multiple journals share the same account number. The system now correctly identifies and binds to a single journal record, preventing the crash and allowing the statement creation to proceed. Root Cause: In _find_additional_data(), the search for a journal based on the sanitized_account_number lacked a record limit. If a database contained multiple journals for the same IBAN, the search returned a recordset containing multiple IDs. When the flow subsequently attempted to call instance methods or access fields on this recordset, the ORM triggered a ValueError because it expected a singleton. Fix: Added limit=1 to the search in _find_additional_data(). This ensures that even if the criteria match multiple journals, only a single record is returned and used for the statement import, maintaining consistency with Odoo's singleton requirements for journal-based operations. opw-5462037

Behavior before: Exporting reports relying on _get_aml_values() (e.g., General Ledger) to PDF on large datasets caused high memory consumption and could lead to out-of-memory (OOM) errors. The export process would sometimes fail due to excessive RAM usage. Behavior after: PDF exports complete successfully even with large volumes of account move lines. Memory usage remains stable during the export process, preventing crashes. Root Cause: The method _get_aml_values() used dictfetchall(), which loads the entire query result set into memory at once. During PDF export, where all lines are typically fetched without pagination, this resulted in a massive memory footprint and eventual OOM. Fix: Replaced dictfetchall() with dictfetchmany(1000) to process results in chunks. This ensures that only a limited number of rows are loaded into memory at a time, significantly reducing memory usage during PDF generation while preserving the existing logic and behavior. opw-6065292

**Problem** Before this commit, the email address typed in the signup form was not validated. Consequently, the user could use whatever string as email address. **How to reproduce** 1. Activate "free sign up" ("Settings"->"Website"->"Customer Account") 2. While being signed off, navigate to "/web/signup" 3. No validation is enforced on the email field **Fix** The email field is correclty marked as "required", but its type was set as "text" instead of "email". This commit fixes the problem by changing the type to "email". task-6094631

To reproduce: - Activate Peppol - Activate selfbilling on your purchase journal - Create a Vendor Refund - Generate the UBL => The InvoiceTypeCode is 389, meaning it's considered a selfbilling invoice, not a selfbilling credit note. The issue is that we never put the document type of credit_note for selfbilling documents as it wasn't expected. invoice was, due to a else encompassing invoices and bills. Also add a handle demo to be able to create selfbilling documents in demo mode. opw-6132226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr