Tuesday, March 31, 2026
5 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where delivery slips incorrectly displayed the quantity of packaged items. The change ensures that the correct quantity (5) is shown when items are delivered in packs, resolving a discrepancy between ordered and delivered amounts. This improves accuracy in inventory management.
Original PR description
Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity. ## Steps to replicate: - Install Purchase and Inventory with demo data -…
Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity.
## Steps to replicate:
- Install Purchase and Inventory with demo data
- Settings > Enable 'Units of Measure & Packagings' and 'Packages'
- Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor.
- Create new RFQ with the same vendor for 'Desk pad' having quantity 10
- Confirm RFQ > Go to receipt > Details
- Create and Set Destination Package to
- LOT A 5 pack of 6
- LOT B 5 pack of 6
- Validate Delivery Order and Print the Delivery Slip
## Observed Behavior:
Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect.
The correct quantity ordered and delivered should be 5 (Pack of 6).
## Root cause:
This unintentional behavior occurs after commit [1].
When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging.
As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed.
Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5.
[2]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945
[3]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88
## Solution:
Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly.
**Before:**
<img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" />
**After:**
<img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" />
[1]:
https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28
opw-5930343
Forward-Port-Of: odoo/odoo#249779This update resolves an issue where Field Service users couldn't add customers to tasks, resulting in an access error. The fix securely updates partner records using sudo() to allow task creation, and adds view-level restrictions to control who can modify customer phone numbers. This ensures Field Service functionality is consistently available.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Used sudo() in the inverse method to update the partner phone securely, bypassing restricted access. task-5039657 Forward-Port-Of: odoo/enterprise#109668 Forward-Port-Of: odoo/enterprise#93969
This update fixes an issue where refund creation from invoices with similar items would fail due to incorrect line matching. The new algorithm now accurately identifies the best matching invoice lines based on product, price, and quantity, ensuring refunds are processed correctly. This improves the reliability of refund processing for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update fixes an issue where refund creation from invoices with similar product details would fail due to incorrect line matching. The new algorithm now accurately identifies the best matching invoice lines based on product, price, and quantity, ensuring refunds are processed correctly. This improves the reliability of refund processing for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update fixes an issue where refund processing for invoices with multiple identical lines would fail. The new algorithm now accurately matches refund lines to invoices based on product, price, and quantity, preventing incorrect matching and ensuring accurate credit note processing. This improves the reliability of refund operations.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200