Daily updates from Odoo
Thursday, February 12, 2026
11 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 the system incorrectly linked bank statement lines to the 'ODOO' partner. The change ensures that statement lines are now correctly associated with the appropriate partner, improving data accuracy and reporting. This resolves a potential error in how the Odoo bot was retrieving partner information.
Original PR description
When the partner_name was "ODOO" the retrieve partner was linking the statement line to OdooBot. no task id Forward-Port-Of: odoo/enterprise#106879
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
A test for the Shiprocket delivery module was failing due to a default pricelist being applied, which incorrectly inflated the total order amount. This fix ensures the test accurately reflects the expected tax calculation, preventing future issues with pricing.
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#105180This 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 addresses a problem with our report testing process related to a temporary build environment (faketime). The report filter was malfunctioning due to how faketime interacts with the date filtering system. This fix ensures reports are tested correctly and avoids disruptions to the overall system.
Original PR description
Faketime doesn't integrate well with our current version of the report date filter. JS date is not frozen, so the filter misbehaves. It's working OK for all other builds. Future versions (19.2+) will probably have another version of the filter which should have a different implementation, solving the problem in another way. Reworked and backported from: odoo/enterprise#101689 Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#106172
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
This update fixes an issue preventing valid Zengin bank statement files from importing correctly. The validation process has been expanded to allow a wider range of characters, including standard hyphens and alphanumeric text, aligning with the Zengin specification. This ensures all valid bank statement files can now be imported into Odoo.
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