Odoo Changelog — 2026-01-17

Saturday, January 17, 2026

3 changes · saas-18.4

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_hu_edi, l10n_de: keep manual currency rate when posting invoices

Coresaas-18.4accountl10n_del10n_hu_ediMedium

This update ensures that manually set currency rates on customer invoices (specifically for German and Hungarian invoices) are correctly applied during the posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This change maintains the user's intended rate, improving invoice accuracy and financial reporting.

Original PR description

Initial setup: Install  l10n_hu_edi and l10n_de.

When creating a customer invoice DE in a foreign currency, a manually edited
currency rate was overridden at posting time with the rate from the currency
table.

Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes.

Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves.

task-5391774

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

Forward-Port-Of: odoo/odoo#242192

#currency#invoice#reporting#financials

17.0 FIX Decimals in TotClauVta tag

PR #104169

Enterprisesaas-18.4l10n_cl_ediMedium

This update resolves a problem where Odoo invoices exported to the SII system (Chile) were being rejected due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential disruptions to sales processes.

Original PR description

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

[PERF] account_budget: optimize budget report SQL query plan

PR #104652

Enterprisesaas-18.4accountMedium

This update optimizes the SQL query used to generate the budget report, resulting in significantly faster performance, especially with large datasets. The change refactors the query to better utilize database optimization techniques, reducing processing time and improving report generation speed. This enhances the overall user experience for this key financial report.

Original PR description

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104531
Forward-Port-Of: odoo/enterprise#104299

Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192

Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862 Forward-Port-Of: odoo/enterprise#104531 Forward-Port-Of: odoo/enterprise#104299