Thursday, January 22, 2026
8 changes · 17.0
Resolved issues and error corrections
This update corrects a rounding issue in the payment wizard when displaying amounts in MXN currency for invoices with USD pricing and taxes. The fix ensures accurate currency conversion and display of invoice totals, resolving a discrepancy between the invoice and payment wizard. This improves financial reporting accuracy.
Original PR description
With a company where the main currency is, for instance, MXN (easier to reproduce with l10n_mx): - Create a currency exchange rate for USD: 0.051908143350 unit per MXN and 19.264800000000 MXN per unit. - Create an invoice in USD with a product priced at 432, quantity of 2, and 16% taxes. In the journal items of the invoice, the balance is 19307.96 MXN. However, in the payment wizard, the amount shown when switching to MXN currency is 19307.95. In _get_total_amount_in_wizard_currency_to_full_reconcile, we convert the source amount currency (which includes line + tax not yet converted), then perform the conversion. Whereas in the invoice, we first convert the product line and tax line separately and then sum them up. enterprise: https://github.com/odoo/enterprise/pull/92522 opw-4846090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug in the tests for the Mexican Electronic Invoicing (CFDI) payment wizard. The fix ensures accurate rounding of payments during tax calculations, addressing a potential discrepancy in how taxes were applied. This improves the reliability of financial reporting within the Odoo Enterprise system.
Original PR description
This commit correct the test test_cfdi_rounding_9 after commit a7213d25965348aa3188ee7368f8db6d57463fc1 community: https://github.com/odoo/odoo/pull/222682 opw-4846090
This update addresses a minor issue preventing Odoo modules (l10n_eg_edi_eta, l10n_ro_edi_stock, and l10n_rs_edi) from correctly importing a JSON error handling function. The fix involves installing a specific version of the 'requests' library and importing the necessary exception class, resolving a conflict introduced in a recent 'requests' package update.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` packageThis update resolves a bug preventing Quality Administrators from creating Quality Worksheet Templates. The issue stemmed from incorrect permission handling during record creation, now corrected to ensure proper access rights are applied. Users can now successfully create and save templates.
Original PR description
A Quality Administrator user currently cannot create a Quality Worksheet Template. This is caused by the fact that the process creates additional records: 'ir.model' and 'ir.model.fields'. The `.sudo()` used with the first one is not propagated to the second one. The solution was to create 'ir.model.fields' separately, after the creation of 'ir.model'. Additionally, 'ir.rule' creation is also done with `.sudo()` now (it's a part of the same process). Steps to reproduce: * as admin, modify the demo user: * make sure the "Administration" access right is empty * set "Quality" access right to "Administrator" * as demo user: * go to Quality -> Configuration -> Quality Worksheet Templates * create a new template and save The template should be saved without any errors. Task: 5350296
This update simplifies the process of reversing returns for products valued using standard costs. Previously, extra journal entries were automatically created, which is no longer necessary. This change streamlines accounting and reduces potential errors when handling returns of standard cost items.
Original PR description
Currently, when a user needs to reverse a return for a standard cost product, extra journal items are created to balance the initial purchase operation. Steps to reproduce: 1. Create a standard price/automated product category 2. Create a storable product with such category and cost 10 3. Create a PO with 1 @ 100, Confirm and receive the product 4. Return the full quantity 5. Return the return for the full quantity Issue: During the last operation two additional journal items are created to balance the returned svl with the original purchase price. However this is not needed when the item has a standard cost inventory valuation. opw-5133716
This update corrects a bug that caused the kitchen printer to print blank tickets when using the self-ordering kiosk feature in Restaurant mode. The fix ensures that the printer only prints when order lines are present, aligning with the expected behavior of the system. This prevents unnecessary printing and potential confusion for staff.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer)
This update resolves a potential infinite loop issue that could occur when generating product combinations, specifically with multi-checkbox attributes. The fix ensures that product lines without values are excluded, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a minor issue in the way Odoo transmits ELM (Employers’ Ledger and Monetary Summary) data for Swiss payroll. The change ensures that a snapshot is only created if one doesn't already exist, optimizing the process and preventing unnecessary data duplication. This improves efficiency and reduces potential processing delays.