Odoo Changelog — 2025-09-13

Saturday, September 13, 2025

6 changes · saas-18.4

Bug Fixes(6)

Resolved issues and error corrections

[FIX] account_iso20022: fix invalid XML structure for `ClrSysMmbId`

Enterprisesaas-18.4account_iso20022MEDIUM

This fix adjusts Swiss ISO 20022 payment files so bank clearing numbers are placed in the expected XML field structure. It helps prevent payment batch files from being rejected or flagged as invalid by banks and validation tools.

Original PR description

### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…

### Steps to reproduce:
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner
- Pay with "Swiss ISO20022"
- Create a batch payment with that payment and validate
- In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId))

### Cause:
The code directly inputs the value of `clearing_number` in `ClrSysMmbId`.

### Solution:
Add `MmbId` to contain the clearing number.

### Note:
The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`.

This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations.

opw-4872507

Forward-Port-Of: odoo/enterprise#94460

#payments#Swiss localization#ISO 20022#bank exports

[FIX] l10n_mx_edi: prevent error when adding CFDI Origin in credit notes

PR #92876

Enterprisesaas-18.4l10n_mx_ediMEDIUM

Fixes an issue that prevented users from saving Mexican customer credit notes when a CFDI Origin was entered. This helps businesses complete credit note workflows without encountering an error.

Original PR description

Currently, an error occurs when creating a customer credit note with a CFDI Origin.

**Steps to reproduce:**

- Install the `l10n_mx_edi` module and switch to `ESCUELA KEMPER URGATE` company.
- Navigate to: Invoicing > Customers > Credit Notes > New.
- Set `CFDI Origin` to `01|E19C50D2-1292-5817-BDDE-2666967C7471` and click `Save`.

**Error:**
`TypeError: unhashable type: 'list'`

**Root Cause:**
At [1], the code incorrectly uses `relationado_data['03', []]` instead of `relationado_data.get('03', [])`. The tuple `('03', [])` is treated as a dictionary key, which leads to an `error`.

**Fix:**
This commit ensures users can correctly set the CFDI Origin.

[1]
https://github.com/odoo/enterprise/blob/14b31a3631a97dd61ebd662fb768485e5a509c2c/l10n_mx_edi/models/account_move.py#L500

sentry-6823395705

#credit-notes#cfdi#mexico#invoicing

[FIX] l10n_es_reports: incorrect amount for accounts 551, 5525 in balance sheet

PR #94662

Enterprisesaas-18.4l10n_es_reportsMEDIUM

The Spanish balance sheet now avoids counting certain related-party payable accounts twice. This prevents overstated totals in the Other Current Payables section, giving businesses more accurate financial reports.

Original PR description

**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from…

**Steps to reproduce:**
1. Install `l10n_es_reports` and `accounting`.
2. Switch company to `ES Company`.
3. Create a journal entry using account 551 or 5525.
4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*.

**Observed behavior:**
- In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry.
- Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated.

**Root cause:**
* In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice:
  * once in credits and again in the balance, leading to double counting.

**Reference:**
* BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta
* PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447)

**Solution:**
- Removed accounts 551 and 5525 from the balance calculation to prevent duplication.

opw-5056965

Forward-Port-Of: odoo/enterprise#94310

#spanish-localization#balance-sheet#accounting

[FIX] account_reports: Fixed failing journal report unit test

PR #94658

Enterprisesaas-18.4account_reports

The journal report test was updated so it no longer depends on a payment reference staying blank in certain country-specific accounting setups. This helps keep automated builds stable when Czech localization is installed, reducing false test failures without changing user-facing accounting behavior.

Original PR description

test_document_data_basic was failing in builds with l10n_cz installed because
- we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty
- but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in)

this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation

build_error-231479

Forward-Port-Of: odoo/enterprise#94554

#journal report#testing#localization

[FIX] sign: Improve stability of sign item placement during PDF rendering

PR #94694

Enterprisesaas-18.4signMEDIUM

Users can no longer place signing fields on a PDF page before it has finished loading, preventing errors during document preparation. The update also improves page refresh handling so temporary elements are not removed at the wrong time.

Original PR description

Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading.

Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically.

task-5065598

Forward-Port-Of: odoo/enterprise#94666
Forward-Port-Of: odoo/enterprise#94001

#pdf#signing#stability

[FIX] auth_totp: synchronization on webclient boot

PR #226996

Coresaas-18.4auth_totp

This fixes a timing issue that could cause the two-step authentication flow to behave unreliably when the web client starts. It updates the related test synchronization so the problem is properly covered and less likely to reappear.

Original PR description

Should actually fix what #224161 tried to: I didn't notice that the events had been renamed (#220852) and since the test was still disabled (and the fixing PR was set to the master one) all the CIs ran without the test, thus not testing the fix in any way.

It could have passed anyway as it's a non-deterministic issue, but it's at best a 50/50 that it succeeds so over 3 stagings I'd most likely have seen it...

https://runbot.odoo.com/odoo/error/231316
https://runbot.odoo.com/odoo/error/181862 (the original of the same)

Forward-Port-Of: odoo/odoo#226857

#two-factor-authentication#login#reliability

### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner - Pay with "Swiss ISO20022" - Create a batch payment with that payment and validate - In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId)) ### Cause: The code directly inputs the value of `clearing_number` in `ClrSysMmbId`. ### Solution: Add `MmbId` to contain the clearing number. ### Note: The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`. This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations. opw-4872507 Forward-Port-Of: odoo/enterprise#94460

Currently, an error occurs when creating a customer credit note with a CFDI Origin. **Steps to reproduce:** - Install the `l10n_mx_edi` module and switch to `ESCUELA KEMPER URGATE` company. - Navigate to: Invoicing > Customers > Credit Notes > New. - Set `CFDI Origin` to `01|E19C50D2-1292-5817-BDDE-2666967C7471` and click `Save`. **Error:** `TypeError: unhashable type: 'list'` **Root Cause:** At [1], the code incorrectly uses `relationado_data['03', []]` instead of `relationado_data.get('03', [])`. The tuple `('03', [])` is treated as a dictionary key, which leads to an `error`. **Fix:** This commit ensures users can correctly set the CFDI Origin. [1] https://github.com/odoo/enterprise/blob/14b31a3631a97dd61ebd662fb768485e5a509c2c/l10n_mx_edi/models/account_move.py#L500 sentry-6823395705

**Steps to reproduce:** 1. Install `l10n_es_reports` and `accounting`. 2. Switch company to `ES Company`. 3. Create a journal entry using account 551 or 5525. 4. Open the Balance Sheet from *Accounting → Reporting → Balance Sheet*. **Observed behavior:** - In the Balance Sheet, under *3. Other Current Payables*, the amount shown is double the journal entry. - Drilling down shows the correct amount in the journal entry, but the Balance Sheet line is overstated. **Root cause:** * In the expression for *3. Other Current Payables*, accounts **551** and **5525** were included twice: * once in credits and again in the balance, leading to double counting. **Reference:** * BOE: https://www.boe.es/eli/es/rd/2007/11/16/1514/con#cuenta * PR with related changes: [odoo/enterprise#82447](https://github.com/odoo/enterprise/pull/82447) **Solution:** - Removed accounts 551 and 5525 from the balance calculation to prevent duplication. opw-5056965 Forward-Port-Of: odoo/enterprise#94310

test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#94554

Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94666 Forward-Port-Of: odoo/enterprise#94001

Should actually fix what #224161 tried to: I didn't notice that the events had been renamed (#220852) and since the test was still disabled (and the fixing PR was set to the master one) all the CIs ran without the test, thus not testing the fix in any way. It could have passed anyway as it's a non-deterministic issue, but it's at best a 50/50 that it succeeds so over 3 stagings I'd most likely have seen it... https://runbot.odoo.com/odoo/error/231316 https://runbot.odoo.com/odoo/error/181862 (the original of the same) Forward-Port-Of: odoo/odoo#226857