Odoo Changelog — 2025-12-30

Tuesday, December 30, 2025

7 changes · 18.0

Bug Fixes(7)

Resolved issues and error corrections

[FIX] point_of_sale: correctly add the scanned product

Core18.0point_of_sale

This update fixes an issue where scanning invalid GS1 barcodes in Point of Sale could incorrectly load products. Previously, scanning a barcode like '0000' would lead to the first product containing '0' in its barcode being loaded. This change ensures that only valid barcodes correctly identify and add the intended product to the sale.

Original PR description

Before this commit, when GS1 barcode was set in the company settings, scanning an invalid barcode may load a wrong product. For example, if the barcode "0000" was scanned, and it would search for all products that contains "0" in their barcode, and load the first one found.

opw-5394561

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#barcode#pos#product

[FIX] point_of_sale: convert standard price

PR #241168

Core18.0point_of_saleMEDIUM

This update fixes an issue where product prices in Point of Sale weren't correctly calculated when using different currency settings. The change ensures standard prices are converted to the PoS currency, preventing incorrect pricelist calculations and ensuring accurate order totals. This improves the reliability of sales transactions.

Original PR description

The standard price of the products were not converted to the currency of the PoS journal, which could lead to issues when creating pricelist items based on the standard price.

Steps to reproduce:
-------------------
* Change the currency of any PoS journal to a different currency than the company currency.
* Create a product with a standard price > 0.
* Create a pricelist that uses the standard price as a base price. (e.g. price = standard price * 2)
* Add this product to a PoS order
> Observation: The price is not correctly computed according to the
  pricelist, because the standard price was not converted to the PoS currency.

Why the fix:
------------
We just make sure to convert the standard price of the products when loading the products in the PoS session the same way as we do it for the list price.

opw-5124388

#pricing#currency#pos

[FIX] l10n_mx_edi: Fix predial account regex

PR #102981

Enterprise18.0l10n_mx_ediMEDIUM

This update addresses a requirement from the Mexican tax authority (SAT) regarding the format of the ‘CuentaPredial’ field in Odoo’s Mexican tax reports. The previous regex was too restrictive, preventing valid account numbers from being processed. This change ensures compliance with SAT regulations and accurate tax reporting.

Original PR description

SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node

Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd

#Mexico#Tax#SAT#CFD

[FIX] l10n_be_hr_payroll: fix traceback when creating a payslip

PR #99217

Enterprise18.0l10n_be_hr_payroll

This update resolves an issue that prevented users from creating payslips for contracts without a defined working schedule in the Belgian payroll system. The fix ensures that the system now defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a traceback error. This improves the reliability of payslip generation.

Original PR description

Currently, a traceback occurs when a user tries to create a payslip for a contract 
that has no working schedule in a Belgian company.

**Steps to reproduce this issue:**

1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 
2) Create an employee with no working hours.
3) Create a contract for that employee with:
   - Work entry source as Attendance
   - No Working Schedule
   - State should be open/running 
4) Click the Payslip smart button to create a new payslip for that contract. 
5) A traceback occurs

**Error:**
```
ValueError: Expected singleton: resource.calendar()
```
**Cause:**
When creating a payslip for a contract with no resource_calendar_id, 
the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` 
through self.resource_calendar_id. Since the contract's calendar lacks a 
resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472

**Solution:**
If the contract or employee does not have a resource_calendar_id, 
use the default resource_calendar_id from the company instead.

opw-5237559

#payroll#belgium#hr#contract

[FIX] mail: fix race condition in partner suggestion sort test

PR #241619

Core18.0mail

This update resolves a sporadic test failure related to how partner suggestions are sorted, specifically when messages are sent. The fix ensures the test accurately reflects the system's data by waiting for the necessary updates to complete before verification, preventing incorrect sorting results.

Original PR description

Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition.

This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3").

This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order.

runbot-237553

#testing#suggestions#sorting

[IMP] l10n_dk_nemhandel: invoice with discount

PR #241614

Core18.0l10n_dk_nemhandelMEDIUM

This update resolves an issue where Odoo invoices with discounts generated for Nemhandel couldn't pass validation, preventing them from being sent to customers. The change ensures discounts are correctly accounted for in invoice calculations, allowing for proper transmission of invoices through Nemhandel. This improves the functionality of our integration with Nemhandel.

Original PR description

Before this fix, all the OIOUBL invoices with a discount generated
by Odoo would fail the schematron validation, meaning they can't
be sent to the customer through Nemhandel.
The schematron enforces that the discount is taken into account at
the PriceAmount, to keep the rules on lineExtensionAmount working.

Also changes the import to understand that it's a discount.

opw-5379474





---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#invoice#discount#nemhandel#ubl

[FIX] hw_drivers: allow upgrades to >= 19.1

PR #241663

Core18.0hw_driversMEDIUM

This update addresses a compatibility issue preventing older Odoo IoT boxes from running with the newer saas-19.1 database. The PR updates the underlying operating system and Python version, allowing seamless integration with the latest Odoo version. This avoids the need for manual remote fixes or re-flashing of the IoT boxes.

Original PR description

This PR adds 2 migration scripts which allow older iot box images (<= 25_07) to work with databases in saas-19.1 and later.

It updates os to debian trixie and installs all of the necessary packages to allow working after upgrades or with new databases. The update takes approximately 30 minutes. A warning about the necessity to update is added in this
upgrade script: https://github.com/odoo/upgrade/pull/9153

1) Our IoT Boxes which the clients are currently using are running under "Bookworm" os with Python 3.11 with Odoo on it.
2) We have a mecanism which aligns the iot box code to the connected database version using `git checkout`
3) In saas-19.1 Odoo bumped the Python minimal version requirement to 3.12
4) As a result when our iot boxes will do 'git checkout saas-19.1' Odoo will never be able to start anymore
5) When this happens the only way to fix it is either remotely connect to the iot box and run a script like in this PR (remote debug must be activated before upgrading) or flash the iot box with a new image based on Trixie
6) This PR avoids this by updating the current OS to Trixie and the Python version accordingly so that the clients can keep using their iot boxes in saas-19.1

Forward-Port-Of: odoo/odoo#241129

#iot#upgrade#compatibility#odoo

Before this commit, when GS1 barcode was set in the company settings, scanning an invalid barcode may load a wrong product. For example, if the barcode "0000" was scanned, and it would search for all products that contains "0" in their barcode, and load the first one found. opw-5394561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The standard price of the products were not converted to the currency of the PoS journal, which could lead to issues when creating pricelist items based on the standard price. Steps to reproduce: ------------------- * Change the currency of any PoS journal to a different currency than the company currency. * Create a product with a standard price > 0. * Create a pricelist that uses the standard price as a base price. (e.g. price = standard price * 2) * Add this product to a PoS order > Observation: The price is not correctly computed according to the pricelist, because the standard price was not converted to the PoS currency. Why the fix: ------------ We just make sure to convert the standard price of the products when loading the products in the PoS session the same way as we do it for the list price. opw-5124388

Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559

Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition. This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3"). This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order. runbot-237553

Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This PR adds 2 migration scripts which allow older iot box images (<= 25_07) to work with databases in saas-19.1 and later. It updates os to debian trixie and installs all of the necessary packages to allow working after upgrades or with new databases. The update takes approximately 30 minutes. A warning about the necessity to update is added in this upgrade script: https://github.com/odoo/upgrade/pull/9153 1) Our IoT Boxes which the clients are currently using are running under "Bookworm" os with Python 3.11 with Odoo on it. 2) We have a mecanism which aligns the iot box code to the connected database version using `git checkout` 3) In saas-19.1 Odoo bumped the Python minimal version requirement to 3.12 4) As a result when our iot boxes will do 'git checkout saas-19.1' Odoo will never be able to start anymore 5) When this happens the only way to fix it is either remotely connect to the iot box and run a script like in this PR (remote debug must be activated before upgrading) or flash the iot box with a new image based on Trixie 6) This PR avoids this by updating the current OS to Trixie and the Python version accordingly so that the clients can keep using their iot boxes in saas-19.1 Forward-Port-Of: odoo/odoo#241129