Monday, January 19, 2026
8 changes · 18.0
Resolved issues and error corrections
This update fixes a usability issue where the barcode on customer receipts was too narrow, making it difficult for staff to scan. The barcode width has been increased to ensure reliable scanning and accurate order processing. This improves the efficiency of our point-of-sale operations.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="451" height="508" alt="image" src="https://github.com/user-attachments/assets/a0d1e95e-0a9d-4552-977a-0ad9686867b8" /> </td> <td> <img width="456" height="517" alt="image" src="https://github.com/user-attachments/assets/40d04ac4-9ffc-4f81-a063-31b3ea26b4e1" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242469
This update corrects a bug that occurred when attempting to change a tax lock date to a past date. The fix prevents the system from generating incorrect default values and triggering an error, ensuring accurate reporting. This improves the stability and reliability of financial reports.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update corrects a bug that prevented users from importing XML invoices through the accounting module when the 'CustomizationID' tag was missing. The fix ensures that all UBL files now include this mandatory tag, allowing successful invoice processing. This resolves import errors and improves data accuracy.
Original PR description
[FIX] account_edi_ubl_cii: xml import error customization id This error happens when the user tries to import an xml invoice in accounting > customer > invoice and the CustomizationID tag is empty. The cause of this is the CustomizationID tag that exists in the file, but it's empty. This tag is mandatory in a ubl file, so we cannot process the file if it's empty. opw-5238398
This update resolves an issue where contacts created within a company branch couldn't be selected as customers in Field Service. Now, users operating from a branch company can seamlessly choose these contacts, mirroring their availability in Sales Order. This improves Field Service functionality and streamlines customer management within branch operations.
Original PR description
Steps to Reproduce: 1. Create a branch under an existing company. 2. Create a contact in company (so the contact is visible only to the company). 3. Switch to the branch of the company. 4. Open Field Service and create a new record. 5. In the *Customer* field, try to select the contact created earlier. Issue: The contact created under the company is not selectable in the *Customer* field in Field Service. Current behaviour: The same contact is visible in the Contacts app, and also selectable in Sales Order — but not in the Field Service. Expected behaviour: The contact created under the company should be selectable as a customer in Field Service when the current user is operating from that branch. Fix: Added domain on the field partner_id from xml in field services task's views. Task-5114444
This update resolves a problem where GS1 barcodes were causing errors during scanning, preventing products from being correctly identified. The fix allows the system to gracefully handle GS1 barcodes that don't conform to date formatting rules, ensuring accurate product and location detection.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611
This update resolves an issue where embedded buttons in the control panel were getting cropped due to incorrect height calculations during dragging. The fix ensures buttons accurately display their size, improving the user experience and preventing visual distortion. This change improves the overall appearance and functionality of the control panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue within the l10n_ro_saft module that was causing errors when generating SAFT reports. The fix ensures accurate reporting by correctly handling unit of measure data, preventing a 'singleton error' that impacted report generation. This improves the reliability of the SAFT reporting process.
Original PR description
`saft_template` in `l10n_ro_saft` adds a table that loops over the different Unit of Measures (`uoms`) available. The issue is that if the `uoms` are part of different categories (ie: Length and Weight) we get a singleton error as we're trying to access a non-relational field of a recordset with multiple records. The commit fixes the error by using the already defined variable `uom` OPW-5499918 Forward-Port-Of: odoo/enterprise#104478
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when generating invoices with similar payment information. The fix ensures that the system correctly handles multiple invoices sharing the same payment details, preventing errors and improving invoice generation reliability. This ensures consistent invoice creation for users.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460