Odoo Changelog — 2026-03-31

Tuesday, March 31, 2026

6 changes · saas-18.4

Bug Fixes(6)

Resolved issues and error corrections

[FIX] pos_sale: settle sale order with down payment and extra lines

Coresaas-18.4pos_saleMedium

Sale orders with a down payment can now be settled again from Point of Sale even when the same checkout also includes additional products. This prevents valid sale orders from disappearing from settlement options when the overall receipt total is higher than the original sale order amount.

Original PR description

The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005

The unpaid_amount is now computed from the PoS order total instead of the settle payment order line.

This causes an issue when the PoS order contains additional product lines besides the settle payment line.

In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS.

How to reproduce:
- Create a sale order.
- Apply a down payment in the PoS.
- Add other products before validating the payment.
- Ensure the total exceeds the sale order amount.
- Pay the order.
- Try to settle the same sale order from PoS, cannot find it.

opw-5821232

Forward-Port-Of: odoo/odoo#251387

#point-of-sale#sale-orders#down-payments#settlement

[FIX] stock: show correct quantities on delivery slip

PR #256766

Coresaas-18.4stockMedium

Delivery slips now show the correct ordered and delivered quantities when products use packaging units such as packs. This prevents confusing or inflated quantities on customer and warehouse paperwork.

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
- 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#249779

[FIX] purchase: compare PO/invoice price_unit with product price prec.

PR #256713

Coresaas-18.4purchaseMedium

Vendor bills imported through EDI are now matched to purchase orders even when tiny rounding differences appear in unit prices. This prevents valid invoices, including Peppol invoices, from failing to link to their related purchase orders.

Original PR description

Fixes Task 5213234

Issue:
In AccountMove method _find_matching_po_and_inv_lines (called when looking for
a subset match of EDI invoice lines with PO lines), the price_unit of a
purchase.order.line is compared to the price_unit of an invoice line.
However, currently the comparisons do not take into account the precision to be
applied to product prices.
In some cases, the invoice line price_unit differs from the price_unit in a PO
line, but by less than the "Product Price" precision. With the current
comparisons this leads to not matching the lines.
This has prevented matching some invoices received via Peppol for at least one
big customer (see Task-5213234)

Steps to reproduce:
- Create an XML document for an EDI UBL invoice with 2 lines; the first line
  has a price_unit 113.57 euros (for example) 
- Create a PO with a reference matching the invoice, and one PO line with a
  price_unit matching the price_unit of the first invoice line (113.57 euros)
- Upload the XML invoice and create a bill from it; during the creation of the
  account.move.line, the price_unit gets a value which is slightly different
  from 113.57 (113.57000000000001) (due to python rounding ?)
- Result: no link is established between the PO and the invoice.

This fix makes sure that the "Product Price" precision is used when comparing
the invoice line price_unit with a PO line price_unit.

opw-5213234

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#236960
Forward-Port-Of: odoo/odoo#232527

[FIX] l10n_jo_edi: Fix credit notes lines ids matching algorithm

PR #256950

Coresaas-18.4account_edi_ubl_ciil10n_jo_edil10n_jo_edi_posMedium

This fix improves how Jordan electronic invoices link refund lines back to the original invoice lines, especially when invoices contain repeated similar products or changed line descriptions. It helps prevent incorrect credit note references for both standard invoices and point-of-sale refunds.

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

[FIX] appointment,web_gantt: removed originId from data before the orm call

PR #100570

Enterprisesaas-18.4appointmentweb_ganttMedium

This update resolves an issue where users couldn't successfully undo rescheduling calendar events. The fix removes a problematic data field ('originId') before the system writes event data to the database, preventing a data error. This ensures the undo functionality now works as expected.

Original PR description

Currently, an error occurs when user tries to undo a calendar event.

Steps to replicate:
- Install `appointment` with demo data.
- Navigate to `Appointments > Schedule > Resource Booking`.
- Drag to create a calendar event.
- Reschedule the event to a later time (drag and drop forward).
- Click Undo on the notification that appears.

Error:
`ValueError: Invalid field 'originId' in 'calendar.event'`
`KeyError: 'originId'`

Cause:
- The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it.
- The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur.

Solution:
- Remove the `originId` key from `fallbackdata` before the orm call.

[1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116

[fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425

[orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477

[line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248

sentry-7020359653

[FIX] stock_barcode: prevent crash on confirming archived products

PR #112495

Enterprisesaas-18.4stock_barcodeMedium

This update resolves an issue where confirming quantities of archived products through the barcode app would cause a system error. The fix ensures that archived products are included in search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality.

Original PR description

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and create a new delivery with
- **Source Location:** WH/Stock
- **Product:** [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

Forward-Port-Of: odoo/enterprise#112349
Forward-Port-Of: odoo/enterprise#109204

The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005 The unpaid_amount is now computed from the PoS order total instead of the settle payment order line. This causes an issue when the PoS order contains additional product lines besides the settle payment line. In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS. How to reproduce: - Create a sale order. - Apply a down payment in the PoS. - Add other products before validating the payment. - Ensure the total exceeds the sale order amount. - Pay the order. - Try to settle the same sale order from PoS, cannot find it. opw-5821232 Forward-Port-Of: odoo/odoo#251387

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#249779

Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is compared to the price_unit of an invoice line. However, currently the comparisons do not take into account the precision to be applied to product prices. In some cases, the invoice line price_unit differs from the price_unit in a PO line, but by less than the "Product Price" precision. With the current comparisons this leads to not matching the lines. This has prevented matching some invoices received via Peppol for at least one big customer (see Task-5213234) Steps to reproduce: - Create an XML document for an EDI UBL invoice with 2 lines; the first line has a price_unit 113.57 euros (for example) - Create a PO with a reference matching the invoice, and one PO line with a price_unit matching the price_unit of the first invoice line (113.57 euros) - Upload the XML invoice and create a bill from it; during the creation of the account.move.line, the price_unit gets a value which is slightly different from 113.57 (113.57000000000001) (due to python rounding ?) - Result: no link is established between the PO and the invoice. This fix makes sure that the "Product Price" precision is used when comparing the invoice line price_unit with a PO line price_unit. opw-5213234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236960 Forward-Port-Of: odoo/odoo#232527

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

Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to create a calendar event. - Reschedule the event to a later time (drag and drop forward). - Click Undo on the notification that appears. Error: `ValueError: Invalid field 'originId' in 'calendar.event'` `KeyError: 'originId'` Cause: - The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it. - The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur. Solution: - Remove the `originId` key from `fallbackdata` before the orm call. [1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116 [fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425 [orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477 [line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248 sentry-7020359653

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#112349 Forward-Port-Of: odoo/enterprise#109204