Odoo Changelog — 2026-08-18

Tuesday, August 18, 2026

5 changes · 18.0

Improvements(1)

Enhancements to existing features

[IMP] sign: only creator can change signer email

Enterprise18.0signMEDIUM

Signer email addresses on signature requests can now only be changed by the person who created the request. This helps prevent unintended or unauthorized recipient changes and keeps the signing process more controlled.

Original PR description

Forward-Port-Of: odoo/enterprise#126675

#signatures#permissions#email

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_co_dian: backport XML parser to include withholding taxes

PR #126186

Enterprise18.0l10n_co_dianMEDIUM

Odoo now correctly reads Colombian vendor bill XML files that include withholding taxes. This ensures ReteRenta, ReteIVA, and ReteICA amounts are added to invoice lines, reducing manual corrections and improving tax accuracy.

Original PR description

Currently, Odoo doesn't detect Withholdings taxes for Colombia while uploading vendor bill XML, causing ReteRenta, ReteIVA, ReteICA withholdings to not being added in invoice lines, for versions under 19.2

Fix: Backport commit https://github.com/odoo/enterprise/commit/edc67858350d1b8408019e51751240026d931dab

Versions: 18.0 -> 19.1

Task-id: [6417175](https://www.odoo.com/odoo/project/49/tasks/6417175)

#colombia#vendor bills#withholding taxes#xml import

[FIX] l10n_*: fix date format and commercial register in footer

PR #126006

Enterprise18.0l10n_din5008_account_followupl10n_din5008_industry_fsmMEDIUM

DIN 5008 PDF documents now consistently show dates in the expected day.month.year format for Germany, Austria, and Switzerland, regardless of the user's language settings. This prevents customer-facing documents such as invoices, quotations, purchase orders, follow-ups, and field service worksheets from displaying confusing or non-compliant date formats.

Original PR description

* = din5008_account_followup, din5008_industry_fsm

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

opw-6392649

#DIN 5008#date format#PDF reports#localization

[FIX] {account,l10n_ma}_reports: correctly include budget in l10n_ma Profit and Loss

PR #127054

Enterprise18.0account_reportsl10n_ma_reportsMEDIUM

Fixes the Moroccan Profit and Loss report so budget figures are included instead of appearing empty. The report also now shows the related budget percentage column, giving users a more complete view for financial planning and comparison.

Original PR description

Issue:
Budgets are not working on Profit and Loss in the l10n_ma.

Steps to Reproduce:
 - Install l10n_ma
 - Go to Profit and Loss, create a budget
 - Select Profit and Loss Statement (MA)
 - Budget is empty.

Reason:
For l10n_ma we use different values on `target_line_res_dict` (`cur_op` `prev_op` `cur_tot`) rather than the usual `balance`.
This causes our budget column to have those same 3 types instead of the usual `balance`.
When we then search for the dict entry `balance` in `target_line_res_dict`, we won't find anything giving us `None` and causing the current issue where nothing appears.

https://github.com/odoo/enterprise/blob/61e3272430b4adeefb90a0a224bd308a3267decf/account_reports/models/account_report.py#L3125-L3129

opw-6385229

#budgets#profit and loss#morocco#financial reports

[FIX] account_iso20022: correct <LEI> tag filter in SEPA

PR #127758

Enterprise18.0account_iso20022MEDIUM

This fixes German SEPA credit transfer exports so they no longer include an unsupported LEI field in older bank file formats. The change keeps generated payment files compliant with bank requirements, reducing the risk of rejected vendor payment batches.

Original PR description

### Issue before this commit: When generating a SEPA Credit Transfer batch using the German XML format (pain.001.001.03), the <LEI> tag is erroneously included in the exported file if an LEI is…

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Settins > Vendor Payments > SEPA Credit Transfer / ISO20022 and set Name Identification as 529900T8BM49AURSDO55 and Issuer as LEIMAN
3. Go to companies and set 529900T8BM49AURSDO55 as LEI in the DE company
4. Go to Accounting dashboard and click the 3 dots of the bank group, go to Configuration and set the Account Number and be sure in the Outgoing Payments tab XML Format is German
5. Create a new German company from Contacts with:
1. Country as Germany
2. VAT
3. Account Number in the Bank Accounts by adding one line:
1. example Account Number: DE65100500007201811026
2. example Bank: BNP Paribas
3. activate the Send Money button
7. Then go to Vendor > Payments and create a new one with Payment Method as SEPA Credit Transfer for the German company created
8. Go back and select the new payment from the list and click create batch and print it
9. In the XML of pain.001.001.03.(DE) file, the LEI tag should not be included.

### Cause of the issue:
The XML generation logic does not filter out the <LEI> element for older schema versions like pain.001.001.03, which do not support this tag.

### Reason to introduce the fix:
To ensure strict schema compliance and prevent bank rejections. The <LEI> element is now properly omitted from pain.001.001.03 files and restricted only to newer formats (e.g., pain.001.001.09) where it is valid.

opw-6428150

#SEPA#payments#bank export#Germany#ISO 20022

Currently, Odoo doesn't detect Withholdings taxes for Colombia while uploading vendor bill XML, causing ReteRenta, ReteIVA, ReteICA withholdings to not being added in invoice lines, for versions under 19.2 Fix: Backport commit https://github.com/odoo/enterprise/commit/edc67858350d1b8408019e51751240026d931dab Versions: 18.0 -> 19.1 Task-id: [6417175](https://www.odoo.com/odoo/project/49/tasks/6417175)

* = din5008_account_followup, din5008_industry_fsm **Steps to reproduce:** * Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`) * Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.). **Observed behavior (date format):** * All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH. **Cause (date format):** * All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`). **Fix (date format):** * Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`). * This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention. opw-6392649

Issue: Budgets are not working on Profit and Loss in the l10n_ma. Steps to Reproduce: - Install l10n_ma - Go to Profit and Loss, create a budget - Select Profit and Loss Statement (MA) - Budget is empty. Reason: For l10n_ma we use different values on `target_line_res_dict` (`cur_op` `prev_op` `cur_tot`) rather than the usual `balance`. This causes our budget column to have those same 3 types instead of the usual `balance`. When we then search for the dict entry `balance` in `target_line_res_dict`, we won't find anything giving us `None` and causing the current issue where nothing appears. https://github.com/odoo/enterprise/blob/61e3272430b4adeefb90a0a224bd308a3267decf/account_reports/models/account_report.py#L3125-L3129 opw-6385229

### Issue before this commit: When generating a SEPA Credit Transfer batch using the German XML format (pain.001.001.03), the <LEI> tag is erroneously included in the exported file if an LEI is configured on the company. This invalidates the XML, causing banks to reject the file. ### Steps to reproduce the issue: 1. Download Accounting and l10n_de 2. Go to Settins > Vendor Payments > SEPA Credit Transfer / ISO20022 and set Name Identification as 529900T8BM49AURSDO55 and Issuer as LEIMAN 3. Go to companies and set 529900T8BM49AURSDO55 as LEI in the DE company 4. Go to Accounting dashboard and click the 3 dots of the bank group, go to Configuration and set the Account Number and be sure in the Outgoing Payments tab XML Format is German 5. Create a new German company from Contacts with: 1. Country as Germany 2. VAT 3. Account Number in the Bank Accounts by adding one line: 1. example Account Number: DE65100500007201811026 2. example Bank: BNP Paribas 3. activate the Send Money button 7. Then go to Vendor > Payments and create a new one with Payment Method as SEPA Credit Transfer for the German company created 8. Go back and select the new payment from the list and click create batch and print it 9. In the XML of pain.001.001.03.(DE) file, the LEI tag should not be included. ### Cause of the issue: The XML generation logic does not filter out the <LEI> element for older schema versions like pain.001.001.03, which do not support this tag. ### Reason to introduce the fix: To ensure strict schema compliance and prevent bank rejections. The <LEI> element is now properly omitted from pain.001.001.03 files and restricted only to newer formats (e.g., pain.001.001.09) where it is valid. opw-6428150