Odoo Changelog — 2026-02-12

Thursday, February 12, 2026

8 changes · saas-18.2

Bug Fixes(8)

Resolved issues and error corrections

[FIX] l10n_hk_hr_payroll: Taxable salary and RA

Enterprisesaas-18.2l10n_hk_hr_payrollMEDIUM

This update resolves two errors impacting Hong Kong payroll reporting. Specifically, it corrects a calculation mistake that incorrectly deducted ERMPF from taxable salaries and ensures that rental allowances are not included in IRD reports, aligning with Hong Kong's specifications. This ensures accurate tax reporting and compliance.

Original PR description

Fixes two issues related to computations;
The taxable salary wrongly deduce the ERMPF which it should not.
in the IRD reports, the total income includes the rental allowances, which is wrong according to their specs.

task-5353781

Forward-Port-Of: odoo/enterprise#100842

#payroll#tax#Hong Kong#compliance

[FIX] delivery_shiprocket: force empty pricelist in test

PR #106976

Enterprisesaas-18.2delivery_shiprocket

A test for the Shiprocket delivery module was failing due to a default pricelist being applied, which incorrectly calculated taxes. This fix ensures that the pricelist is cleared during testing, allowing for accurate tax calculations and reliable test results. This resolves a discrepancy in the reported order total.

Original PR description

Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
    self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`

Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.

-----
Error runbot 232692

Forward-Port-Of: odoo/enterprise#105180

#shiprocket#taxes#testing

[FIX] sign: check for chatter when displaying sign menu item

PR #97401

Enterprisesaas-18.2sign

This update ensures the 'Request Signature' menu item appears correctly on form views when a chatter is present. Previously, the system inconsistently checked for chatter, leading to the item sometimes being missing. This fix guarantees the menu item is displayed as expected for users with chatter functionality.

Original PR description

****Behavior:****

**Current:**
When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent.

**Solution:**
On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry.

**Steps to reproduce:**
From Timesheets:
- Go to Timesheets
- Open a task
- The cog menu will not contain "Request Signature"

From Project:
- Go to Project
- Select a project and open a task
- The cog menu will contain "Request Signature"

opw-4817423

#UI#Signatures#Chatter

[FIX] timesheet_grid: widget not used in aggregate of list view after refresh

PR #107203

Enterprisesaas-18.2timesheet

This update fixes an issue where the total time on timesheets displayed in the list view was incorrectly formatted as a regular number instead of a time. The fix ensures that the total time is consistently displayed correctly after refreshing the list view, improving the accuracy of timesheet reporting.

Original PR description

# Steps to reproduce
- Open Timesheets
- Go to list view
- Refresh page
- Total is formatted as regular float instead of time

# Cause of the issue
The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget.

Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`).

We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh.

task-5907954

Forward-Port-Of: odoo/enterprise#107006

#timesheet#reporting#formatting

[FIX] account_reports: consider inactive accounts in accounts coverage report

PR #107227

Enterprisesaas-18.2account

This update fixes an issue where the Accounts Coverage Report incorrectly flagged deprecated accounts as missing. The change removes a filter that excluded these accounts, ensuring the report accurately reflects the company's financial data. This improves the report's reliability and accuracy.

Original PR description

Purpose: Accounts Coverage Report considers only active accounts and deprecated accounts are excluded(which should be included).

Steps to reproduce:-
- Switch to company with Belgian COA.
- Open form view of P&L report and click on Accounts Coverage Report.
- Coverage report raises error message that account 667 is reported but does not exist in COA.
- Create an expense account with code 667000 arbitrarily.
- Coverage report does not raises above error.
- Now deprecate 667000 account.
- Coverage report again raises error that account 667 is reported but does not exist in COA.

Solution: remove `('deprecated', '=', False)` from domain.

task- 5906024

Forward-Port-Of: odoo/enterprise#107183
Forward-Port-Of: odoo/enterprise#107085

#reporting#accounts#deprecated

[FIX] account_asset: exclude cancelled moves from disposal date

PR #107193

Enterprisesaas-18.2accountMEDIUM

This update fixes an issue where assets incorrectly appeared in depreciation reports after being disposed of. The system was taking the latest date from all depreciation moves, including cancelled ones, leading to an inaccurate disposal date. This ensures asset depreciation reports accurately reflect disposal events.

Original PR description

**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Audit Trail" - Go to "Accounting / Accounting / Management / Assets" - Create an asset: * Original Value: [any] *…

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

#asset management#depreciation#accounting

[FIX] l10n_jp_zengin: special characters shd be allowed to import

PR #107215

Enterprisesaas-18.2l10n_jp_zengin

This update fixes an issue preventing correct import of Zengin accounting files. The validation process now allows a wider range of characters, including standard hyphens and alphanumeric text, aligning with the Zengin specification. This ensures all valid Zengin files can be imported without errors.

Original PR description

Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text.

This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include:
- Uppercase alphanumeric characters (A-Z, 0-9)
- Standard symbols (e.g., -, ., /, (, ), etc.)

Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite

task-5928087

Forward-Port-Of: odoo/enterprise#107007

#accounting#japan#zengin

[FIX] l10n_co_{dian,edi}: correct invoice date range validation

PR #107255

Enterprisesaas-18.2l10n_co_dianl10n_co_ediMEDIUM

This update fixes an issue where invoices sent to DIAN or Carvajal were incorrectly flagged with a warning if the invoice date was within a specific range. The validation logic has been adjusted to align with Colombian regulations, allowing invoice dates up to 6 days before and after the current date, ensuring accurate electronic invoicing.

Original PR description

Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…

Currently, an `incorrect warning` message is shown when sending an invoice to
`DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1] and [2], the allowed invoice date range is incorrectly computed, using
`5 days in the past` and `10 days in the future`. This does not match the Colombian
regulations and triggers incorrect validation errors for valid invoice dates.

These checks are intentionally implemented in both modules because they apply
at different stages and for different providers:
1) `l10n_co_dian`
When `DIAN: Free service` is selected as the `Electronic Invoicing Provider`
from the `Invoicing Settings`, the date constraint is evaluated at `send time`.
After the invoice is created, the validation is performed when the user sends
the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the
invoice date is outside the allowed range.

2) `l10n_co_edi`
When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same
rule is checked `at the confirmation time` of the draft invoice. In this case,
the validation results in a `chatter message`, not a blocking send-time error.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to
`6 days before and 6 days after` the current date, in accordance with the
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados,
page 59, at [2].

[1]:
https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679

[2]:
https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

Forward-Port-Of: odoo/enterprise#105763

# invoicing#DIAN#electronic invoicing#Colombia

Fixes two issues related to computations; The taxable salary wrongly deduce the ERMPF which it should not. in the IRD reports, the total income includes the rental allowances, which is wrong according to their specs. task-5353781 Forward-Port-Of: odoo/enterprise#100842

Issue ----- `File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts self.assertAlmostEqual(sale_order.amount_total, 55) AssertionError: 32.0 != 55 within 7 places (23.0 difference) ` Cause ----- Test fails because a pricelist gets applied by default and overrides the taxes. ----- Error runbot 232692 Forward-Port-Of: odoo/enterprise#105180

****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423

# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107006

Purpose: Accounts Coverage Report considers only active accounts and deprecated accounts are excluded(which should be included). Steps to reproduce:- - Switch to company with Belgian COA. - Open form view of P&L report and click on Accounts Coverage Report. - Coverage report raises error message that account 667 is reported but does not exist in COA. - Create an expense account with code 667000 arbitrarily. - Coverage report does not raises above error. - Now deprecate 667000 account. - Coverage report again raises error that account 667 is reported but does not exist in COA. Solution: remove `('deprecated', '=', False)` from domain. task- 5906024 Forward-Port-Of: odoo/enterprise#107183 Forward-Port-Of: odoo/enterprise#107085

**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Audit Trail" - Go to "Accounting / Accounting / Management / Assets" - Create an asset: * Original Value: [any] * Acquisition Date: [in the past] (e.g. 01/01/2025) * Duration: [at least until today] (e.g. 36 Months) * Depreciation Account: [any] * Expense Account: [any] - Confirm the asset - Modify Depreciation: * Action: Dispose * Date: [in the past] (e.g. 30/10/2025) * Loss Account: [any] - Dispose - Go to "Accounting / Reporting / Management / Depreciation Schedule" - Filter on a period after the disposal date **Issue:** The asset appears in the selected period even if it has already been disposed. **Cause:** There are posted depreciation moves that have a date after the disposal date. These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead. However, the disposal date computed on the asset is taking the max date from all the depreciation moves. Even the cancelled ones ; leading to a disposal date different than the one entered. opw-5225749 Forward-Port-Of: odoo/enterprise#107028

Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087 Forward-Port-Of: odoo/enterprise#107007

Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [2]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#105763