Odoo Changelog — 2025-12-20

Saturday, December 20, 2025

7 changes

Branch: saas-18.4

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_ke_edi_oscu: prevent error when sending vendor bill to eTIMS

PR #102596

Enterprisesaas-18.4l10n_ke_edi_oscuMEDIUM

This update resolves an error that prevented vendor bills from being correctly sent to eTIMS. The issue stemmed from incorrect eTIMS configuration during company setup. Now, the system will correctly handle sending bills to eTIMS when the eTIMS settings are properly configured.

Original PR description

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

Forward-Port-Of: odoo/enterprise#101319

#eTIMS#Kenya#EDI

[FIX] web: fix load of embedded actions in action service

PR #240702

Coresaas-18.4webMEDIUM

This update resolves a bug where custom embedded actions weren't consistently displayed across different Odoo projects. The fix ensures that actions are correctly loaded and available in the top bar, regardless of which project a user is currently working in or if they refresh the page. This improves the user experience and functionality of embedded actions.

Original PR description

Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces…

Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs:
- Create a project A and project B, activate the top bar in both projects
    - Create a new custom embedded action in project A
    - Switch to project B (by changing the URL), the custom action of project A is present in project B
- In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar.

It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action.

We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction".

task-5269261

Forward-Port-Of: odoo/odoo#240558
Forward-Port-Of: odoo/odoo#237695

#embedded actions#user experience

[FIX] documents: load custom views for documents from activity systray

PR #102585

Enterprisesaas-18.4documentsMEDIUM

This update resolves an issue where navigating to documents from the 'Activities' icon caused the custom document view to fail, preventing features like document previews. The fix ensures the correct custom view is loaded, guaranteeing the desired functionality works as expected for users.

Original PR description

When navigating to documents from the 'Activities' systray icon, the
system would load an action that correctly filtered for "My Activities"
but lacked the specific view definitions of the main Documents app.

This caused the 'List' view-switcher to load the default list view
instead of the custom one, breaking features like document preview that
depend on the custom view's JavaScript.

This patch fixes the issue by ensuring that the correct, custom view
definitions from the main Documents app are loaded. This guarantees
that the custom list view and all its features work correctly,
regardless of how the user navigates to it.

This ensures the correct custom list view is loaded while preserving the
"My Activities" filter.

Task-5187045

Forward-Port-Of: odoo/enterprise#102442
Forward-Port-Of: odoo/enterprise#98979

#documents#user experience#functionality

Branch: saas-18.3

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_ke_edi_oscu: prevent error when sending vendor bill to eTIMS

PR #102586

Enterprisesaas-18.3l10n_ke_edi_oscuMEDIUM

This update resolves an issue where sending vendor bills to eTIMS would fail due to incorrect eTIMS configuration. Specifically, the system requires the 'eTIMS Server Mode' to be set up correctly for the process to function. This change ensures the system correctly handles new company setups and prevents the error.

Original PR description

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

Forward-Port-Of: odoo/enterprise#101319

#eTIMS#Kenya#EDI

Branch: master

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] l10n_be_intrastat: add option to export Intrastat Report to XML with chosen selection

PR #102587

Enterprisemasterl10n_be_intrastatMEDIUM

This update allows users to export Intrastat reports in XML format, addressing previous limitations that caused submission issues. Previously, reports were automatically generated in a specific format, now users can select the desired format and data inclusion, ensuring accurate report submissions to OneGate.

Original PR description

**Behavior:** Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This…

The solution is to currently reenable the user to export their report to XML from a cog menu in the Intrastat Report view. While still leaving the current flow through account.return possible, until a better solution is thought of.

**Steps to reproduce:**
- Connect to a company under Belgian Localisation.
- Create a product and, under the Accounting tab, specify a Commodity code (eg Live asses) and Country of Origin (Belgium)
- Create an Invoice containing the product to a Client in another EU Country (eg Luxembourg) and under the 'Other Info' tab, specify Intrastat Countrt (Belgium) - You can choose to leave out Intrastat Transport Mode and Incoterm, this will make the resulting XML have some missing informations
- Create a Bill with the product with the same settings
- If you go to Intrastat Report, after changing the 'Report' filter to Intrastat (Goods) you will now be able to see an arrival and a dispatch. The extended mode filter is enabled by default, if you didnt fill Intrastat Transport Mode and Incoterm, you will see these missing.
- From this view there is currently no way to export the XML, to do that click the Returns button (select an Opening Date for accounting if needed), click on 'New' and specify Intrastat in the Return Type and a time window containing your Invoice and Bill.
- Then you will see an Intrastat Report show up and after selecting Review, then Submit, you will be able to download the XML. which will contain dispatches and arrivals and will be in Extended Mode. Which, if missing Transport/Incoterm, will fail when submitted to OneGate

opw-5347238

Forward-Port-Of: odoo/enterprise#102531

#Intrastat#Belgium#Export#Reporting

[Sign] Fix WhatsApp templates access on multicompany

PR #102566

Enterprisemasterwhatsapp_signMEDIUM

This update resolves an issue where WhatsApp sign requests from multiple companies were failing due to template access restrictions. The fix ensures users only see templates they are authorized to use, regardless of the company sending the request, improving the reliability of WhatsApp sign functionality.

Original PR description

Currently, WhatsApp templates are linked to the default company, causing access errors when sending sign requests from other companies.

This patch filters templates based on the user's access rights to avoid AccessErrors and clarify which templates are available per company.

task-5424781

Forward-Port-Of: odoo/enterprise#102456

#whatsapp#sign#multicompany

Branch: 17.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] account: preserve manually changed prices when changing fiscal position

PR #237914

Core17.0accountMEDIUM

This update corrects a bug where manually adjusted prices on customer invoices were being reset when the invoice's fiscal position was changed. The fix ensures that prices remain as the user set them, mirroring the behavior in Sale Orders. This improves invoice accuracy and reduces manual adjustments.

Original PR description

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a customer invoice with at least one product line.
* Manually adjust the **price_unit** on the invoice line.
* Change the fiscal position on the invoice.
* Click the **Update Taxes and Accounts** button.

**Observed behavior:**
* The manually adjusted price is reset to the product’s default sales price (e.g., 1000).
* This occurs even though neither the product nor the UoM changed.
* In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation.

**Cause:**
* `action_update_fpos_values` method call the recomputation of unit price each
  time when we click update taxes and accounts button on invoice.

**Fix:**
* Add a condition to **skip price recomputation** when fiscal position changes.
* This preserves manual prices when only the fiscal position changes.

opw-5252832

#invoice#pricing#fiscal position

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills. Steps to Reproduce: - Install `l10n_ke_edi_oscu` module without demo data. - Create a New company with `Kenya` as the Country and switch to it. - Go to Vendors > Bills, create a new bill, and add an invoice line without tax. - Confirm it, then click `Send to eTIMS`. Traceback: ```py File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill content = move._l10n_ke_oscu_json_from_move() File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details) File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines tax, line_tax_details = next( StopIteration: null ``` This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`. Here we raise a warning when the `eTIMS` configuration is not set up correctly. [1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93 sentry-7083978544 Forward-Port-Of: odoo/enterprise#101319

Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs: - Create a project A and project B, activate the top bar in both projects - Create a new custom embedded action in project A - Switch to project B (by changing the URL), the custom action of project A is present in project B - In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar. It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action. We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction". task-5269261 Forward-Port-Of: odoo/odoo#240558 Forward-Port-Of: odoo/odoo#237695

When navigating to documents from the 'Activities' systray icon, the system would load an action that correctly filtered for "My Activities" but lacked the specific view definitions of the main Documents app. This caused the 'List' view-switcher to load the default list view instead of the custom one, breaking features like document preview that depend on the custom view's JavaScript. This patch fixes the issue by ensuring that the correct, custom view definitions from the main Documents app are loaded. This guarantees that the custom list view and all its features work correctly, regardless of how the user navigates to it. This ensures the correct custom list view is loaded while preserving the "My Activities" filter. Task-5187045 Forward-Port-Of: odoo/enterprise#102442 Forward-Port-Of: odoo/enterprise#98979

**Behavior:** Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This causes issues for some users that want more specific formats like standard over extended, only arrivals/dispatches or both, etc... And this can cause them to not be able to submit their reports. The solution is to currently reenable the user to export their report to XML from a cog menu in the Intrastat Report view. While still leaving the current flow through account.return possible, until a better solution is thought of. **Steps to reproduce:** - Connect to a company under Belgian Localisation. - Create a product and, under the Accounting tab, specify a Commodity code (eg Live asses) and Country of Origin (Belgium) - Create an Invoice containing the product to a Client in another EU Country (eg Luxembourg) and under the 'Other Info' tab, specify Intrastat Countrt (Belgium) - You can choose to leave out Intrastat Transport Mode and Incoterm, this will make the resulting XML have some missing informations - Create a Bill with the product with the same settings - If you go to Intrastat Report, after changing the 'Report' filter to Intrastat (Goods) you will now be able to see an arrival and a dispatch. The extended mode filter is enabled by default, if you didnt fill Intrastat Transport Mode and Incoterm, you will see these missing. - From this view there is currently no way to export the XML, to do that click the Returns button (select an Opening Date for accounting if needed), click on 'New' and specify Intrastat in the Return Type and a time window containing your Invoice and Bill. - Then you will see an Intrastat Report show up and after selecting Review, then Submit, you will be able to download the XML. which will contain dispatches and arrivals and will be in Extended Mode. Which, if missing Transport/Incoterm, will fail when submitted to OneGate opw-5347238 Forward-Port-Of: odoo/enterprise#102531

Currently, WhatsApp templates are linked to the default company, causing access errors when sending sign requests from other companies. This patch filters templates based on the user's access rights to avoid AccessErrors and clarify which templates are available per company. task-5424781 Forward-Port-Of: odoo/enterprise#102456

**Steps to reproduce:** * Install the **Accounting** module. * Create a customer invoice with at least one product line. * Manually adjust the **price_unit** on the invoice line. * Change the fiscal position on the invoice. * Click the **Update Taxes and Accounts** button. **Observed behavior:** * The manually adjusted price is reset to the product’s default sales price (e.g., 1000). * This occurs even though neither the product nor the UoM changed. * In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation. **Cause:** * `action_update_fpos_values` method call the recomputation of unit price each time when we click update taxes and accounts button on invoice. **Fix:** * Add a condition to **skip price recomputation** when fiscal position changes. * This preserves manual prices when only the fiscal position changes. opw-5252832