Monday, April 20, 2026
10 changes · saas-18.4
Resolved issues and error corrections
The Dutch ICP report now uses the same rounding-down rule as the export files. This avoids confusing mismatches between the report and the submitted amounts, making the figures easier to trust and reconcile.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#112953
The comparison view in tax reports now works correctly even when a report line contains text instead of only numbers. This prevents the report from crashing when users compare against one past period, so they can review results without interruption.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#113330 Forward-Port-Of: odoo/enterprise#112619
This update corrects ISO20022 payment files so currencies like JPY are exported with the proper number of decimal places. It prevents bank rejections caused by amounts being formatted with two decimals when the currency should not have them.
Original PR description
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3.…
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it using the ISO20022 method on the JPY journal 4. Create a batch payment containing that payment, with Batch Type Outbound, on the JPY journal, with ISO20022 as payment method 5. Validate the batch — the XML file is generated and attached 6. Download it -> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has no decimals. The file is rejected by banks. The fix: -------- Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d: > Generating the xml file for iso20022 always generates the amount with two decimals which is hard coded and can cause error for currencies without decimals for example JPY. > The fix is to have the currency decimal number dynamically set through the currency decimal places field. opw-6103849 Forward-Port-Of: odoo/enterprise#113296
This change removes a tracking setting from a payroll field so it is no longer read too early in the employee update flow. As a result, holiday pay values are calculated at the right time and payroll tests and outputs stay accurate.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#114063 Forward-Port-Of: odoo/enterprise#113015
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114069 Forward-Port-Of: odoo/enterprise#106998
The manufacturing report now converts unit quantities correctly when products are tracked in different units of measure. This fixes incorrect totals and averages in report groupings, so production figures and cost analysis are reliable again.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#113979When a delivery is scanned using a packaging barcode, the system now correctly keeps the due date from the barcode when creating the lot. This avoids lots being created with the wrong expiration date and helps ensure inventory tracking stays accurate.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#113136
Forward-Port-Of: odoo/enterprise#112490When a subscription payment is processed through certain bank settings, the related invoice could stay marked as unpaid even though the payment succeeded. This fix ensures the invoice is properly matched with the payment so customers and teams see the correct payment status.
Original PR description
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even…
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even though the payment transaction is 'done'. This type of configuration is usually done when users want to skip the bank reconciliation process, and just create payments without the need to reconcile the payments with transactions. Steps to reproduce: - In Settings, under Sales > Invoicing, disable Automatic Invoice - Activate demo payment method - In the main Bank account add the default account as outstanding account for demo payment method. - Create a sales order with a subscription product - Open Preview - Pay - Go back to the sales order and open the created invoice Issue: The invoice is created and the payment is registered, but the invoice remains 'Not Paid'. Analysis: The invoice and the payment move lines are not automatically reconciled during the post-processing of the transaction, leaving the invoice unbalanced. opw-5869303 Forward-Port-Of: odoo/enterprise#110656
This update prevents Documents files from being disrupted when a sign template is created or deleted. It also keeps signature requests correctly linked back to the original document even when multiple templates are created from the same file.
Original PR description
Steps to reproduce: Bug 1 (The Crash): 1. Open Documents app, select a PDF, and click Action > Sign. 2. In the Sign app, delete the newly created Sign Template. 3. Return to the Documents app. 4. A…
Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.
Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.
Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI.
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.
Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.
Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.
Task: 5432116
Forward-Port-Of: odoo/enterprise#113167This update corrects the account reference used in the Luxembourg FAIA XML export so it matches the format expected by the tax report. It helps ensure exported invoices and purchase documents are accepted consistently and reduces the risk of reporting errors.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113455