Monday, June 23, 2025
1 change · saas-18.1
Resolved issues and error corrections
Scanning product packaging during inventory counts now records the correct number of individual units. This prevents incorrect stock levels when employees count items using pack barcodes and ensures later scans of units or packs update the same count properly.
Original PR description
### Issue: Steps to reproduce: - In the settings enable packagings - Create a storable product P with Units as uom and a barcode - Inventory > Configuration > Product > Units & Packagings - Click on…
### Issue: Steps to reproduce: - In the settings enable packagings - Create a storable product P with Units as uom and a barcode - Inventory > Configuration > Product > Units & Packagings - Click on pack of 6 > Packaging Barcodes > New - Create one for your product with a different barcode - Go to barcode > Inventory count #### Issue 1: - Scan your packaging > It create a line for 1 Pack of 6 - Apply #### > If you check on the product form you have 1 on Hand unit #### Issue 2: - Scan your packaging > It create a line for 1 Pack of 6 - Scan your product > Nothing happens rather than adding one unit #### Issue 3: - Scan your product > It create a line for 1 Unit - Scan your packaging > Nothing happends rather than adding 6 units ### Cause of the issue: The issue 1 is the most problematic as it introduce corrupted data. The issue has been introduced by Commit 188ad6980222a77168c462cf149cb79bf28ca2e6 where packagings have been merged with uoms. Prior to this commit, scanning a packaging would convert the barcodeData to to be expressed in the uom of the product: https://github.com/odoo/enterprise/commit/188ad6980222a77168c462cf149cb79bf28ca2e6 The commit came with the additional feature of creating lines refering dirrectly to the packaging, for instance scanning a pack of 6 would create one line: 1 pack of 6. While this behavior make sense in the context of pickings since stock moves can bear different uoms than the product it self, it does not in the context of stock.quant's since the uom of the quant is necessarily the one of the product: https://github.com/odoo/odoo/blob/9f8e9ca2676f5e3ccc34522d444d1f02e2d21f92/addons/stock/models/stock_quant.py#L53-L55 Now, the issue is that in inventory counts you edit quants via the barcode lines. When the barcode changes are applied in db, we provide the data's to write or create via these lines: https://github.com/odoo/enterprise/blob/38e0ae75c2cfddfe76535847ff8b67823b0c6419/stock_barcode/static/src/models/barcode_model.js#L920-L928 https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/static/src/models/barcode_quant_model.js#L307-L320 which can not provide to the backend the packaging uom in order to convert the related quantities (as it is not a quant field). In particular, the Command.create and Command.update are simply populated expecting these qties to be expressed in the product_uom. ### Fix: Converting the barcodeData's quantity in case a packaging is provided will solve all issues since all the save commands will be expressed in the expected uom and since the barcode machinery is already tailored to treat the addition of appropriate qties. opw-4872894