Daily updates from Odoo
Thursday, June 4, 2026
5 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where barcode scanning incorrectly displayed delivered quantities on sales orders. The problem stemmed from how the system processed barcode scans, leading to inaccurate order fulfillment. The fix ensures that quantities are correctly reflected after scanning lots, resolving delivery discrepancies.
Original PR description
Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities. ## Steps to replicate: - Install Sales and Barcode (no demo data). - Enable Lots & Serial…
Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.
## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
- Scan lot 2 > increase qty to 3 using +1 button
- Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.
## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.
## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.
As the loop in `_findLine` iterates through `pageLines` with values like:
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }},
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```
During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].
This results in the line with quantity 2 being selected as the line to update at the end of the function.
When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.
[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729
## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.
opw-5423943
Forward-Port-Of: odoo/enterprise#118085
Forward-Port-Of: odoo/enterprise#109032This update fixes a bug where users were unexpectedly locked out of list views after attempting to edit a row. The fix ensures the system correctly exits edit mode when a user clicks away, preventing this frustrating interruption. This improves the overall user experience and data entry efficiency.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836 Forward-Port-Of: odoo/enterprise#119008 Forward-Port-Of: odoo/enterprise#113000
This update corrects a calculation error in the executive summary report, specifically within the date range calculations. Previously, the report was undercounting the number of days in a period, leading to inaccurate metrics like Average Debtor Days. This change ensures the report accurately reflects the period length, improving the reliability of key business data.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update fixes an issue where the Balance Sheet report's XLSX export was incorrectly including all accounts instead of the one selected in the date filter. The fix removes a filtering step that was unintentionally introduced, ensuring the export accurately reflects the user's chosen account. This improves the reliability of financial reporting.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
This update corrects a bug where previously validated manual bank statement entries continued to be incorrectly suggested for matching with new transactions. The fix ensures that only the most recent bank statement entry is considered during reconciliation, improving the accuracy of financial records. This resolves a potential issue with mismatched accounts.
Original PR description
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create a transaction for 500 dollars - Create a manual counterpart line for the bank statement line with label "test123" and validate - Create another transaction of -1000 dollars and label "test123" Issue: The manual counterpart line matched before is being suggested against the new transaction. The perfect match reconciliation model will reconcile the manual counterpart line with the new bank statement line. Adding test for community branch opw-6045050 Forward-Port-Of: odoo/enterprise#117462 Forward-Port-Of: odoo/enterprise#115847