Odoo Changelog — 2026-05-07

Thursday, May 7, 2026

6 changes · saas-18.4

Bug Fixes(6)

Resolved issues and error corrections

[FIX] account_accountant: fix currency grouping in reconciliation with foreign currency

Enterprisesaas-18.4account_accountantMedium

This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines during reconciliation was addressed. Now, the balance is consistently shown, regardless of the number of lines or currencies involved.

Original PR description

### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…

### Issue:
When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction

Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected

### Cause:
In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array

This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it
There is no reason to block the sum of lines with the same currency

When there is no selectedLines, the function returns early and doesn't unhide the balance

### Steps to reproduce:
- Install `account_accountant` with demo data
- Enable a foreign currency like EUR
- Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€)
- Go to the Dashboard, and select Bank
- Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$)
- Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency`
- Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$)
- Switch to the Kanban View and Reconcile the line Multi-currencies
- Select your 2 invoices one by one
Before the fix, after selecting the second invoice, the balance is displayed as `/`

For the additional case:
- Unselect all lines
- Select a line in another currency (e.g., USD), then unselect it
The balance remains hidden

opw-6063366

Forward-Port-Of: odoo/enterprise#115101

#currency#reconciliation#finance

[FIX] pos_urban_piper_enhancements: prep display crash for future delivery order

PR #116481

Enterprisesaas-18.4pos_urban_piperMedium

This update resolves a crash that occurred when preparing online food delivery orders scheduled for the future. The issue stemmed from an incorrect date format, which has now been corrected to ensure smooth order preparation workflows. This improves the reliability of our delivery system for online food orders.

Original PR description

### In this commit:

Fixes a crash in the preparation display when handling future online food delivery orders.

The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils.

Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176)

Forward-Port-Of: odoo/enterprise#108298

#delivery#order preparation#pos

[FIX] l10n_be_hr_payroll_sd_worx : Search for public holidays without calendar

PR #116421

Enterprisesaas-18.4l10n_be_hr_payrollMedium

This update ensures that all public holidays, including those without associated working schedules, are now correctly included in the SD Worx report. Previously, the system missed these holidays, leading to inaccurate payroll calculations. This fix improves the accuracy of payroll reporting for Belgian businesses.

Original PR description

### Steps to reproduce:
	- Create a public holiday without working schedule
	- Generate a SD worx for the month of the public holiday
	- Notice the public holiday is not shown in the report

### Cause:
When searching for the public holiday we don't take into condsideration the holidays without working schedule.

### Fix:
Modify the domain to fetch those holidays as well

opw-5500070

Forward-Port-Of: odoo/enterprise#114900

#payroll#reporting#holidays#Belgium

[FIX] account_avatax: prevent crash with pos order creation

PR #115840

Enterprisesaas-18.4account_avataxMedium

This update resolves a bug that caused Odoo to crash when creating Point of Sale (POS) orders with the Avatax module installed. The fix restores a previous method to correctly identify the customer's shipping information, ensuring POS order creation functions smoothly. This improves the reliability of the POS system for our users.

Original PR description

Before this commit, when pos_avatax was installed, creating a pos order could crash because the pos order does not have the partner_shipping_id field.

This commit re-adds the _get_avatax_ship_to_partner method as it was before the refactor https://github.com/odoo/enterprise/commit/0404086db567ee0595414263d36a3b7dceaa0dbe, which returns the partner_id for the pos order. The `_get_avatax_ship_to_partner` is overridden in `pos_avatax`. Since a `pos.order` does not have a `partner_shipping_id`, the overridden function only reads the partner_id.

opw-6122280

#pos#avatax#order creation

[FIX] l10n_nl_reports: fix SBR submission for multi-branch tax entities

PR #116428

Enterprisesaas-18.4l10n_nl_reportsMedium

This update resolves a problem that prevented correct submission of Dutch VAT returns (SBR) when using multiple companies within a single VAT unit. The fix ensures the system only uses the correct closing entry, preventing errors and improving the reliability of the SBR process. This impacts users who utilize Odoo's multi-company/multi-branch accounting.

Original PR description

In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process.

When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)`

This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group.

This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic.

Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1

opw-6106081

Forward-Port-Of: odoo/enterprise#116237

#VAT#Netherlands

[FIX] l10n_co_dian: fix AttachedDocument import detection

PR #115599

Enterprisesaas-18.4l10n_co_dianMedium

This update resolves an issue where DIAN XML files (AttachedDocument type) were not being imported correctly, leading to data loss. The fix ensures the system correctly identifies and processes these files, aligning with DIAN documentation and allowing for accurate data extraction.

Original PR description

### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN…

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101

### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176) Forward-Port-Of: odoo/enterprise#108298

### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070 Forward-Port-Of: odoo/enterprise#114900

Before this commit, when pos_avatax was installed, creating a pos order could crash because the pos order does not have the partner_shipping_id field. This commit re-adds the _get_avatax_ship_to_partner method as it was before the refactor https://github.com/odoo/enterprise/commit/0404086db567ee0595414263d36a3b7dceaa0dbe, which returns the partner_id for the pos order. The `_get_avatax_ship_to_partner` is overridden in `pos_avatax`. Since a `pos.order` does not have a `partner_shipping_id`, the overridden function only reads the partner_id. opw-6122280

In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process. When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)` This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group. This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic. Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1 opw-6106081 Forward-Port-Of: odoo/enterprise#116237

### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf However, no strict validation is enforced, so variants should still be supported ### Cause: When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:` This causes issues with documents structured like: ```xml <AttachedDocument> <CustomizationID>Documentos adjuntos</CustomizationID> <ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID> </AttachedDocument> ``` In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian` As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document ### Steps to reproduce: - Install `l10n_co_dian` - Go in Bills and import the test document: `import_attached_document_2` Before the fix, nothing it extracted from the xml opw-6083523