Tuesday, February 17, 2026
5 changes · saas-18.4
Enhancements to existing features
This update adjusts the calculations for the CP200 seizable amount in the Belgian payroll module (l10n_be_hr_payroll). Specifically, it incorporates a new valuation (2026) and updates the relevant percentage parameters to ensure accurate payroll processing according to Belgian tax regulations. This ensures compliance and correct salary deductions for Belgian employees.
Original PR description
Update CP200 Seizable Amount Percentages salary Parameters . Add 2026 valuation task-5478481 Forward-Port-Of: odoo/enterprise#105900
This update adjusts the way Odoo handles GST e-invoices for India, switching to a new GST Suvidha Provider (GSP) configuration. This change is necessary to align with recent updates and ensure Odoo continues to comply with Indian tax regulations for e-invoicing.
Original PR description
Update the Indian localization to switch the GST e-invoice GSP (GST Suvidha Provider) configuration to a new provider as required by recent integration updates. This change ensures that GST credentials uses the new GSP configuration and aligns with updated operational requirements. Task: 5379879 Forward-Port-Of: odoo/enterprise#103984
Resolved issues and error corrections
This update fixes an issue where duplicate DateV identifiers could be assigned to partners, even after archiving. The change ensures that a unique DateV ID is always required, regardless of a partner's active status, preventing data inconsistencies. This improves data accuracy for German reporting.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update resolves a technical error that was causing a crash when creating new payroll records. The fix utilizes a standard Odoo method to handle virtual records, ensuring the payroll module functions correctly and reliably. This prevents disruptions to business processes.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303
This update resolves an issue where Odoo couldn't successfully process Fedex delivery requests due to a missing piece of information required by the Fedex API. Specifically, the system was failing with an 'INVALID' error. By adding a necessary field to the API request, we now ensure accurate delivery rate calculations and validation for Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590