Thursday, February 12, 2026
11 changes · saas-18.3
Enhancements to existing features
This update enhances the handling of Romanian tax invoices (e-invoices) by automatically downloading the official PDF version from the ANAF. Previously, only XML data was imported, lacking a visual invoice for accountants to review. Now, the PDF is the primary attachment, improving accuracy and compliance.
Original PR description
### Before For bills from the Romanian ANAF we only downloaded an XML and imported the data. There is no visual aid for the accountant to see and compare the received document. ### Now We use the ANAF service to get the official "PDF" version of the invoice. This is requested for any new bill we get through ANAF that doesn't already contain a pdf from the vendor and it is set as the main attachment. task-5877171 Forward-Port-Of: odoo/odoo#247382
This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest requirements from the BOE (Agencia Tributaria) regarding the Modelo 347. A change was made to the export format to align with a recent regulatory update (BOE-A-2025-25390), and a placeholder is used 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 resolves a bug that prevented users from sending invoices via PEPPOL, resulting in a 'You cannot remove parts of the audit trail' error. The fix ensures attachments are correctly handled during the PEPPOL invoice sending process, allowing invoices to be sent without interruption. This improves the reliability of the PEPPOL integration for our business customers.
Original PR description
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an…
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an invoice: * Customer: [a Belgian customer with VAT] * Invoice Lines: [a line with a tax] - Confirm the invoice - Send the invoice via PEPPOL **Issue:** A UserError is raised: "You cannot remove parts of the audit trail.". **Cause:** The audit trail prevent modifying an attachment. When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment. During the process, "res_model" and "res_id" fields of the attachments are set to the message record. Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error. However, it fails because the value is still in cache. **Solution:** Invalidate these fields as it is done when sending the invoice without PEPPOL. https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20 opw-5916696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248220 Forward-Port-Of: odoo/odoo#247949
This update corrects a bug in the self-order mobile experience where the 'Send To Kitchen' button remained visible after an order had already been processed. The fix ensures the system accurately reflects the order's status, preventing unnecessary button displays and improving the user flow. This enhances the efficiency of kitchen staff.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table Issue : “Send To Kitchen” Button Visible even order in kitchen --------------- Steps to Reproduce: 1. Open the Restaurant 2. Place a order from mobile menu and select a table. 3. In the Restaurant UI: - Open that table. The "Send To Kitchen" button is still visible even though the order was already sent to the kitchen and printed. Cause: - In self-order mode the order is not automatically synced after being sent to the kitchen and print. - As a result, the system still treats it as unsent, leaving the Order button visible. Fix: - Added getLastOrderPreparationChange() method to extract current order state and send it with the RPC request after order is saved, ensuring last_order_preparation_change updated Task-5106704 Related PR-https://github.com/odoo/enterprise/pull/106979
This update resolves a test error that was causing orders to be incorrectly marked as finalized in certain accounting scenarios. The fix adds a brief delay to ensure all order processing steps are completed before validation, preventing the 'already finalized' error. This ensures consistent order handling.
Original PR description
The `test_point_of_sale_custom_tax_with_extra_product_field` test does a `PaymentScreen.clickInvoiceButton()` and then directly after that a `PaymentScreen.clickValidate()`. In l10n scenarios, the logic behind triggering the `toInvoice` field can take longer. This would cause the validation to execute before the `toggleIsToInvoice` finishes executing and then it would throw an error that the order was already finalized. This PR ads an extra wait on the `Invoice` button to make sure that the toggle is executed properly before finalizing the order. Runbot Error: [233024](https://runbot.odoo.com/odoo/runbot.build.error/233024) Task: [5897371](https://www.odoo.com/odoo/project/1737/tasks/5897371) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248191
This update ensures that pricelists correctly apply to event products within the Point of Sale (PoS) system. Previously, event products weren't recognizing pricelists, leading to incorrect pricing. This fix resolves this issue, guaranteeing accurate pricing for event tickets during PoS transactions.
Original PR description
Before this fix, pricelist didn't take effect on event products. How to reproduce : 1. Create a pricelist with fixed price and make it available for a pos. 2. Open a pos with event products. 3. Make an orderline with an event product 4. Apply a pricelist on it. The solution is to override setPricelist() in pos_event. Which is called when we apply a pricelist to an order. task: 5092613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where the self-order page would freeze if local data was corrupted. Now, users receive an error message and can easily clear their data and refresh, particularly helpful on mobile devices. This enhances usability and prevents frustrating downtime.
Original PR description
Inconsistent data in the localDB or local storage can cause the pos_self_rder to fail before it can get initialized. When this happens the page just stays white. Now when an error happens while initializing an error message will show up and give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246925
This update corrects a bug where loyalty points were incorrectly calculated and duplicated after saving a POS order, particularly when adding products. The fix ensures that loyalty points are accurately reflected, preventing over-rewarding of customers. This improves the reliability of the loyalty program within the Point of Sale system.
Original PR description
Step to reproduce: - have a trusted pos and a loyalty program which gives points per $ spent - start pos and select order and a partner (he should already have some LPs) - notice the loyalty points…
Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order
Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50, product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250
Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state
Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
opw-5609964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248077
Forward-Port-Of: odoo/odoo#245400This update corrects a bug in the self-order mode where the 'Send to Kitchen' button remained visible even after an order had been processed and printed. The fix ensures the system accurately reflects the order's status, preventing confusion and improving the user experience for kitchen staff. This update ensures orders are correctly marked as complete.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table Issue : “Send To Kitchen” Button Visible even order in kitchen --------------- Steps to Reproduce: 1. Open the Restaurant 2. Place a order from mobile menu and select a table. 3. In the Restaurant UI: - Open that table. The "Send To Kitchen" button is still visible even though the order was already sent to the kitchen and printed. Cause: - In self-order mode the order is not automatically synced after being sent to the kitchen and print. - As a result, the system still treats it as unsent, leaving the Order button visible. Fix: - Added getLastOrderPreparationChange() method to extract current order state and send it with the RPC request after order is saved, ensuring last_order_preparation_change updated Task-5106704 Related PR-https://github.com/odoo/odoo/pull/247969
This update fixes errors in how Hong Kong payroll taxes are calculated, specifically preventing incorrect deductions for ERMPF and ensuring IRD reports accurately exclude rental allowances. These changes ensure compliance with Hong Kong tax regulations and improve the accuracy of financial reporting.
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 corrects an issue where asset depreciation reports incorrectly showed assets after they had been disposed of. The fix ensures that disposal dates are accurately reflected, preventing misleading reporting and improving financial data accuracy. The change was triggered by a bug in how the system calculated disposal dates.
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