Odoo Changelog — 2026-07-13

Monday, July 13, 2026

7 changes · 17.0

Improvements(1)

Enhancements to existing features

[IMP] account_peppol: improve display of Peppol error messages

Core17.0account_peppolMEDIUM

This update enhances the display of Peppol error messages within Odoo. Previously, technical error details were difficult for users to understand and act upon. Now, errors are presented as a clear, human-readable HTML list in the chatter, making it easier to diagnose and resolve issues related to Peppol integration.

Original PR description

Before this commit, Peppol error messages (e.g. Schematron errors) were logged in the chatter as a single unformatted line and without any humanization. The errors were too technical and the user could not easily know what action to take.

This PR splits the raw error payload into individual entries, maps known error codes to human-readable explanations, and renders them as an HTML list in the chatter.

task-6144909

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

#Peppol#error reporting#integration

Bug Fixes(6)

Resolved issues and error corrections

[FIX] account_sepa: sanitize QR-IBAN payment references

PR #123267

Enterprise17.0account_sepaMEDIUM

Swiss QR-IBAN payment files now remove unsupported characters from payment references before the file is generated. This helps prevent ISO 20022 payment files from being rejected by Swiss banks when references contain characters such as the degree symbol.

Original PR description

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

#Swiss payments#QR-IBAN#ISO 20022#bank file

[REF] product: Set max iterations to look for product combinations

PR #213285

Core17.0productMEDIUM

This update addresses a potential issue where product combinations could get stuck in an infinite loop, causing Odoo instances to freeze. The change sets a maximum iteration limit to prevent this, ensuring smoother operation and preventing prolonged downtime. This was triggered during a recent database migration and, while a rare occurrence, could have significant impact.

Original PR description

Sometimes, products get stuck for a long time while getting variant combinations in production.

Sets a maximum iteration limit to prevent an infinite loop.

The issue occurred on a production database migrated from Odoo 11.0 to 17.0.

Even if it is a corner case, it can block Odoo workers in an infinite loop and bring the entire instance down

#product#performance#stability

[FIX] payment_worldline: correct Cofidis payment mapping

PR #275874

Core17.0payment_worldlineMEDIUM

This update fixes a mapping issue with Worldline's Cofidis payment method. Previously, the system used an outdated payment product ID, leading to incorrect payment processing. Now, the mapping is updated to the latest Worldline documentation, ensuring accurate and reliable payment transactions.

Original PR description

opw-6368979

Description of the issue/feature this PR addresses:

Update the Worldline Cofidis payment method mapping to match the latest
payment product ID defined in the Worldline documentation.

Current behavior before PR:

The Cofidis payment method was mapped to the outdated payment product ID
(3012), causing payment requests to use an incorrect mapping.

Desired behavior after PR is merged:

The Cofidis payment method is mapped to the correct payment product ID
(5129) as per the latest Worldline documentation, ensuring payment
requests use the correct mapping.

#payment#Worldline#Cofidis

[FIX] payment_worldline: correct Cofidis payment mapping

PR #275881

Core17.0payment_worldlineMEDIUM

This update fixes an issue where the Worldline Cofidis payment method was incorrectly mapped to an outdated payment product ID. The change updates the mapping to the latest ID specified in Worldline documentation, ensuring accurate payment processing and preventing potential payment failures. This improves the reliability of Worldline payments.

Original PR description

opw-6368979

Description of the issue/feature this PR addresses:

Update the Worldline Cofidis payment method mapping to match the latest
payment product ID defined in the Worldline documentation.

Current behavior before PR:

The Cofidis payment method was mapped to the outdated payment product ID
(3012), causing payment requests to use an incorrect mapping.

Desired behavior after PR is merged:

The Cofidis payment method is mapped to the correct payment product ID
(5129) as per the latest Worldline documentation, ensuring payment
requests use the correct mapping.

#payments#Worldline#Cofidis

[FIX] account_edi_ubl_cii: check TaxInclusiveAmount on import

PR #271829

Core17.0account_edi_ubl_ciiMEDIUM

This update resolves an issue where Odoo incorrectly identified valid invoices with negative tax amounts as credit notes when importing UBL or Factur-X (CII) invoices. The change updates how Odoo interprets tax amounts during import, ensuring invoices are correctly recognized and processed. This improves data accuracy and prevents misclassification of financial documents.

Original PR description

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

#accounting#invoice#CII#UBL

[IMP] account_{edi_ubl_cii, peppol_selfbilling}: ensure unique sequence per partner for self-billing bills

PR #259935

Core17.0account_peppol_selfbillingaccountMEDIUM

This update fixes an issue where self-billing invoices created in sales journals caused traceability problems. It now ensures unique invoice sequences are used per partner, aligning with recent versions and preventing confusion during accounting firm workflows with quick edit mode. This improves data accuracy and reporting.

Original PR description

This PR handles 2 cases :

===== PART 1 =====
Self-billing bill sequences should be unique per partner, as implemented in v19+. 
This PR backports that behavior to 17.0.

===== PART 2 =====
Previously, the `is_self_billing` option on `account.journal` was available only for purchase journals.
This caused an issue when importing a self-billing invoice into a regular sales journal with quick edit mode (accounting firm) enabled.
In such cases, the newly created invoices would use the self-billing sequence pattern, leading to traceability issues.
This PR allows the creation of self-billing sales journals to prevent this issue.

task-6103142

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

#accounting#invoicing#self-billing

Before this commit, Peppol error messages (e.g. Schematron errors) were logged in the chatter as a single unformatted line and without any humanization. The errors were too technical and the user could not easily know what action to take. This PR splits the raw error payload into individual entries, maps known error codes to human-readable explanations, and renders them as an HTML list in the chatter. task-6144909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with a valid Swiss bank account. * Under **Accounting -> Configuration -> Settings** enable QR Payments. * Go to the vendor and enter the correct QR-IBAN number under the Accounting Section. * Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the account number of QR-IBAN. * Create and post a vendor payment using the bank journal. * Set the payment reference (`ref`) to contain the `°` character. * Add the payment to a batch payment and generate the ISO 20022 payment file. * Inspect the generated XML. **Observed Behaviour:** The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that may be rejected by Swiss banks because it does not comply with the EPC minimum character set. **Cause:** The QR-IBAN branch validates the structured reference before sanitizing it, allowing unsupported characters to remain in the generated XML. **Fix:** Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters are removed while preserving valid QR references. opw - 6350931

Sometimes, products get stuck for a long time while getting variant combinations in production. Sets a maximum iteration limit to prevent an infinite loop. The issue occurred on a production database migrated from Odoo 11.0 to 17.0. Even if it is a corner case, it can block Odoo workers in an infinite loop and bring the entire instance down

opw-6368979 Description of the issue/feature this PR addresses: Update the Worldline Cofidis payment method mapping to match the latest payment product ID defined in the Worldline documentation. Current behavior before PR: The Cofidis payment method was mapped to the outdated payment product ID (3012), causing payment requests to use an incorrect mapping. Desired behavior after PR is merged: The Cofidis payment method is mapped to the correct payment product ID (5129) as per the latest Worldline documentation, ensuring payment requests use the correct mapping.

Before this commit: - When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`. - In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. - In such situations, Odoo incorrectly imports the document as a credit note. Technical reason: - The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund. After this commit: - **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note. - Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes. Task-6321262

This PR handles 2 cases : ===== PART 1 ===== Self-billing bill sequences should be unique per partner, as implemented in v19+. This PR backports that behavior to 17.0. ===== PART 2 ===== Previously, the `is_self_billing` option on `account.journal` was available only for purchase journals. This caused an issue when importing a self-billing invoice into a regular sales journal with quick edit mode (accounting firm) enabled. In such cases, the newly created invoices would use the self-billing sequence pattern, leading to traceability issues. This PR allows the creation of self-billing sales journals to prevent this issue. task-6103142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr