Odoo Changelog — 2026-03-06

Friday, March 6, 2026

5 changes · saas-18.3

Bug Fixes(5)

Resolved issues and error corrections

[FIX] sale_subscription: block cancelling invoiced subscriptions after close

Enterprisesaas-18.3sale_subscriptionMedium

This update fixes a bug where users could cancel subscriptions that had already been closed and generated invoices. The change adds a check to ensure that cancelled subscriptions with outstanding invoices cannot be re-cancelled, preventing potential billing issues and maintaining data integrity. This ensures accurate subscription management.

Original PR description

Steps to reproduce: -------------------------------- 1. Install Subscription module 2. Create a new subscription quotation and confirm it 3. Generate an invoice for the subscription 4. Attempt to…

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#106596

#subscription#billing#invoice

[FIX] payment_authorize: prevent OTS token consumption

PR #252357

Coresaas-18.3payment_authorizeMedium

This update resolves an issue where payment processing through Authorize.Net was occasionally failing due to a conflict between API requests and background updates. By implementing a temporary lock on payment records, Odoo now ensures that tokens are used only once, preventing errors and guaranteeing successful payment processing. This improves the reliability of our payment system.

Original PR description

Currently, when processing a payment through Authorize.Net, a concurrent update (e.g., from a background cron job) can trigger a PostgreSQL `SERIALIZATION_FAILURE` right after the API request succeeds. Because Odoo automatically retries the request upon this failure, the second attempt sends the same One-Time-Use (OTS) token. Authorize.Net rejects the reused token ("Invalid OTS Token"), causing a successful charge to be incorrectly marked as failed in Odoo.

This commit introduces a pessimistic lock (`FOR NO KEY UPDATE`) on the `payment_transaction` record before making the call to Authorize.Net. This serializes access to the transaction row, ensuring that any lock waits or serialization failures occur *before* the single-use token is consumed, allowing Odoo's automatic retry mechanism to succeed safely.

opw-5475032

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

Forward-Port-Of: odoo/odoo#249088

#payments#authorize.net

[FIX] point_of_sale: prevent recompute of manually set prices while settling

PR #252263

Coresaas-18.3point_of_saleMedium

This update fixes an issue where manually adjusted prices in Point of Sale (PoS) settlements weren't being correctly applied. Previously, PoS settlements would revert prices back to the base price, even if the user had manually set a different price. Now, the system accurately reflects user-defined prices during settlement, ensuring accurate transactions.

Original PR description

**Steps to reproduce:** - Create a product tracked by lot, set it's price to 1000 - Create a quotation add a line with the created product and change the price to 1200 - Add another line with the…

**Steps to reproduce:**
- Create a product tracked by lot, set it's price to 1000
- Create a quotation add a line with the created product and change the price to 1200
- Add another line with the same product and change it's price to 600
- Go to PoS and settle this quotation
- The lines' prices will be 1000 and 600 instead of 1200 and 600

**Why the fix:**
In the event of a settle with a product tracked by lots, we are setting the price of all *related_lines* (lines with the same product in this case) to it's base price, not taking into account the fact that this price has been modified by the user when making the quotation.

This only happens for related lines, which explains why one line's price is still 600 while the other was reverted to the base price of 1000 instead of being 1200 as it was previously set.

To avoid this, we now set the price_unit back to the base one only if the price hasn't been changed manually.

opw-5223463

Forward-Port-Of: odoo/odoo#251883
Forward-Port-Of: odoo/odoo#238295

[FIX] pos_self_order: price with fiscal position

PR #252350

Coresaas-18.3pos_self_orderMedium

This update fixes an issue where self-order prices weren't accurately calculated when taxes and fiscal position mappings were involved. The change ensures prices are correctly recomputed using accounting methods, leading to more accurate order totals and financial reporting. This improves the reliability of self-order transactions.

Original PR description

Before this commit, the price of order lines from self was recomputed in the backend but for orders with price included taxes and a fiscal position mapping, the recomputation was not correct. This commit fixes the issue by recomputing the prices using compute_all method from accounting on taxes after fiscal position.

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

Forward-Port-Of: odoo/odoo#252048
Forward-Port-Of: odoo/odoo#251945

#pricing#taxes#fiscal#self-order

[FIX] point_of_sale: update serial numbers requirements

PR #246930

Coresaas-18.3point_of_saleMedium

This update fixes a bug in the Point of Sale where a warning wasn't displayed when selling products with unique serial numbers and quantities greater than one. Previously, the system didn't alert users that only one serial number was being used for multiple products. This change ensures proper warnings are shown, preventing potential errors during transactions.

Original PR description

## Issue In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is…

## Issue
In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is given.

## Steps to reproduce
1. Install Point of Sale (`point_of_sale`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a PoS product P
    - Tracked *By Unique Serial Number*
    - Update its quantity and create a few serial numbers
4. In the Point of Sale, select product P and set a serial number, then update the quantity to 2.
5. **The _Valid product lot_ icon next to the product is still green. We can also go to the payment screen without any warning, even though only one serial number was selected for two products.**

## Cause
The color and name of the icon displayed next to the serial tracked product is decided here:

https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9-L14

The `PosOrderLine.hasValidProductLot` is defined here:

https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/models/pos_order_line.js#L333-L341

The very first condition of this method makes the icon green as long as one serial number is selected.

opw-5486210

Steps to reproduce: -------------------------------- 1. Install Subscription module 2. Create a new subscription quotation and confirm it 3. Generate an invoice for the subscription 4. Attempt to cancel the subscription * A ValidationError is correctly raised 5. Close the subscription by selecting any close (churn) reason 6. Attempt to cancel the same closed subscription again Observation: -------------------------------- The subscription is successfully cancelled even though it already has invoices Issue: -------------------------------- In the following code: https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices Solution: -------------------------------- Added an additional condition to prevent cancelling churned subscriptions that still have active invoices opw-5479719 Forward-Port-Of: odoo/enterprise#106596

Currently, when processing a payment through Authorize.Net, a concurrent update (e.g., from a background cron job) can trigger a PostgreSQL `SERIALIZATION_FAILURE` right after the API request succeeds. Because Odoo automatically retries the request upon this failure, the second attempt sends the same One-Time-Use (OTS) token. Authorize.Net rejects the reused token ("Invalid OTS Token"), causing a successful charge to be incorrectly marked as failed in Odoo. This commit introduces a pessimistic lock (`FOR NO KEY UPDATE`) on the `payment_transaction` record before making the call to Authorize.Net. This serializes access to the transaction row, ensuring that any lock waits or serialization failures occur *before* the single-use token is consumed, allowing Odoo's automatic retry mechanism to succeed safely. opw-5475032 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249088

**Steps to reproduce:** - Create a product tracked by lot, set it's price to 1000 - Create a quotation add a line with the created product and change the price to 1200 - Add another line with the same product and change it's price to 600 - Go to PoS and settle this quotation - The lines' prices will be 1000 and 600 instead of 1200 and 600 **Why the fix:** In the event of a settle with a product tracked by lots, we are setting the price of all *related_lines* (lines with the same product in this case) to it's base price, not taking into account the fact that this price has been modified by the user when making the quotation. This only happens for related lines, which explains why one line's price is still 600 while the other was reverted to the base price of 1000 instead of being 1200 as it was previously set. To avoid this, we now set the price_unit back to the base one only if the price hasn't been changed manually. opw-5223463 Forward-Port-Of: odoo/odoo#251883 Forward-Port-Of: odoo/odoo#238295

Before this commit, the price of order lines from self was recomputed in the backend but for orders with price included taxes and a fiscal position mapping, the recomputation was not correct. This commit fixes the issue by recomputing the prices using compute_all method from accounting on taxes after fiscal position. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252048 Forward-Port-Of: odoo/odoo#251945

## Issue In the Point of Sale, when selling a product tracked by unique serial number with a quantity greater than one, no warning are displayed to the displayed as long as one serial number is given. ## Steps to reproduce 1. Install Point of Sale (`point_of_sale`) 2. In Settings, enable *Lots & Serial Numbers* 3. Create a PoS product P - Tracked *By Unique Serial Number* - Update its quantity and create a few serial numbers 4. In the Point of Sale, select product P and set a serial number, then update the quantity to 2. 5. **The _Valid product lot_ icon next to the product is still green. We can also go to the payment screen without any warning, even though only one serial number was selected for two products.** ## Cause The color and name of the icon displayed next to the serial tracked product is decided here: https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9-L14 The `PosOrderLine.hasValidProductLot` is defined here: https://github.com/odoo/odoo/blob/3d787e1b7c2ab471694849a04bdf2d3a5ff7e515/addons/point_of_sale/static/src/app/models/pos_order_line.js#L333-L341 The very first condition of this method makes the icon green as long as one serial number is selected. opw-5486210