Odoo Changelog — 2026-08-11

Tuesday, August 11, 2026

5 changes · 18.0

Bug Fixes(5)

Resolved issues and error corrections

[FIX] documents: ignore modal clicks in list global click handler

Enterprise18.0documentsMEDIUM

Fixed an issue in Documents where clicking inside the “Search More” selection dialog could unexpectedly close it while editing document details. Users can now sort, resize columns, and select contacts or related records without losing the dialog or their current document selection.

Original PR description

Steps to reproduce:
1. Install Documents
2. In the Documents list view, select a document to display the inspector.
3. Edit a field such as Owner or Customer which uses a Many2one widget.
4. In the field dropdown, click "Search More..." to open a modal dialog.
5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers).

Issue:
- The modal dialog immediately closes, and the contact cannot be selected.

Root cause:
- When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack.

Solution:
- Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer.
Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear
the main selection and destroy the inspector field.


opw-6253360

Forward-Port-Of: odoo/enterprise#119262

#documents#list view#modal#selection

[FIX] l10n_be_hr_payroll_acerta : Populate weekends in report when leave overlaps

PR #124500

Enterprise18.0l10n_be_hr_payroll_acertaMEDIUM

Belgian Acerta payroll exports now include weekend days when an eligible leave period, such as sick leave, overlaps a weekend. This helps ensure reports match Acerta requirements and avoids missing leave information in payroll submissions.

Original PR description

## Steps to reproduce:
	- Install l10n_be_hr_payroll_acerta
	- Create an employee in a belgian company
	- Create a sick time off for the created employee that overlaps with a weekend
	- Export acerta report for the employee
	- Notice the weekend that overlaps with the time off is not present in the report

## Cause:
While exporting the report file we only loop over the created work entries' dates and since weekends doesn't have work entries we don't consider them in the report.

## Fix:
When generating the line of a leave's start date we check if the leave overlaps with a WE, we fetch the WE's date and we generate a line for each day of the WE.

According to Acerta this is the correct behavior for their reports for specific types of leaves.

**opw-6313534**

#payroll#belgium#acerta#leave#reporting

[FIX] l10n_cl_edi: this fix adds new key values returned from SII

PR #127351

Enterprise18.0l10n_cl_ediMEDIUM

Odoo now recognizes five new response codes introduced by Chile's tax authority for supplier electronic documents. This prevents affected documents from getting stuck during processing and keeps the workflow aligned with the latest SII requirements.

Original PR description

**Before this PR:**
After the implementation of Resolution 161 of November 13th 2025, SII responses included keys not supported by the current l10n_cl_edi implementation. This resulted in supplier DTEs not being processed as they were before the change, because the five new keys were not found in Odoo's current `l10n_cl_claim` field, causing that the documents with these responses, were kept in a loop not solved.

**After this PR:**
The five new values from the resolution, along with their translations, were added to the selector field, fixing the process flow.

**SII Reference:**
https://www.sii.cl/normativa_legislacion/resoluciones/2025/reso161.pdf (see Event Code, page 5)

Forward-Port-Of: odoo/enterprise#121833

#Chile#SII#electronic invoicing#supplier documents

[FIX] l10n_mx_edi: update payment20.xml with "precision=6"

PR #127568

Enterprise18.0l10n_mx_ediMEDIUM

This fix ensures Mexican electronic payment documents use the required six-decimal precision for tax amounts. It prevents valid customer payments from being rejected due to small rounding mismatches in CFDI validation.

Original PR description

**Steps to reproduce:** - Checkout the source code before this commit: https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f - Install Accounting and l10n_mx_edi -…

**Steps to reproduce:**
- Checkout the source code before this commit: https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f

- Install Accounting and l10n_mx_edi

- Checkout the source code after the commit

- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Make sure that "Outstanding Receipts accounts" are set on the Bank journal
- Create an invoice:
  * Customer: [any] (e.g. Acme Corporationà
  * Payment Way: Efectivo
  * Payment Terms: [10 Days after End of Next Month] (in order to set "Payment Policy" to "PPD")
  * Product: [any]
  * Quantity: 1.0
  * Price: 295.17
  * Taxes: 16%
- Confirm the invoice
- Send CFDI
- Register payment
- "Upate Payments" from the invoice

**Issue:**
The payment CFDI is in error:
`Code : CRP20274
Message : El campo ImporteP que corresponde a Traslado, no es igual a la suma de los importes de los impuestos registrados en el documento relacionado donde el impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaP del documento relacionado sea igual al campo TasaOCuotaP de este elemento.`

**Cause:**
This commit https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f introduces 6 decimals for the payment CFDI taxes.
However, if `l10n_mx_edi` module is not upgraded, the required changes in `l10n_mx_edi.payment20` template won't be applied and the amounts will not sum up correctly.

opw-646062

#Mexico#CFDI#payments#taxes

[FIX] l10n_nl_reports: Handle missing closing entry

PR #127389

Enterprise18.0l10n_nl_reports_sbr_status_infoMEDIUM

The Dutch tax reporting status check now handles cases where a tax return record is missing its closing entry. This prevents one incomplete or broken record from stopping status updates for all other Digipoort tax returns.

Original PR description

The `l10n_nl_reports_sbr_status_info` contains the `l10n_nl_reports_sbr.status.service` class. The class is responsible for fetching the status of sent Digipoort tax returns. The status is then posted as a chatter message to the tax return's closing entry. Issues can arise when one of the status service records is, for whatever reason, missing a closing entry. In such case, the message cannot be posted, resulting in an exception being raised. Since the records are processed in a loop without a try-catch, this causes the whole action to fail. This can lead to one broken record effectively shutting down the whole module's functionality.

This PR adds some if-else checks to gracefully handle the case where the closing entry is missing.

Related tickets: opw-5901446 and opw-6410082

Forward-Port-Of: odoo/enterprise#125996

#Dutch localization#tax reporting#Digipoort#stability

Steps to reproduce: 1. Install Documents 2. In the Documents list view, select a document to display the inspector. 3. Edit a field such as Owner or Customer which uses a Many2one widget. 4. In the field dropdown, click "Search More..." to open a modal dialog. 5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers). Issue: - The modal dialog immediately closes, and the contact cannot be selected. Root cause: - When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack. Solution: - Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer. Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear the main selection and destroy the inspector field. opw-6253360 Forward-Port-Of: odoo/enterprise#119262

## Steps to reproduce: - Install l10n_be_hr_payroll_acerta - Create an employee in a belgian company - Create a sick time off for the created employee that overlaps with a weekend - Export acerta report for the employee - Notice the weekend that overlaps with the time off is not present in the report ## Cause: While exporting the report file we only loop over the created work entries' dates and since weekends doesn't have work entries we don't consider them in the report. ## Fix: When generating the line of a leave's start date we check if the leave overlaps with a WE, we fetch the WE's date and we generate a line for each day of the WE. According to Acerta this is the correct behavior for their reports for specific types of leaves. **opw-6313534**

**Before this PR:** After the implementation of Resolution 161 of November 13th 2025, SII responses included keys not supported by the current l10n_cl_edi implementation. This resulted in supplier DTEs not being processed as they were before the change, because the five new keys were not found in Odoo's current `l10n_cl_claim` field, causing that the documents with these responses, were kept in a loop not solved. **After this PR:** The five new values from the resolution, along with their translations, were added to the selector field, fixing the process flow. **SII Reference:** https://www.sii.cl/normativa_legislacion/resoluciones/2025/reso161.pdf (see Event Code, page 5) Forward-Port-Of: odoo/enterprise#121833

**Steps to reproduce:** - Checkout the source code before this commit: https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f - Install Accounting and l10n_mx_edi - Checkout the source code after the commit - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Make sure that "Outstanding Receipts accounts" are set on the Bank journal - Create an invoice: * Customer: [any] (e.g. Acme Corporationà * Payment Way: Efectivo * Payment Terms: [10 Days after End of Next Month] (in order to set "Payment Policy" to "PPD") * Product: [any] * Quantity: 1.0 * Price: 295.17 * Taxes: 16% - Confirm the invoice - Send CFDI - Register payment - "Upate Payments" from the invoice **Issue:** The payment CFDI is in error: `Code : CRP20274 Message : El campo ImporteP que corresponde a Traslado, no es igual a la suma de los importes de los impuestos registrados en el documento relacionado donde el impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaP del documento relacionado sea igual al campo TasaOCuotaP de este elemento.` **Cause:** This commit https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f introduces 6 decimals for the payment CFDI taxes. However, if `l10n_mx_edi` module is not upgraded, the required changes in `l10n_mx_edi.payment20` template won't be applied and the amounts will not sum up correctly. opw-646062

The `l10n_nl_reports_sbr_status_info` contains the `l10n_nl_reports_sbr.status.service` class. The class is responsible for fetching the status of sent Digipoort tax returns. The status is then posted as a chatter message to the tax return's closing entry. Issues can arise when one of the status service records is, for whatever reason, missing a closing entry. In such case, the message cannot be posted, resulting in an exception being raised. Since the records are processed in a loop without a try-catch, this causes the whole action to fail. This can lead to one broken record effectively shutting down the whole module's functionality. This PR adds some if-else checks to gracefully handle the case where the closing entry is missing. Related tickets: opw-5901446 and opw-6410082 Forward-Port-Of: odoo/enterprise#125996