Odoo Changelog — 2026-08-19

Wednesday, August 19, 2026

7 changes · saas-18.4

Bug Fixes(7)

Resolved issues and error corrections

[FIX] account_invoice_extract: compare to sanitized IBAN

Enterprisesaas-18.4account_invoice_extract

Vendor bank account matching during invoice OCR now compares normalized IBAN values instead of the raw account text. This helps invoices match the correct partner bank account even when stored IBANs include spaces, dots, or dashes.

Original PR description

When looking for a matching IBAN, we were searching on the `acc_number` field, which can contain spaces or special characters (dots, dashes, etc). But the OCR always returns the IBAN in a sanitized format, without any space or special characters, so it should be compared against the sanitized IBAN of the partners.

task-none (issue found by chance)

Forward-Port-Of: odoo/enterprise#127775

#invoice OCR#IBAN#bank account matching

[FIX] l10n_de_reports: fix AccessError on Datev ATCH export

PR #127787

Enterprisesaas-18.4l10n_de_reportsMedium

Fixed an issue where accounting users could be blocked from exporting Datev attachment zip files when an invoice’s main image attachment came from a log note. This ensures permitted users can complete German Datev exports without needing administrator access.

Original PR description

### Issue:
When an invoice has an image as its main attachment added via a log note, any non-admin user who did not create the attachment gets an `AccessError` when exporting the Datev ATCH zip

### Cause:
Since commit `e7c93e5a6f`, attachments uploaded via certain flows can be "orphaned" — their `res_model` is set to `False` and `res_id` to `0` via `_fix_attachments_on_record_from_files_data`
This allows the attachment to appear in the chatter without being linked to the move's attachment list

However, `_message_set_main_attachment_id` can still set such an orphaned attachment as `message_main_attachment_id`
When a user without system rights tries to read it, the ORM access check uses `res_model=False` and `res_id=0`, which does not match the move the user has access to, raising an `AccessError`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create and confirm an Invoice (any lines, any customer)
- Add a Log Note with an image
- Set Demo user's Accounting rights to `Invoicing & Banks`
- Log in as Demo
- Open the General Ledger
- In the cog menu, choose `Datev ATCH (zip)`

Before the fix, an `AccessError` is raised

opw-6397804

#datev#attachments#export#invoicing

[FIX] documents : random kanban ordering after split

PR #127433

Enterprisesaas-18.4documents

Split PDF pages now appear in a predictable order in Documents. This prevents confusion when multiple pages are created at the same time and previously appeared randomly in the kanban view.

Original PR description

steps:
- upload a multi-page pdf
- split all the pages -> they now show in a random order

The issue is that the current documents are sorted by create_date desc, but the split creates all the different documents at the same time so they are sorted in the order they happen to be on the disk.

We now add a sort by id to act as a tie-breaker.

opw-6176840

Forward-Port-Of: odoo/enterprise#126683
Forward-Port-Of: odoo/enterprise#117255

#documents#pdf#kanban#ordering

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

PR #128291

Enterprisesaas-18.4l10n_din5008_account_followupl10n_din5008_industry_fsmMedium

PDF documents using the DIN 5008 layout now show dates in the expected day.month.year format for Germany, Austria, and Switzerland, regardless of the user's language settings. This prevents invoices, quotes, purchase orders, follow-up reports, 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

Forward-Port-Of: odoo/enterprise#128209
Forward-Port-Of: odoo/enterprise#126006

#DIN 5008#date format#Germany#PDF reports

[FIX] sale_renting_project: fix missing rental orders in project stat button

PR #121449

Enterprisesaas-18.4sale_renting_project

The project Sales button now shows all linked sales, including rental orders, so the list matches the number shown on the project. This prevents users from missing rental-related orders when reviewing project sales activity.

Original PR description

Steps to Reproduce
---
1. Install sale_renting_project.
2. Create a Project linked to 1 standard Sales Order and 1 Rental Order.
3. Observe the "Sales" stat button counts 2 Sales.
4. Click the stat button. Only the standard Sales Order is displayed.

Issue
---
In saas-18.4, the project Sales stat button calls action_view_sos without the from_embedded_action context key. As a result, _get_sale_orders_domain applies the non-rental filter by default, causing rental orders to be excluded from the action even though they are included in the displayed counter.

Expected Behavior
---
The Sales stat button should display all orders linked to the project, including both standard and rental orders, matching its total counter.

Fix
---
Return the base project domain unmodified when from_embedded_action is not set in the context.

task-6140201

#rental#projects#sales-orders

[FIX] account_iso20022: emit beneficiary state and street2 in PstlAdr

PR #128031

Enterprisesaas-18.4account_iso20022Medium

ISO 20022 payment files now include the beneficiary's state or province and second street address line when available. This helps prevent North American banks from rejecting wire transfers because of incomplete beneficiary address details.

Original PR description

The PstlAdr block written into pain.001 files never contains the partner's state/province nor the second street line, even when they are set on the record: _get_all_addr() now returns them, but…

The PstlAdr block written into pain.001 files never contains the
partner's state/province nor the second street line, even when they
are set on the record: _get_all_addr() now returns them, but
_get_PstlAdr() also needs to write them out. Some North American banks
reject wire transfers whose beneficiary address lacks the
state/province, so those payments fail regardless of how complete the
vendor record is.

Emit CtrySubDvsn when the address has a state, before Ctry as required
by the element order of the PostalAddress schema, and append street2
to the street address line.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Requires odoo/odoo#282518, which makes _get_all_addr() return the state and street2.

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

Forward-Port-Of: odoo/enterprise#128021
Forward-Port-Of: odoo/enterprise#127958

#payments#ISO 20022#vendor payments#bank transfers

[FIX] account_asset: discrepancy issues between depreciation schedule…

PR #128443

Enterprisesaas-18.4account_assetMedium

The asset app now detects when an asset's account no longer matches the account used on its related journal entry, which could cause differences between depreciation schedules and balance sheets. Users can see a warning and update affected assets in bulk, helping keep financial reports aligned.

Original PR description

… and balance sheet

When a user changes the account on a journal item that was linked to an asset, it creates discrepancy between the Depreciation Schedule, which relies on the asset's Fixed Asset Account, and the Balance Sheet that relies on the journal item's account.
We created a warning when such a discrepancy is detected, and allowed the user to mass edit the assets to change those accounts.

task-4314894

Forward-Port-Of: odoo/enterprise#122241

#assets#depreciation#balance sheet#accounting

When looking for a matching IBAN, we were searching on the `acc_number` field, which can contain spaces or special characters (dots, dashes, etc). But the OCR always returns the IBAN in a sanitized format, without any space or special characters, so it should be compared against the sanitized IBAN of the partners. task-none (issue found by chance) Forward-Port-Of: odoo/enterprise#127775

### Issue: When an invoice has an image as its main attachment added via a log note, any non-admin user who did not create the attachment gets an `AccessError` when exporting the Datev ATCH zip ### Cause: Since commit `e7c93e5a6f`, attachments uploaded via certain flows can be "orphaned" — their `res_model` is set to `False` and `res_id` to `0` via `_fix_attachments_on_record_from_files_data` This allows the attachment to appear in the chatter without being linked to the move's attachment list However, `_message_set_main_attachment_id` can still set such an orphaned attachment as `message_main_attachment_id` When a user without system rights tries to read it, the ORM access check uses `res_model=False` and `res_id=0`, which does not match the move the user has access to, raising an `AccessError` ### Steps to reproduce: - Install `l10n_de_reports` and switch to the DE company - Create and confirm an Invoice (any lines, any customer) - Add a Log Note with an image - Set Demo user's Accounting rights to `Invoicing & Banks` - Log in as Demo - Open the General Ledger - In the cog menu, choose `Datev ATCH (zip)` Before the fix, an `AccessError` is raised opw-6397804

steps: - upload a multi-page pdf - split all the pages -> they now show in a random order The issue is that the current documents are sorted by create_date desc, but the split creates all the different documents at the same time so they are sorted in the order they happen to be on the disk. We now add a sort by id to act as a tie-breaker. opw-6176840 Forward-Port-Of: odoo/enterprise#126683 Forward-Port-Of: odoo/enterprise#117255

* = 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 Forward-Port-Of: odoo/enterprise#128209 Forward-Port-Of: odoo/enterprise#126006

Steps to Reproduce --- 1. Install sale_renting_project. 2. Create a Project linked to 1 standard Sales Order and 1 Rental Order. 3. Observe the "Sales" stat button counts 2 Sales. 4. Click the stat button. Only the standard Sales Order is displayed. Issue --- In saas-18.4, the project Sales stat button calls action_view_sos without the from_embedded_action context key. As a result, _get_sale_orders_domain applies the non-rental filter by default, causing rental orders to be excluded from the action even though they are included in the displayed counter. Expected Behavior --- The Sales stat button should display all orders linked to the project, including both standard and rental orders, matching its total counter. Fix --- Return the base project domain unmodified when from_embedded_action is not set in the context. task-6140201

The PstlAdr block written into pain.001 files never contains the partner's state/province nor the second street line, even when they are set on the record: _get_all_addr() now returns them, but _get_PstlAdr() also needs to write them out. Some North American banks reject wire transfers whose beneficiary address lacks the state/province, so those payments fail regardless of how complete the vendor record is. Emit CtrySubDvsn when the address has a state, before Ctry as required by the element order of the PostalAddress schema, and append street2 to the street address line. Steps to reproduce: - Install Accounting and enable a generic ISO 20022 payment method on a bank journal - Create a vendor located in the US or Canada with a complete address, including the state and a second street line - Register a vendor payment, add it to a batch and generate the pain.001 file - The creditor PstlAdr has no state/province, and its street line only carries the first street field: the street2 part is dropped Requires odoo/odoo#282518, which makes _get_all_addr() return the state and street2. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#128021 Forward-Port-Of: odoo/enterprise#127958

… and balance sheet When a user changes the account on a journal item that was linked to an asset, it creates discrepancy between the Depreciation Schedule, which relies on the asset's Fixed Asset Account, and the Balance Sheet that relies on the journal item's account. We created a warning when such a discrepancy is detected, and allowed the user to mass edit the assets to change those accounts. task-4314894 Forward-Port-Of: odoo/enterprise#122241