Daily updates from Odoo
Saturday, July 4, 2026
6 changes · saas-19.3
Resolved issues and error corrections
Fixes an issue where leaving the Barcode view could reduce a receipt quantity when products were handled in packs instead of individual units. Quantities are now converted correctly, helping keep inventory receipts accurate and preventing understated stock levels.
Original PR description
**Steps to reproduce:** - Install `stock` and `purchase` modules - Enable `Units of Measure and Packages` and `Storage Locations` from setting - Create a storable product with vendor purchase UoM set…
**Steps to reproduce:** - Install `stock` and `purchase` modules - Enable `Units of Measure and Packages` and `Storage Locations` from setting - Create a storable product with vendor purchase UoM set to "Pack of 6" - Create and confirm a Purchase Order with quantity 6 Units - Open the generated receipt - Update a move line in Detailed Operations: - Quantity: 1 - UoM: Pack of 6 - Save and open the Barcode view using smart button. - Increase quantity using "+" button by 1. - Exit barcode view without validating and refresh the receipt **Issue:** After refresh, the stock move quantity becomes 1 instead of 6, while the move line correctly shows 1 Pack of 6. **Cause:** https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162 - Exiting the barcode view triggers `__onExit()`, which forwards `reserved_uom_qty` and `qty_done` from move lines to `post_barcode_process()`. https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898 This `post_barcode_process()` function triggers `_truncate_overreserved_moves()` https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58 - During this flow, `_truncate_overreserved_moves()` updates the stock move quantity by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns this value directly to the move without converting it into the stock move UoM. - In this case, both values are 1 because the move line is UoM is "Pack of 6" Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units, this conversion is skipped. As a result, the move quantity is incorrectly set to 1 instead of 6. https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54 **Fix:** - Convert quantities coming from barcode processing into the stock move UoM before updating the move quantity, ensuring packaged UoM values are preserved correctly. ---- opw-5472598 Forward-Port-Of: odoo/enterprise#122769 Forward-Port-Of: odoo/enterprise#116022
Belgian CODA bank imports now use the full payment communication as the reference when transactions have unstructured communication. This makes imported bank transactions easier to identify and match with the correct payments or invoices.
Original PR description
### Issue: When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref Causing difficulty to match with the transactions ### Cause: For simplicity reason, the payment_ref and the communication where different The `payment_ref` was fetched once and replace The `communication` was always completed by new lines ### Steps to reproduce: - Install `l10n_be_coda` - Set the account on the Bank Journal to GR5605700000000928073840752 - Import the Simplied CODA (On the ticket) from the bank dashboard Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter opw-6245848 Forward-Port-Of: odoo/enterprise#122344 Forward-Port-Of: odoo/enterprise#120536
The Preparation Display app now opens directly instead of using an intermediate action that required extra permissions. This prevents certain point-of-sale users from being blocked by an access error, helping kitchen and restaurant workflows continue smoothly.
Original PR description
A recent fix in the base module requires users to have "write" access on ao model to execute its server actions. commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`. However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display. This commit bypasses the intermediate server action and opens the URL action directly. Task-6311320 Forward-Port-Of: odoo/enterprise#121293
This update resolves a bug in a test related to account reporting, specifically impacting how demo data is handled. The fix includes a necessary step to ensure test data is properly cleared, preventing errors in related reports. This improves the reliability of our reporting features.
Original PR description
The test introduced by d60564a42b7c7b16d1d975146291835b65a19461 was using the field `deferred_move_ids` which is defined by account_accountant. As it is used to clear the pre-existing moves (typically demo data), we are re-using the same conditional as test_tour.py to check whether this field is available. By the way, we also add a missing flush_recordset that caused errors in test_kpi_summary_reports_unreconciled_bank_statements. Runbot-error: [939986](https://runbot.odoo.com/odoo/error/939986) Forward-Port-Of: odoo/odoo#271218
This update fixes issues preventing barcode scans of employee badges from correctly logging users into the Point of Sale (PoS) system. Specifically, it ensures that scanning a badge triggers the correct PIN entry and correctly switches cashiers when scanning another employee's badge. This improves the user experience and streamlines the login process for PoS staff.
Original PR description
See commit messages. [[FIX] pos_hr: scanning badge should work with PIN input focused](https://github.com/odoo/odoo/commit/95d9329674e81b2659445e2021a35b21bbbc81a3) [[FIX] point_of_sale: scanning a badge should not auto confirm the PIN](https://github.com/odoo/odoo/commit/d59fb1f6fe27d117579b3945c5bba400d17d0014) (Note: this is only needed up to saas-18.4 included -- 19.0 already has this diff) [[FIX] pos_hr: scanning another cashier's badge switches to that cashier](https://github.com/odoo/odoo/commit/c812fe596694b16a494e3dcf908d17f621f7ce92) opw-6125029 Forward-Port-Of: odoo/odoo#273838 Forward-Port-Of: odoo/odoo#262474
This update significantly speeds up the process of closing a Point of Sale session, particularly when using 'Identify Customer' for bank payments. Previously, closing a session with many payments could take over 10 minutes, but now it completes in approximately 75 seconds. This improves efficiency and reduces delays for users.
Original PR description
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order. 3. Close the session. With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed". Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too. Benchmark --------- These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database: - before: the close did not finish after more than 10 minutes. - after: the close takes around 75 seconds. opw-6242303 Forward-Port-Of: odoo/odoo#269306