Odoo Changelog — 2026-01-17

Saturday, January 17, 2026

6 changes · saas-18.3

Bug Fixes(6)

Resolved issues and error corrections

17.0 FIX Decimals in TotClauVta tag

Enterprisesaas-18.3l10n_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 invoice exports and avoids potential rejection by the SII system.

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

#SII#export invoices#Chile

[FIX] l10n_pt: Automate tax based on state

PR #236005

Coresaas-18.3l10n_ptMedium

This update automatically determines the correct VAT rate for sales orders based on the warehouse location, ensuring compliance with Portuguese tax regulations. Previously, VAT rates were manually set, leading to potential errors and delays. This change streamlines the process and reduces the risk of incorrect invoicing.

Original PR description

Implements automation to correctly set the sales order fiscal position based on the warehouse, ensuring compliance with "place of supply" VAT rules.

Problem:
- The VAT rate must be determined by the supply location (warehouse), not the customer's delivery address.
- Manually selecting the fiscal position on every sales order is slow and highly prone to user error, leading to incorrect invoicing.

task-5088046

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#235887
Forward-Port-Of: odoo/odoo#227994

#VAT#Tax#Portugal#Compliance

[PERF] account_budget: optimize budget report SQL query plan

PR #104643

Enterprisesaas-18.3accountMedium

This update optimizes the SQL query used to generate budget reports, resulting in significantly faster performance, especially with large datasets. The change refactors the query to utilize a more efficient join strategy, reducing processing time and improving report generation speed. This directly impacts user experience and report loading times.

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

[FIX] l10n_ke_edi_oscu: hide eTIMS warning for non-Kenyan companies

PR #104649

Enterprisesaas-18.3l10n_ke_edi_oscu

This update corrects a misleading warning displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to companies based in Kenya, preventing unnecessary alerts and improving the user experience. This change simplifies invoice processing for all users.

Original PR description

**Steps to reproduce:**
* Install the **l10n_ke_edi_oscu** module.
* Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”).
* Open any invoice for that company.

**Observed behavior:**
* A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya.

**Cause:**
* The eTIMS validation logic runs for **all companies**.
* Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning.

**Fix:**
* Run the eTIMS validation only for **Kenyan companies**.
* Suppress the warning for companies outside Kenya.

opw-5435558

Forward-Port-Of: odoo/enterprise#103158

#eTIMS#Kenya#Invoice#Warning

[FIX] account_followup: show activity in list view only when schedule activity is enabled

PR #104669

Enterprisesaas-18.3account_followup

This update ensures that the 'Activity' column in the Follow-up Levels list view only shows when 'Schedule Activity' is enabled. Previously, it incorrectly displayed an activity even when this option was turned off. This change improves the clarity and accuracy of follow-up level data.

Original PR description

Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…

Currently, follow-up levels display an `activity` in the list view even 
when the `Schedule Activity` option is not enabled on the record.

**Steps to reproduce:**
- Install the `account_followup` module.
- Navigate to Accounting > Configuration > Invoicing > Follow-up Levels.
- Click `New` and enter a `description`.
- Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`.
- `Disable` Schedule Activity, `save` the record again, and return to the `list view`.
- Observe the `Activity` for the newly created follow-up level.

**Observation:**
The Activity column still shows a value in the list view, even though Schedule Activity is unchecked.

**Root Cause:**
At [1], `activity_type_id` is always shown in the list view without 
considering `create_activity`, causing the `activity` to remain visible 
even when `Schedule Activity` is `disabled`.

**Fix:**
This commit ensures that the `Activity` is displayed in the list view only 
when `Schedule Activity` (`create_activity`) is enabled for the record.

[1]:
https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13

opw-5476176

Forward-Port-Of: odoo/enterprise#104427

[IMP] certificate, account_edi_proxy_client: manage CA certificate stores

PR #244376

Coresaas-18.3account_edi_proxy_clientcertificateSecurity

This update enhances the security of our web connections by allowing us to securely verify server identities using certificate records. Previously, our system struggled to utilize certificate verification effectively due to limitations in the underlying software. This change adds a more robust method for confirming the authenticity of our connections, strengthening overall security.

Original PR description

Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. 
This is rather complicated, since PyOpenSSL only allows filenames with their default methods. 
We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store.

IAP PR: odoo/iap-apps#1308

Task [link](https://www.odoo.com/odoo/project.task/5068741)
task-5068741

Forward-Port-Of: odoo/odoo#238717

#security#certificate#web connection

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

Implements automation to correctly set the sales order fiscal position based on the warehouse, ensuring compliance with "place of supply" VAT rules. Problem: - The VAT rate must be determined by the supply location (warehouse), not the customer's delivery address. - Manually selecting the fiscal position on every sales order is slow and highly prone to user error, leading to incorrect invoicing. task-5088046 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235887 Forward-Port-Of: odoo/odoo#227994

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

**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158

Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427

Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#238717