Tuesday, March 10, 2026
3 changes · 17.0
Resolved issues and error corrections
This update corrects a validation error that occurred when sending invoices to Peppol. The system previously incorrectly converted UoM 'qt (US)' to 'QT', which is no longer a valid code according to UN/ECE standards. This change ensures invoices comply with international regulations.
Original PR description
Currently, the Odoo UoM 'qt (US)' is converted to 'QT', which is not valid anymore. Based on investigation, this was originally set to QT following this link: https://unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf But this document seems dated from 2005. Step to reproduce: - Create an invoice with a line with 'qt (US)' as UoM - Try to send the invoice to Peppol - You will get a validation error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21" Also removed the link to unece.org since the link is no longer valid. opw-5961476 Forward-Port-Of: odoo/odoo#252174
This update fixes an issue where the shipping weight for deliveries with packages was incorrectly calculated when multiple pickings were involved. The change ensures that package weights are accurately computed based on the context of each individual delivery, leading to more reliable shipping weight data. This improves the accuracy of shipping costs and inventory management.
Original PR description
Problem: When computing the `shipping_weight` for pickings with packages, we use package weights. If a picking is passed via the context, the package weight is computed using the contained product…
Problem: When computing the `shipping_weight` for pickings with packages,
we use package weights. If a picking is passed via the context, the
package weight is computed using the contained product weights. Otherwise,
it just uses the `package.package_type_id.base_weight` or 0.
This issue occurs when computing the `shipping_weight` for multiple
pickings at one time. Odoo prefetches the packages and their weights are
computed using the context of the first picking. If a package does not
belong to the first picking, their weight is not computed using its
`stock.move.line` product weights and the incorrect value is cached. When
the loop reaches the next picking, it uses the incorrect weight that was cached.
Purpose: Add `@api.depends_context('picking_id')` to `_compute_weight` so that
package weights are cached per picking.
I have updated this assert
https://github.com/odoo/odoo/blob/338fc201cc0ed0f2fd8349fab4f538817e69a295/addons/stock_delivery/tests/test_packing_delivery.py#L316-L317
to explicitly pass the `picking_id` in the context when checking the cached package weights.
Steps to Reproduce on Runbot:
Navigate to Inventory > Configuration > Settings and enable Packages.
Create a new storable product with a weight of 1 kg and add 2 units on-hand.
Create a delivery for 1 unit of our newly created product, mark as todo and put in a pack.
Create a second delivery for 1 unit of our newly created product, mark as todo, and put in a pack.
Observe on the second delivery the weight for shipping is 1 kg.
Navigate to the list view of deliveries and add the weight for shipping field to the view.
Search for both deliveries we created and observe the first one has a weight for shipping of 1 kg,
but the second one has a weight for shipping of 0 kg.
opw-5902814This update fixes an issue where upsell orders within subscription plans weren't correctly reflecting the invoiced quantity. The fix ensures that the quantity invoiced on upsell orders matches the quantity on the associated invoice, resolving a discrepancy that prevented accurate billing. This impacts subscription revenue reporting.
Original PR description
_ ## Short functional explanation of the error When creating a subscription for the previous and current month, and creating an upsell order for a day in between the start of the previous and current…
_ ## Short functional explanation of the error When creating a subscription for the previous and current month, and creating an upsell order for a day in between the start of the previous and current period, when we invoice that upsell order, the quantities invoiced shown on the upsell order are incorrect. ## Reproduction Steps 1. Create a subscription starting the first day of last month. Set the recurring plan as Monthly and add a product. Click on Confirm. 2. Create a first invoice for which the Invoice Date is the first day of last month. Click on confirm. 3. In the breadcrumb, click on the Sales order and create a second invoice, this time with the date of today. 4. Click on the Sales order in the breadcrumb and click on Upsell. Set the quantity to 5, the quotation date to the 15th of last month and in the Other info tab, set the Start date to the same date. 5. Create an invoice and confirm. 6. Go back to the Sales order of the Upsell and check the Invoiced field in the Order Lines tab. ### Expected behavior The field Invoiced should be equal to 5, which is the quantity we have on the invoice. ### Unexpected behavior The field Invoiced is left at 0. ## Origin of the issue When getting the quantity invoiced for a specific Sales order, we retrieve the related invoice lines of that order using the code: https://github.com/odoo/enterprise/blob/13ca7fbc46e7c915423d80a152ecd3cfd0ac8468/sale_subscription/models/sale_order_line.py#L186-L190 The issue comes from `start_date <= l.deferred_start_date <= day_before_end_date`, as the invoices that have a deferred_start_date prior to the start_date won't be found. Only involves 17.0 __ opw-5238326