Daily updates from Odoo
Thursday, May 7, 2026
12 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where commission plans with negative target values caused a system error. The fix ensures the commission plan generation process can handle negative targets correctly, preventing errors and improving the flexibility of commission plan configuration. This change enhances the reliability of sales commission calculations.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines during reconciliation was addressed. Now, the balance is consistently shown, regardless of the number of lines or currencies involved.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update resolves an issue where the Mod 349 tax report incorrectly excluded vendor bills with amounts less than 1 Euro. The fix adjusts a calculation to ensure these small amounts are properly displayed, improving the accuracy of tax reporting for Spanish businesses. This ensures compliance and accurate financial data.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#116102 Forward-Port-Of: odoo/enterprise#114776
This update resolves an issue preventing users from modifying warehouse routes in the Romanian (RO) version of Odoo. The fix addresses a bug where an error occurred when changing routes, blocking modifications. This ensures multi-step routes can be updated without disruption.
Original PR description
### Issue: When changing the routes of a Romanian warehouse, an error is raised, blocking any modification of multi-step routes ### Cause: The code attempts to access `in_type_id` from `warehouse_data` However, when updating routes, `warehouse_data` is empty in the method `_create_or_update_sequences_and_picking_types` This leads to a crash because the code assumes that `warehouse_data` always contains `in_type_id` and `out_type_id` Additionally, even if the data were present, it would result in creating duplicate `stock.picking.type` records ### Steps to reproduce: - Install `l10n_ro_saft_stock` with demo data and switch to `RO Company` - Enable `Multi-steps Routes` in Settings - Try to modify Incoming or Outgoing Shipments on a warehouse - When saving, the following error is raised: "Oh snap! in_type_id" odoo-pr: https://github.com/odoo/odoo/pull/257293 opw-5925087 Forward-Port-Of: odoo/enterprise#114166
This update resolves a crash that occurred when preparing online food delivery orders scheduled for the future. The issue stemmed from an incorrect date format, which has now been corrected to ensure smooth order preparation workflows. This improves the reliability of our delivery system for online food orders.
Original PR description
### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176) Forward-Port-Of: odoo/enterprise#108298
This update fixes a minor accounting error related to the reversal of source tax (QST) calculations in Odoo's Swiss payroll module (l10n_ch_hr_payroll). The change ensures accurate tax reporting by correctly calculating and reversing the minimum IS (Incentive Scheme) amount, improving financial compliance.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update ensures that all public holidays, including those without associated working schedules, are now correctly included in the SD Worx report. Previously, the system missed these holidays, leading to inaccurate payroll calculations. This fix improves the accuracy of payroll reporting for Belgian businesses.
Original PR description
### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070 Forward-Port-Of: odoo/enterprise#114900
This update resolves a bug that caused Odoo to crash when creating Point of Sale (POS) orders with the Avatax module installed. The fix restores a previous method to correctly identify the customer's shipping information, ensuring POS order creation functions smoothly. This improves the reliability of the POS system for our users.
Original PR description
Before this commit, when pos_avatax was installed, creating a pos order could crash because the pos order does not have the partner_shipping_id field. This commit re-adds the _get_avatax_ship_to_partner method as it was before the refactor https://github.com/odoo/enterprise/commit/0404086db567ee0595414263d36a3b7dceaa0dbe, which returns the partner_id for the pos order. The `_get_avatax_ship_to_partner` is overridden in `pos_avatax`. Since a `pos.order` does not have a `partner_shipping_id`, the overridden function only reads the partner_id. opw-6122280
This update resolves a problem that prevented correct submission of Dutch VAT returns (SBR) when using multiple companies within a single VAT unit. The fix ensures the system only uses the correct closing entry, preventing errors and improving the reliability of the SBR process. This impacts users who utilize Odoo's multi-company/multi-branch accounting.
Original PR description
In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process. When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)` This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group. This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic. Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1 opw-6106081 Forward-Port-Of: odoo/enterprise#116237
This update resolves an issue where DIAN XML files (AttachedDocument type) were not being imported correctly, leading to data loss. The fix ensures the system correctly identifies and processes these files, aligning with DIAN documentation and allowing for accurate data extraction.
Original PR description
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN…
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf However, no strict validation is enforced, so variants should still be supported ### Cause: When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:` This causes issues with documents structured like: ```xml <AttachedDocument> <CustomizationID>Documentos adjuntos</CustomizationID> <ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID> </AttachedDocument> ``` In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian` As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document ### Steps to reproduce: - Install `l10n_co_dian` - Go in Bills and import the test document: `import_attached_document_2` Before the fix, nothing it extracted from the xml opw-6083523
This update fixes a limitation in how Odoo updates its UNSPSC product codes. Previously, new codes could only be added during initial installation, not subsequent updates. A new upgrade script now automatically adds the latest UNSPSC codes to the database, ensuring our product data remains current. Existing product codes are not modified.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
This update resolves an error that occurred when the Account Followup module was installed without the Payment module. The fix prevents a template rendering issue caused by attempting to access a missing 'payment.method' field, ensuring payment reminders function correctly.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116443 Forward-Port-Of: odoo/enterprise#116079