Friday, February 20, 2026
13 changes · saas-18.4
Resolved issues and error corrections
This update resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly shown, which has now been corrected by adding a new field to the model. This ensures the correct display of offer information for Belgian employees.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488 Forward-Port-Of: odoo/enterprise#107755 Forward-Port-Of: odoo/enterprise#104578
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated as part of a larger change in 17.3 to consolidate previous week/month actions. This ensures the approval reminder email functions correctly, sending to the appropriate timesheet records.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
This update corrects a technical issue related to the transmission of 13th month payroll data for Swiss clients using the LPP (Lump-Sum Payment) base. The change ensures accurate reporting and compliance with Swiss tax regulations, specifically addressing a requirement for including the 13th month payment in the LPP calculation.
Original PR description
Forward-Port-Of: odoo/enterprise#107908
This update resolves an issue where Invoicing and Banks users were unable to access key financial reports. The change adds necessary security permissions, allowing these groups to view basic reports like partner ledger and aged receivable/payable, improving their ability to manage financial data.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#107851 Forward-Port-Of: odoo/enterprise#107654
This update resolves an issue where tasks remained linked to sales orders even without associated order items, preventing users from properly billing tasks. The change ensures tasks can be cleanly detached from sales orders when no items are linked, streamlining billing processes and improving task management. This fix maintains the ability to add materials to existing sales orders for field service tasks.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#107716 Forward-Port-Of: odoo/enterprise#103487
This update resolves an issue preventing accurate report generation within the l10n_au_hr_payroll_account module. The change adjusts the report domain to use .ids instead of NewId, ensuring the reports correctly identify payroll records. This improves the reliability of financial reporting.
Original PR description
Domains do not support NewId, so we change the report domain to call .ids instead. [Runbot Error - 115303](https://runbot.odoo.com/odoo/error/115303)
This update resolves an issue where users could inadvertently assign partners from different companies when managing multiple companies. The change ensures that partners are correctly associated with the intended company, improving data accuracy and streamlining accounting processes. This fix enhances the reliability of financial reporting across our enterprise solutions.
Original PR description
Before this commit, it was possible to add a partner that was from another company when multiple companies were selected. task-5941113 Forward-Port-Of: odoo/enterprise#107546
This update fixes an issue where OCR-extracted expense amounts weren't correctly converting to the company's standard currency (USD). The change ensures that the 'Total' amount accurately reflects the original receipt total after applying the correct exchange rate, improving the accuracy of expense reporting.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. The issue was caused by missing data in the search field, which blocked the search bar from returning results. Now, all journal entries are searchable by move, partner, account, and label.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update corrects a discrepancy in payslip calculations related to the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107576 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue preventing early bill printing with the Italian fiscal printer. The fix addresses a traceback caused by incorrect data handling during the printing process, ensuring receipts are now printed correctly when the 'early print' option is enabled. This improves the restaurant's ability to efficiently manage and print customer bills.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#107720
Forward-Port-Of: odoo/enterprise#105511This update fixes a compatibility issue with the Dutch tax (OB) and ICP report templates. It replaces outdated taxonomy data with the final 20251210 NT20 taxonomy, ensuring successful processing of these reports by the Digipoort system. This ensures accurate reporting for Dutch tax compliance.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries with excessively large negative hour values (over six digits) are now properly flagged as errors. Previously, these entries could be added without warning, leading to potential data inaccuracies. This fix maintains data integrity by enforcing consistent hour limits across all timesheet entries.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781