Odoo Changelog — 2026-09-12

Saturday, September 12, 2026

3 changes · saas-19.4

Bug Fixes(3)

Resolved issues and error corrections

[FIX] hr_expense_stripe: Traceback in auth request when no expense date

Enterprisesaas-19.4hr_expense_stripeMedium

Fixed an issue where a company card could be blocked from making new payments if one of its generated expenses had no date. Expenses without dates are now handled safely and only counted in all-time limit checks, keeping card payments available while preserving spending controls.

Original PR description

Fix a traceback preventing card users to make any payment with their card if at least one expense created by said card has no date

Steps to reproduce:
- Install hr_expense_stripe_demo (to access the test wizards)
- Setup the stripe (demo) account with a valid card and funds
- Create one transaction with the card
- Remove the date of the generated expense

-> Any further transaction with that card will fail

After this commit:
An expense with no date is considered only in the 'all time'

Ticket [link](https://www.odoo.com/odoo/project.task/6326124)
opw-6326124

Forward-Port-Of: odoo/enterprise#130337

#expenses#stripe#company cards#payments

[FIX] l10n_cl_edi_boletas: handle empty response from SII

PR #131324

Enterprisesaas-19.4l10n_cl_ediMedium

The Chilean electronic invoicing process now handles empty responses from the tax authority when checking document status. This prevents scheduled processing from failing unexpectedly, helping invoice workflows continue reliably.

Original PR description

When checking the status of a DTE, sometimes the response will have no `text`. This causes a traceback error that halts execution of the cron `cron_run_sii_workflow`.

opw-6322106

Forward-Port-Of: odoo/enterprise#130873
Forward-Port-Of: odoo/enterprise#129582

#Chile#electronic invoicing#scheduled processing

[REV] account_iso20022:remove invalid CtrySubDvsn tag in SEPA XML

PR #131303

Enterprisesaas-19.4account_iso20022Medium

SEPA payment XML files no longer include an address field that some European banks reject. This helps Austrian, German, and other affected banks accept batch payment files generated from Accounting.

Original PR description

### Steps to reproduce the issue:
1. Download Accounting and l10n_at
2. Go to settings and activate SEPA Credit Transfer / ISO20022
3. Go to Journals > Bank > set an account number
4. Create an austrian contact (ex. FK Austria Wien AG) and set in the invoicing tab a bank (ex. AT526000071856851733) and set it trusted
5. Go to Bills, create a new one with the contact created and confirm it
6. Then click 'PAY' and select SEPA Credit Transfer
7. Go to Vendors > Batch Payments
8. Create a new one with:
1. Bank as bank
2. SEPA Credit Transfer as Payment Method
3. Add the bill just created
9. Validate and download the XML
10. See that a wrong tag <CtrySubDvsn> is added. This makes some banks refuse it

### Cause of the issue:
External commit 30b023d394a5e4de64873188aa1d5961fecccb10 introduced the `<CtrySubDvsn>` tag to support US and CA requirements. However, the change was incorrectly applied to the common `account_iso20022` file, making it leak into standard European SEPA exports where the tag is not compliant with certain strict banking validation rules.

### Reason to introduce the fix:
Revert the generic addition of the `<CtrySubDvsn>` tag in the common ISO20022 XML generation and restrict it only to the specific localizations (US/CA) that require it. This brings the `<PstlAdr>` node back to compliance, allowing Austrian, German, and other European banks to successfully process the files.

opw-6523035

Forward-Port-Of: odoo/enterprise#131156
Forward-Port-Of: odoo/enterprise#131090

Fix a traceback preventing card users to make any payment with their card if at least one expense created by said card has no date Steps to reproduce: - Install hr_expense_stripe_demo (to access the test wizards) - Setup the stripe (demo) account with a valid card and funds - Create one transaction with the card - Remove the date of the generated expense -> Any further transaction with that card will fail After this commit: An expense with no date is considered only in the 'all time' Ticket [link](https://www.odoo.com/odoo/project.task/6326124) opw-6326124 Forward-Port-Of: odoo/enterprise#130337

When checking the status of a DTE, sometimes the response will have no `text`. This causes a traceback error that halts execution of the cron `cron_run_sii_workflow`. opw-6322106 Forward-Port-Of: odoo/enterprise#130873 Forward-Port-Of: odoo/enterprise#129582

### Issue before this commit: Generating a SEPA Credit Transfer XML for certain European banks (e.g., Austrian and German banks) fails because the generated XML contains an unexpected `<CtrySubDvsn>` tag inside the `<PstlAdr>` node, leading to the rejection of the batch payment file. ### Steps to reproduce the issue: 1. Download Accounting and l10n_at 2. Go to settings and activate SEPA Credit Transfer / ISO20022 3. Go to Journals > Bank > set an account number 4. Create an austrian contact (ex. FK Austria Wien AG) and set in the invoicing tab a bank (ex. AT526000071856851733) and set it trusted 5. Go to Bills, create a new one with the contact created and confirm it 6. Then click 'PAY' and select SEPA Credit Transfer 7. Go to Vendors > Batch Payments 8. Create a new one with: 1. Bank as bank 2. SEPA Credit Transfer as Payment Method 3. Add the bill just created 9. Validate and download the XML 10. See that a wrong tag <CtrySubDvsn> is added. This makes some banks refuse it ### Cause of the issue: External commit 30b023d394a5e4de64873188aa1d5961fecccb10 introduced the `<CtrySubDvsn>` tag to support US and CA requirements. However, the change was incorrectly applied to the common `account_iso20022` file, making it leak into standard European SEPA exports where the tag is not compliant with certain strict banking validation rules. ### Reason to introduce the fix: Revert the generic addition of the `<CtrySubDvsn>` tag in the common ISO20022 XML generation and restrict it only to the specific localizations (US/CA) that require it. This brings the `<PstlAdr>` node back to compliance, allowing Austrian, German, and other European banks to successfully process the files. opw-6523035 Forward-Port-Of: odoo/enterprise#131156 Forward-Port-Of: odoo/enterprise#131090