Odoo Changelog — 2026-08-19

Wednesday, August 19, 2026

9 changes · 17.0

Bug Fixes(9)

Resolved issues and error corrections

[FIX] sale_amazon: bump version after migration

Enterprise17.0sale_amazon

The Amazon sales connector version was updated after its Orders API migration. This helps customers and partners identify that the module includes the latest internal compatibility change for Amazon's newer API.

Original PR description

In https://github.com/odoo/enterprise/pull/114591, we migrated the Orders API from v0 to v2026-01-01 following Amazon's announce of v0's deprecation. In this commit, we update the version of the module to signal the internal change to the community.

task-5972714

#amazon#sales#version#api

[FIX] whatsapp: order template parameters by placeholder

PR #125671

Enterprise17.0whatsappMEDIUM

WhatsApp messages using templates with many mixed variable types now send values in the correct placeholder order. This prevents customers from receiving messages where details such as names, fields, or custom text appear in the wrong place.

Original PR description

**Issue**:
Sending a WhatsApp template with 10 or more variables can assign values to the wrong placeholders when the body contains mixed variable types, such as free text, field, or user name variables.
Templates containing only free-text variables are not affected.

**Reason**:
Meta consumes template parameters positionally, but for mixed variable types, Odoo built the parameter list using the template variable recordset order.
That order can differ from the numeric placeholder order, notably placing {{10}}, {{11}}, {{12}}... before {{1}}
when sending the message, as the payload parameters are not ordered by their numeric placeholder index.

**Fix:**
Sort body variables by their numeric placeholder index before preparing the Meta payload.

Task-6401501

#whatsapp#templates#message accuracy

[FIX] account_saft, l10n_lu_reports, l10n_ro_saft: minor SAF-T errors

PR #126121

Enterprise17.0account_saftl10n_lu_reportsl10n_ro_saftMEDIUM

This fix corrects several issues in SAF-T/FAIA reporting, including tax amounts, software version length, currency tax values, and customer/supplier invoice details. It helps Luxembourg and related SAF-T reports better match official validation rules and reduces audit or filing errors.

Original PR description

This is one of many errors fixing the FAIA report, which is the SAF-T report for Luxembourg. See PR #113316 for a list of similar PRs. ### Error 1: Negative tax amounts Auditors from Luxemborg…

This is one of many errors fixing the FAIA report, which is the SAF-T report for Luxembourg. See PR #113316 for a list of similar PRs.

### Error 1: Negative tax amounts

Auditors from Luxemborg provided one Odoo user with analysis files of their FAIA xml report. The following discrepancy was present in more than 300 lines:

`[TaxInformation/TaxAmount/Amount] # is negative. Only postive values are admitted. The sign is automatically determined by the corresponding CreditAmount (-) Or DebitAmount (+) on the same Line.`

This discrepancy was caused by two different scenarios. The first was a negative `unit_price` line, such as a Discount product. The second was a tax with negative and positive repartition lines, such as a tax with xml ID `lu_2015_tax_AP-EC-17`.

Luxembourg officials confirmed the following behavior:
1. The TaxInformation/TaxAmount/Amount element must be positive.
2. The TaxInformationTotals/TaxAmount/Amount element may be negative.
3. There may only be one TaxInformationTotals element per TaxCode in an Invoice element.

This commit ensures that these conditions are met for the FAIA report. I'm not sure if the TaxInformation changes should also be applied to the base `account_saft saft_report.xml` file.

### Error 2: SoftwareVersion

The SoftwareVersion element is limited to 18 characters. The relevant error from a customer's analysis file is below.

Error: Value exceeds maxLength of "18".

### Error 3: CurrencyAmount

The `account_saft` method `GeneralLedgerCustomHandler._saft_fill_report_tax_details_values()` does not report the amount of tax in foreign currency, instead replacing this value with the amount in company currency. No errors prompted this change; it just seems wrong on its face.

### Error 4:
PR #113720 ensured that the TaxType element is always TVA. This means that the TaxType should no longer should be ignored in our example documents.

### Error 5: Schema validation failure

The elements Inovice/CustomerInfo and Invoice/SupplierInfo are defined with the element `<xs:choice>` in the XSD file linked below. Only one can be present at any time, not both.

https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. note: currently the link is broken.

PR #100749 allowed many parts of SAF-T code to display both customer and supplier data, including these elements. This commit ensures that the elements are mutually exclusive.

opw-6344914 [Link](https://www.odoo.com/odoo/project.task/6344914)

#SAF-T#FAIA#Luxembourg#tax reporting#validation

[FIX] l10n_cl_edi: DTE with foreign currency but no foreign total

PR #126869

Enterprise17.0l10n_cl_ediMEDIUM

This fixes a failure when importing some Chilean electronic supplier invoices that include foreign currency details but omit an optional foreign-currency total. The import now falls back to the standard total, helping affected invoices process successfully through email fetching.

Original PR description

When importing an incoming DTE through the fetchmail server,
the total amount is read from the MntTotOtrMnda as soon as a
Moneda node is present in the document.

Steps to reproduce:
- Set up a CL company with a DTE mail server
- Fetch a DTE that includes the line-level Moneda node but
  does not include the header OtraMoneda block, so no MntTotOtrMnda
- Run the fetchmail cron and check the logs

Issue:
The DTE fails to import

Analysis:
Occurs since https://github.com/odoo-dev/enterprise/commit/5805a92f91411846fdffa245cb047397cfc9b1f3
Moneda is defined at line level while MntTotOtrMnda in the optional header
block Encabezado/OtraMoneda. Instead of assuming MntTotOtrMnda is
always present whenever the document carries a foreign currency, fall
back to the base-currency total MntTotal when it is missing.

opw-6432612

#Chile#electronic invoicing#DTE#invoice import

[FIX] l10n_rs_edi: show eFaktura API error response

PR #281490

Core17.0l10n_rs_ediMEDIUM

Odoo now shows the specific error details returned by Serbia’s eFaktura service when an invoice submission fails. This helps users understand why an invoice was rejected and resolve issues faster instead of seeing only a generic connection or HTTP error.

Original PR description

**Steps to reproduce:** - Install the Serbian EDI module `l10n_rs_edi`. - Configure eFaktura credentials on the company. - Create and confirm a Serbian customer invoice. - Send the invoice to…

**Steps to reproduce:**

-  Install the Serbian EDI module `l10n_rs_edi`.
-  Configure eFaktura credentials on the company.
-  Create and confirm a Serbian customer invoice.
-  Send the invoice to eFaktura.

**Observed Behavior:**

When the eFaktura API returns an HTTP error, Odoo only displays the generic exception generated by `requests`, for example an HTTP 400/500 error.

The actual error information returned by eFaktura in the response body is not shown to the user, making it difficult to understand why the invoice was rejected.

**Cause:**

`_l10n_rs_edi_send` catches `HTTPError`, `Timeout`, and `ConnectionError`, but the error message is built only from the Python exception.

For HTTP errors, the eFaktura API may return a response containing more precise information such as:

```json
{
    ErrorCode: ...,
    Message: ...
}
```

This response was not being used when displaying the error in Odoo.

**Fix:**

When an HTTP response is available and contains an eFaktura error payload, use the returned `ErrorCode` and `Message` as the error displayed on the invoice. Fallback to the existing connection/HTTP exception message when no usable API response is available.

opw - 6453653

#Serbia#eFaktura#invoicing#error messages

[FIX] web_editor: avoid duplicate attachment on image copy

PR #282287

Core17.0web_editor

This fix ensures that when an image already linked to another record is copied, Odoo reuses the existing attachment instead of creating an unnecessary duplicate. This helps keep the database cleaner and avoids extra storage and clutter behind the scenes.

Original PR description

Copying an image attachment already linked to another record could leave a redundant duplicate behind instead of reusing the existing one.

opw-6463012

#attachments#images#duplication#storage

[FIX] account_peppol: don't tick send if endpoint missing

PR #281199

Core17.0account_peppolMEDIUM

The Send & Print flow will no longer preselect “Send via PEPPOL” when the customer is missing required PEPPOL recipient details. This avoids failed invoice sending and makes sure users only see PEPPOL as an option when the recipient can actually receive it.

Original PR description

When opening the Send & Print wizard on a customer invoice, the "Send via PEPPOL" option could be checkeden even for a partner that is not able to receive Peppol documents because its Peppol EAS…

When opening the Send & Print wizard on a customer invoice, the
"Send via PEPPOL" option could be checkeden even for a partner that is not
able to receive Peppol documents because its Peppol EAS and/or Endpoint
are not set.

Steps to reproduce:
- Configure the company for Peppol sending.
- Create a customer as follows:
  - Country: Belgium
  - VAT: none
  - Format: BIS Billing 3.0
  - Peppol e-address (EAS): 0208
  - Poppol Endpoint: none
- Post a customer invoice for that partner.
- Click Send & Print.

Issue:
"Send via PEPPOL" is checked by default, so sending the invoice fails
with "The partner is missing Peppol EAS and/or Endpoint identifier.".

Analysis:

A partner with no EAS/Endpoint at all may still be treated as valid
for the send&print wizard, only to fail later at send time where the
EAS/Endpoint are effectively mandatory.
To avoid blocking automated flows (Connect+), the system should mark
such partners as invalid as soon as their Peppol EAS or Endpoint
is missing

opw-5717362

#peppol#invoice sending#send and print#customer invoice

[FIX] account_edi_ubl_cii: param to avoid wkhtmltopdf issues

PR #280246

Core17.0account_edi_ubl_cii

Before this commit it was impossible to avoid rendering the full report when an invoice had too many lines. This made it impossible to send some Peppol documents. To avoid this we add a system parameter that stops the document generation and prints a limit-reached page instead, avoiding the wkhtmltopdf time/memory issues. OPW-6352345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Original PR description

Before this commit it was impossible to avoid rendering the full report when an invoice had too many lines. This made it impossible to send some Peppol documents.

To avoid this we add a system parameter that stops the document generation and prints a limit-reached page instead, avoiding the wkhtmltopdf time/memory issues.

OPW-6352345

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

[FIX] hr_recruitment: Do not override employee work email with company email

PR #260123

Core17.0hr_recruitment

### Steps to Reproduce: - Create an applicant (with or without an email address). - Move the applicant to the *Hired* stage. - Create an employee from the applicant. - The employee’s work email is automatically being set to the company email. ### Fix: - Explicitly set work_email to False. - work_email=False is required as we have this compute method: https://github.com/odoo/odoo/blob/d84196003012d68b63b8a1564deb43e43c9ebd68/addons/hr/models/hr_employee_base.py#L200-L204 here work_

Original PR description

### Steps to Reproduce:
- Create an applicant (with or without an email address).
- Move the applicant to the *Hired* stage.
- Create an employee from the applicant.
- The employee’s work email is automatically being set to the company email.

### Fix:
- Explicitly set work_email to False.
- work_email=False is required as we have this compute method:
  https://github.com/odoo/odoo/blob/d84196003012d68b63b8a1564deb43e43c9ebd68/addons/hr/models/hr_employee_base.py#L200-L204
  here work_email and partner's email is being sync.

Task: 6124112

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

In https://github.com/odoo/enterprise/pull/114591, we migrated the Orders API from v0 to v2026-01-01 following Amazon's announce of v0's deprecation. In this commit, we update the version of the module to signal the internal change to the community. task-5972714

**Issue**: Sending a WhatsApp template with 10 or more variables can assign values to the wrong placeholders when the body contains mixed variable types, such as free text, field, or user name variables. Templates containing only free-text variables are not affected. **Reason**: Meta consumes template parameters positionally, but for mixed variable types, Odoo built the parameter list using the template variable recordset order. That order can differ from the numeric placeholder order, notably placing {{10}}, {{11}}, {{12}}... before {{1}} when sending the message, as the payload parameters are not ordered by their numeric placeholder index. **Fix:** Sort body variables by their numeric placeholder index before preparing the Meta payload. Task-6401501

This is one of many errors fixing the FAIA report, which is the SAF-T report for Luxembourg. See PR #113316 for a list of similar PRs. ### Error 1: Negative tax amounts Auditors from Luxemborg provided one Odoo user with analysis files of their FAIA xml report. The following discrepancy was present in more than 300 lines: `[TaxInformation/TaxAmount/Amount] # is negative. Only postive values are admitted. The sign is automatically determined by the corresponding CreditAmount (-) Or DebitAmount (+) on the same Line.` This discrepancy was caused by two different scenarios. The first was a negative `unit_price` line, such as a Discount product. The second was a tax with negative and positive repartition lines, such as a tax with xml ID `lu_2015_tax_AP-EC-17`. Luxembourg officials confirmed the following behavior: 1. The TaxInformation/TaxAmount/Amount element must be positive. 2. The TaxInformationTotals/TaxAmount/Amount element may be negative. 3. There may only be one TaxInformationTotals element per TaxCode in an Invoice element. This commit ensures that these conditions are met for the FAIA report. I'm not sure if the TaxInformation changes should also be applied to the base `account_saft saft_report.xml` file. ### Error 2: SoftwareVersion The SoftwareVersion element is limited to 18 characters. The relevant error from a customer's analysis file is below. Error: Value exceeds maxLength of "18". ### Error 3: CurrencyAmount The `account_saft` method `GeneralLedgerCustomHandler._saft_fill_report_tax_details_values()` does not report the amount of tax in foreign currency, instead replacing this value with the amount in company currency. No errors prompted this change; it just seems wrong on its face. ### Error 4: PR #113720 ensured that the TaxType element is always TVA. This means that the TaxType should no longer should be ignored in our example documents. ### Error 5: Schema validation failure The elements Inovice/CustomerInfo and Invoice/SupplierInfo are defined with the element `<xs:choice>` in the XSD file linked below. Only one can be present at any time, not both. https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. note: currently the link is broken. PR #100749 allowed many parts of SAF-T code to display both customer and supplier data, including these elements. This commit ensures that the elements are mutually exclusive. opw-6344914 [Link](https://www.odoo.com/odoo/project.task/6344914)

When importing an incoming DTE through the fetchmail server, the total amount is read from the MntTotOtrMnda as soon as a Moneda node is present in the document. Steps to reproduce: - Set up a CL company with a DTE mail server - Fetch a DTE that includes the line-level Moneda node but does not include the header OtraMoneda block, so no MntTotOtrMnda - Run the fetchmail cron and check the logs Issue: The DTE fails to import Analysis: Occurs since https://github.com/odoo-dev/enterprise/commit/5805a92f91411846fdffa245cb047397cfc9b1f3 Moneda is defined at line level while MntTotOtrMnda in the optional header block Encabezado/OtraMoneda. Instead of assuming MntTotOtrMnda is always present whenever the document carries a foreign currency, fall back to the base-currency total MntTotal when it is missing. opw-6432612

**Steps to reproduce:** - Install the Serbian EDI module `l10n_rs_edi`. - Configure eFaktura credentials on the company. - Create and confirm a Serbian customer invoice. - Send the invoice to eFaktura. **Observed Behavior:** When the eFaktura API returns an HTTP error, Odoo only displays the generic exception generated by `requests`, for example an HTTP 400/500 error. The actual error information returned by eFaktura in the response body is not shown to the user, making it difficult to understand why the invoice was rejected. **Cause:** `_l10n_rs_edi_send` catches `HTTPError`, `Timeout`, and `ConnectionError`, but the error message is built only from the Python exception. For HTTP errors, the eFaktura API may return a response containing more precise information such as: ```json { ErrorCode: ..., Message: ... } ``` This response was not being used when displaying the error in Odoo. **Fix:** When an HTTP response is available and contains an eFaktura error payload, use the returned `ErrorCode` and `Message` as the error displayed on the invoice. Fallback to the existing connection/HTTP exception message when no usable API response is available. opw - 6453653

When opening the Send & Print wizard on a customer invoice, the "Send via PEPPOL" option could be checkeden even for a partner that is not able to receive Peppol documents because its Peppol EAS and/or Endpoint are not set. Steps to reproduce: - Configure the company for Peppol sending. - Create a customer as follows: - Country: Belgium - VAT: none - Format: BIS Billing 3.0 - Peppol e-address (EAS): 0208 - Poppol Endpoint: none - Post a customer invoice for that partner. - Click Send & Print. Issue: "Send via PEPPOL" is checked by default, so sending the invoice fails with "The partner is missing Peppol EAS and/or Endpoint identifier.". Analysis: A partner with no EAS/Endpoint at all may still be treated as valid for the send&print wizard, only to fail later at send time where the EAS/Endpoint are effectively mandatory. To avoid blocking automated flows (Connect+), the system should mark such partners as invalid as soon as their Peppol EAS or Endpoint is missing opw-5717362