Odoo Changelog — 2026-03-26

Thursday, March 26, 2026

5 changes · saas-18.2

Bug Fixes(5)

Resolved issues and error corrections

[FIX] account_reports: use locale decimal separator in external value pop up

PR #111997

Enterprisesaas-18.2account_reports

This update ensures the external value pop-up displays numbers using the correct decimal separator based on the user's language settings. Previously, it always used a dot, which could cause confusion for users in regions that use a comma as a decimal separator. This change improves the user experience and data clarity.

Original PR description

Description of the issue this commit addresses:

The external value pop up doesn't take into account the locale to chose which decimal separator to use.

---

Desired behavior after this commit is merged:

The decimal separator is the one determined by the language of the user rather than always a dot.

---

task-6010533

Forward-Port-Of: odoo/enterprise#109948

#localization#reporting#user experience

[FIX] l10n_cl_edi_factoring: translation issue

PR #111843

Enterprisesaas-18.2l10n_cl_edi_factoring

This update resolves a problem where translations were failing to load correctly for the Chilean VAT reporting module. The change converts a complex list comprehension to a standard for loop, ensuring accurate translation context is used. This issue was primarily observed on Ubuntu Jammy and Debian Bookworm operating systems.

Original PR description

This commit transforms the list comprehension into a regular for loop to
avoid the translation missing context when looking up for lang.

Note: the issue appeared more specifically on Ubuntu Jammy and Debian
Bookworm.

runbot-240951

Forward-Port-Of: odoo/enterprise#111147

#translation#Chile#VAT

[FIX] l10n_us_hr_payroll: fix rate display for tiny overtime hours

PR #111586

Enterprisesaas-18.2l10n_us_hr_payroll

This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous successful implementation for Australia, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reporting.

Original PR description

The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate.

For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation:

$26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06

We then attempted to calculate the rate in reverse for the PDF:

$0.06 / 0.00166667 hour = $35.9999 ≈ $36.00

Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5).

We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia.

task-6052711

Forward-Port-Of: odoo/enterprise#111540

#payroll#overtime#US

[FIX] quality_control: correct demand split on partial failure

PR #112005

Enterprisesaas-18.2quality_controlMEDIUM

This update fixes an issue where stock moves weren't correctly split when a quality control check resulted in a partial failure. Specifically, the system was incorrectly calculating the demand quantity for the failed stock. This ensures accurate stock accounting and reduces the risk of over- or under-stocking due to quality control processes. The fix ensures the correct quantity is moved to the failure location.

Original PR description

**Observed behavior:**
* A new stock move is created for the failed quantity.
* The original move is split incorrectly:
* First move: 2 `product_uom_qty` and 2 `quantity`.
* Second move: 2 `product_uom_qty` and 3 `quantity`.
* The failed move has a demand of **2** instead of **3**.

**Cause:**
* Clicking on *Quality Check* triggers `check_quality`,
which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82
* Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88
* Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97
* In `_move_line_to_failure_location`, a new stock move
is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480
* The demand quantity is computed using the minimum of the
failed quantity and the move line quantity.
* This leads to an incorrect demand of *2* instead of *3*.
* However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472

**Fix:**
* Ensure that partial failures properly split stock moves with
correct `product_uom_qty` and `quantity` values.

---

opw-5492095

Forward-Port-Of: odoo/enterprise#107493

#quality control#stock#inventory

[FIX] product_barcodelookup: prevent duplicated product to be published

PR #111986

Enterprisesaas-18.2product_barcodelookup

This update fixes an issue where duplicating a product template automatically published it. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data accuracy and simplifies product management.

Original PR description

Issue:
---
Duplicate product template creates a published product which is not
expected. Duplicated products should be unpublished by default.

#### Steps to reproduce:
1- Create a product and add a eCommerce category.
2- Without publishing the product duplicate it.

Even though the original product is not published, the duplicated one
is published.
Expected: Regardless of published state of original product, the
duplicated product should not be published.

Cause:
---
This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published`
product if `public_categ_ids` is set. However this was only supposed
to be when creating a new product using form. It makes the create
to ignore `is_published` default value even in copy.

Fix:
---
We can make sure if `is_published` is in create vals, don't force
`is_published` to be set True.

However, as `copy=False` in `is_published` field definition, it
won't be in vals in copy. By overriding `copy_data`, we can ensure
vals is present in copy.

#### Note:
`product_barcodelookup` doesn't depend on `website_sale`. However,
`product_categ_ids` is used in this module. In the test for the
same case we only run the test if the module is installed.
This would be fine as this is a post-install test.

opw-6014789

Forward-Port-Of: odoo/enterprise#111340

#product#template#publication

Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#109948

This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951 Forward-Port-Of: odoo/enterprise#111147

The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711 Forward-Port-Of: odoo/enterprise#111540

**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095 Forward-Port-Of: odoo/enterprise#107493

Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#111340