Thursday, February 12, 2026
7 changes · saas-18.4
Enhancements to existing features
This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest requirements from the BOE (Boletín Oficial de la Elección). Specifically, it incorporates changes related to Modelo 347, a key Spanish tax form, and includes a placeholder for subsidy numbers. This update is crucial for accurate tax reporting in Spain.
Original PR description
reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347 As we do not have anything for the subsidy number, we just put 6 0s. opw-5926624 Forward-Port-Of: odoo/enterprise#107125
Resolved issues and error corrections
This update fixes an issue where multi-employee payslips were defaulting to the language of the first employee. The change ensures that each employee's payslip is printed in their correct, selected language, improving accuracy and user experience. This resolves a previous bug related to date formatting and caching.
Original PR description
Steps to detect the bug: - Install payroll - Create more than one employee with different payslip languages - Add a contract for the employees - Payroll -> Payslip -> Pay run - Create a new payroll for more than one employee - Select all the employees in the pay run - Click 'print' button - Dates for the employees that are not the first one are in the language of the first employee This commit will allow the user to create multiemployee payslips maintaining the correct selected payslip language for each one of them. The issue was caused by a cache dictionary that used only the date and date format as a key, failing to include the user language. This led the system to reuse the first translated date for all subsequent employees. opw-5865260
This update resolves two critical issues impacting payroll calculations and reporting for Hong Kong. Specifically, it corrects a mistake in how taxable salary deductions are handled and ensures that rental allowances are not incorrectly included in IRD reports, aligning with Hong Kong's tax regulations.
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#107136 Forward-Port-Of: odoo/enterprise#100842
This update resolves a bug in the POS Restaurant Preparation Display module where incorrect order quantities were sometimes sent to the kitchen. The fix ensures the system waits for quantity updates before submitting orders, preventing errors that caused test failures and potential inaccuracies in kitchen orders. This improves order accuracy and reliability.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We are waiting for the orderline to be updated with the correct quantity before submitting the order. X-original-commit: 5ebd1ca99dddbbc62aff90202491562114c0c0dc Forward-Port-Of: odoo/enterprise#106600
This update adjusts the calculation for sickness relapse periods in the Belgian payroll module. Starting January 1, 2026, the allowed period between sick leave occurrences to be considered a relapse has increased from 14 to 56 days. This change aligns with updated Belgian tax regulations and ensures accurate payroll reporting.
Original PR description
Spec :- Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. Implementation :- . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add leave work_entry type where work_entry use date_start . Add corresponding tests task-5476174
This update resolves a bug that prevented invoices with lines having a product price of zero in the Mexican (MX) edi format from being saved. The fix ensures that required tax object fields are correctly populated, allowing invoices to be properly generated and processed. This improves the reliability of invoice creation for MX clients.
Original PR description
**PROBLEM** If you create an invoice, and add a line with a product with a price of 0, you cannot save the invoice. **STEP TO REPRODUCE** 1. On a mx company, create an invoice for a mx client. 2. Add a line with a product with a price of 0. 3. Try saving the invoice, it will fails. **CAUSE** Field `l10n_mx_edi_tax_object` is required on invoice line with mx company. However, for lines with a price of 0, it is not set by `_compute_l10n_mx_edi_tax_object` because `_l10n_mx_edi_cfdi_invoice_line_ids()` filters them. opw-5402045
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, resulting in an inaccurate disposal date. This ensures disposal dates align with the intended disposal date.
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