Wednesday, January 28, 2026
10 changes · saas-18.2
Resolved issues and error corrections
Chile-specific invoices now prevent users from entering document numbers that contain non-numeric characters. This avoids confirmation errors and helps ensure electronic tax documents use the required numeric folio format.
Original PR description
An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits. Steps to replicate: - Install…
An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.
Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.
Error:
```
File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
res = super().action_post()
File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
self._post(soft=False)
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
move._l10n_cl_create_dte()
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```
Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.
Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.
Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.
[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8
No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241505Sales orders using the DIN 5008 layout now show the Delivery Date on printed reports and customer previews. This ensures customers and staff see the agreed delivery timing consistently across sales documents.
Original PR description
**Steps to reproduce:** 1. Install modules `sale_management` and `l10n_din5008_sale` 2. Go to Settings, Configure Document Layout and set layout to DIN 5008 3. Create a new Sale Order 4. Set a…
**Steps to reproduce:** 1. Install modules `sale_management` and `l10n_din5008_sale` 2. Go to Settings, Configure Document Layout and set layout to DIN 5008 3. Create a new Sale Order 4. Set a customer, add a product, and fill in the Delivery Date (Other Info) 5. Click on Print and Preview **Issue:** The Delivery Date (commitment_date) is not displayed on: - The DIN 5008 sale order report - The sale order preview (portal view) Functional experts confirmed that the Delivery Date must be visible when using the DIN 5008 layout. **Cause:** The `commitment_date` field was not included in the DIN 5008 sale order report template nor in the preview view. **Solution:** This commit adds the Delivery Date information to: - The DIN 5008 sale order report template - The sale order portal/preview view **opw-5490651** **Before:** <img width="560" height="145" alt="image" src="https://github.com/user-attachments/assets/fb29cda1-d668-4682-aa04-12c613f248d8" /> <img width="861" height="268" alt="image" src="https://github.com/user-attachments/assets/615f259f-e0ff-4fb5-9852-1fdd75cda4c9" /> **After:** <img width="589" height="145" alt="image" src="https://github.com/user-attachments/assets/3f1a8d25-783a-4600-b07e-11b547bb326b" /> <img width="824" height="271" alt="image" src="https://github.com/user-attachments/assets/46b37469-5c72-4556-95e2-eaea0824c166" /> Forward-Port-Of: odoo/odoo#244917
Repair orders can now have part lines without a selected product while the scheduled date is updated. This prevents an error that could interrupt repair processing and helps users continue editing orders smoothly.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error. Forward-Port-Of: odoo/odoo#244179
Users can now duplicate employee skills without running into a validation error. This removes a workflow blocker in the Skills menu and makes it easier to reuse existing skill records.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Install the hr_skills module - Go to the Skills menu - Select a skill and click Duplicate Issue: - A validation error appears when duplicating a skill Solution: - Updated the copy_data method so skills can be duplicated without causing a validation error Task - 5481185
Printer setup now shortens very long printer identifiers before sending them to the printing system. This prevents setup errors for devices whose network names or addresses exceed the supported length, improving reliability for IoT printer connections.
Original PR description
CUPS has a limit on printer names of 127 characters, which means that if a device has a very long device URI, it can exceed this limit and cause an error when we try to add it to CUPS:
```
Failed to add printer 'dnssdPhotosmart%207520%20series%20%40%20Guillaume%E2%80%99s%20MacBook%20Air%20(2)_ipp_tcplocalcups?96d0de60-096c-3d08-5e2d-893393e10c2b'
Traceback (most recent call last):
File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/printer_interface_L.py", line 242, in set_up_printer_in_cups
self.conn.addPrinter(name=device['identifier'], device=device['url'], **ppdname_argument)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cups.IPPError: (1024, 'client-error-bad-request')
```
We fix this error by truncating the identifier to 127 characters maximum.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245910This fix ensures the online shop sends the correct currency information when calculating product prices. It removes a misleading unused value, reducing the risk of pricing errors and making price-related behavior more reliable.
Original PR description
In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and…
In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and [_get_additionnal_combination_info](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_template.py#L490), the target_currency is passed but it is unused parameter.
The product_pricelist price computation logic relies on the [currency](https://github.com/odoo/odoo/blob/saas-18.2/addons/product/models/product_pricelist.py#L162) and target_currency is not used anywhere in the pricing flow. As a result, passing target_currency adds confusion without affecting the outcome.
The target_currency parameter was unused in the method call flow and, due to this, it was always being passed as NULL. This made the parameter ineffective and confusing, while the actual logic expects a valid currency value.
This commit replaces target_currency with currency to avoid unused / misleading parameter.
Traceback
```py
2026-01-22 12:50:48,564 48232 ERROR currency_19 odoo.addons.website_sale.tests.test_website_sale_product_template: ERROR: TestWebsiteSaleProductTemplate.test_markup_data_uses_taxes_included_price_when_configured_on_website
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/addons/website_sale/tests/test_website_sale_product_template.py", line 81, in test_markup_data_uses_taxes_included_price_when_configured_on_website
markup_data = self.product._to_markup_data(self.website)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/website_sale/models/product_product.py", line 162, in _to_markup_data
product_price = request.pricelist._get_product_price(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 121, in _get_product_price
return self._compute_price_rule(product, *args, **kwargs)[product.id][0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 220, in _compute_price_rule
price = suitable_rule._compute_price(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ProductPricelistItem._compute_price() got an unexpected keyword argument 'target_currency'
```
Before fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = None
uom = None
date = False
compute_price = True
kwargs = {'target_currency': res.currency(20,)}
> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
(Pdb)
```
After fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = res.currency(20,)
uom = None
date = False
compute_price = True
kwargs = {}
> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
res.currency(20,)
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
```
- opw - [5447980](https://www.odoo.com/odoo/project/70/tasks/5447980)
- upg - [3782135](https://upgrade.odoo.com/odoo/upgrade.request/3782135)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a stock module issue where deletion-related filtering could ignore the intended set of records. The change helps ensure stock reorderpoint records are handled only within the correct selection, reducing the risk of unintended processing.
Original PR description
Description of the issue/feature this PR addresses:
This PR fixes an incorrect domain construction when restricting records to the current recordset.
The existing code attempted to combine domains using expression.AND() but did not apply the result, and referenced an invalid domain field.
Current behavior before PR:
- expression.AND() was called without assigning its return value, so the combined domain was never applied.
- The domain condition used ('ids', 'in', self.ids), which is not a valid searchable field.
- As a result, the intended filtering by the current recordset was silently ignored.
Desired behavior after PR is merged:
- The domain is correctly rebuilt and assigned using expression.AND().
- The filter uses the valid field instead of ids
- Records are properly restricted to the current recordset
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242799The Point of Sale loyalty flow now safely stops when a cashier cancels selecting a configurable product. This prevents an error screen when a customer is set, helping staff continue sales without interruption.
Original PR description
Steps to reproduce: = - Open a PoS with pos_loyalty - Set a customer - Open a configurable product - Click `Discard` button or press `ESC` key Issue: = - A traceback occurs with the error: `TypeError: Cannot read properties of undefined (reading 'product_id')` Reason: = - When a configurable product is discarded during variant selection, the flow continues and attempts to process an undefined product. Fix: = - Ensure if adding a configurable product is discarded while selecting variant it should not p[roccess futher. task-5481204
This update resolves a problem that occurred when downloading journal audit reports with multiple companies selected. The issue was caused by duplicate sheet names in the XLSX file, which prevented the report from generating correctly. Now, the report header includes the company name and sheet names are unique, ensuring accurate and reliable downloads.
Original PR description
Before: When downloading the journal audit in XLSX format with multiple companies selected, each company could have journals with the same name (e.g., "Sales"). Since XLSX does not allow duplicate sheet names, this resulted in a traceback. After: Added the company name in the report header when multiple companies are selected. Ensured sheet name uniqueness by appending the journal ID to the journal name. task - 5097253
This update resolves an issue preventing the l10n_be_hr_payroll_fleet module from installing correctly when auto-installation is skipped. The fix ensures the module correctly relies on the hr_fleet module, preventing a missing field error during demo data creation. This ensures the module functions as intended.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_fleet with --skip-auto-install and demo data. 2. Traceback when creating demo data because driver_employee_id is missing on the model fleet.vehicle Cause: The module depends on fleet instead of hr_fleet so hr_fleet is only auto installed. Thus, when skipping auto install, the field driver_employee_id doesn't exist. Fix: Change the dependency from fleet to hr_fleet to force the module to be installed. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/237909 Task: 5875410 Forward-Port-Of: odoo/enterprise#105459