Odoo Changelog — 2026-04-30

Thursday, April 30, 2026

4 changes · 17.0

Bug Fixes(4)

Resolved issues and error corrections

[FIX] Point_of_sale: Prevent multiple refunds in a single transaction

Core17.0point_of_saleMedium

This fix addresses an error that occurred when users attempted to process multiple refunds for the same customer within a single payment transaction. The change prevents users from selecting multiple refunds, ensuring the system functions correctly and avoids data inconsistencies. This improves the reliability of the point-of-sale refund process.

Original PR description

After the fix, when selecting multiple refunds not belonging to a same order, a user error will appear, preventing an odoo error later in the flow.…

## Reproduction Steps
1. Go to the point of sales module, and create an order for a specific customer. Proceed to the payment and make sure that finalizing the payment will create an invoice, before confirming the payment.
2. Create a second order for the same customer, and proceed the same way as in step 1.
3. On the product screen, click on "refund".
4. Select one order that you've just completed. Then, setup the quantity at 1 and click on refund.
5. Do step 4 again but this time, select the second order that you've just completed.
6. Click on payment, then click on invoice then try to validate the payment.

The error occurs:
Expected singleton: account.move(720, 722)
Traceback (most recent call last):
File "/data/build/odoo/odoo/models.py", line 5896, in ensure_one
_id, = self._ids
ValueError: too many values to unpack (expected 1)

## Causes of the problem
It is due to an ensure_one() in python. Indeed, in the file point_of_sale/models/pos_order.py,in the function _prepare_invoice_vals(self), an error occured on the line:

vals['ref'] = _('Reversal of: %s', self.refunded_order_ids.account_move.name)

self.refunded_order_ids.account_move.name is supposed to be a singleton, but in the case where a transaction has several refund order, this isn't the case anymore, causing the error.

## Explanation of the fix

After the fix, when you select a second refund after selecting one, the previous one will be replaced by the current one, preventing users to select 2 refunds in the same transaction. In the code, this is translated as:
in the point_of_sale/static/src/app/screens/ticket_screen.js file, in the onDoRefund() function, when a refund (= orderline) is created, we check that there are less than 2. If not, we remove the previous ones.

______________________________________________________________
opw-4791231

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:

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

#refund#pos#transaction

[FIX] sale: track changes on draft quotations

PR #258928

Core17.0saleMedium

This update fixes a bug preventing changes to Sales Orders (customer, state) in draft mode from being logged in the chatter. The previous system suppressed all tracking data, but this change ensures that user-initiated modifications are accurately recorded for better auditability and communication. This improves transparency and collaboration around sales order updates.

Original PR description

**Problem:** Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled. **Steps to reproduce:** 1. Create a…

**Problem:**
Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled.

**Steps to reproduce:**
1. Create a Sales Order, do not confirm
2. Change the customer → no log in chatter
3. Confirm the SO, then cancel it
4. Set it back to Quotation → no log in chatter

**Current behavior:**
No chatter entry is created for either change.

**Expected behavior:**
Both changes should appear in the chatter since `partner_id` (tracking=1) and `state` (tracking=3) have tracking enabled.

**Cause of the issue:**
`_track_finalize` discards ALL tracking data whenever the SO is in `draft` state. This was originally intended to avoid noise from catalog product additions, but it also suppresses legitimate field changes like customer updates and state transitions back to draft.

**Fix:**
Instead of blanket-suppressing all tracking on draft SOs, only discard tracking when the change originates from the product catalog (`_update_order_line_info`), which sets a `catalog_skip_tracking` context flag. This preserves the original noise-reduction intent while allowing real user-initiated field changes to be tracked.

Backport of: 311bf3426fb241cd5036db58c6c317fe0e81ab87

opw-6106537

[FIX] orm,account,l10n_it_edi: stops rounding the discount on import

PR #256037

Core17.0accountl10n_it_ediMedium

This update resolves an issue where discounts weren't being imported accurately due to rounding discrepancies. The fix ensures that discount amounts are imported exactly as they appear on the original invoice, preventing subtotal mismatches. This improves data integrity during invoice processing, particularly for Italian VAT imports.

Original PR description

**PROBLEM**
When importing an invoice, we don't want to round the discounts, to avoid discrepancy between the subtotal computed by Odoo, and the subtotal of the file we import. To do this, we change the decimal precision of discount to 100 digits when importing files. However, float_round wasn't built with this in mind, in float round, we add a small epsilon to fix some rounding issue. This small epsilon changes the amount of the discount (50.0 -> 0.5000000000004) and this changes the subtotal.

**STEP TO REPRODUCE**
1. Install l10n_edi_it.
2. Change the VAT number of IT Company to 05098540288 (to match the one on the file to import).
3. Import the file present in the bug ticket.
4. Notice the subtotal of the line doesn't match what's in the invoice.

**FIX**
We skip rounding of the discount on import.

Ticket [link](https://www.odoo.com/odoo/project.task/6046324)
opw-6046324

#import#discount#vat

[FIX] sale_amazon(,_channel_management): wrong fulfillment channel (2)

PR #114473

Enterprise17.0sale_amazonsale_amazon_channel_managementMedium

This update resolves an issue where stock synchronization with Amazon was failing due to incorrect fulfillment channel data. The system now uses a more reliable field from the Amazon Listings API to determine channel availability, defaulting to FBM when necessary to ensure stock remains synchronized. This change also improves the process of updating FBM stock configurations.

Original PR description

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359

After the fix, when selecting multiple refunds not belonging to a same order, a user error will appear, preventing an odoo error later in the flow. _____________________________________________________ ## Short functional explanation of the error Selecting several refunds from the same customer in the same transaction, and making sure to print an invoice at every operation caused an error. ## Reproduction Steps 1. Go to the point of sales module, and create an order for a specific customer. Proceed to the payment and make sure that finalizing the payment will create an invoice, before confirming the payment. 2. Create a second order for the same customer, and proceed the same way as in step 1. 3. On the product screen, click on "refund". 4. Select one order that you've just completed. Then, setup the quantity at 1 and click on refund. 5. Do step 4 again but this time, select the second order that you've just completed. 6. Click on payment, then click on invoice then try to validate the payment. The error occurs: Expected singleton: account.move(720, 722) Traceback (most recent call last): File "/data/build/odoo/odoo/models.py", line 5896, in ensure_one _id, = self._ids ValueError: too many values to unpack (expected 1) ## Causes of the problem It is due to an ensure_one() in python. Indeed, in the file point_of_sale/models/pos_order.py,in the function _prepare_invoice_vals(self), an error occured on the line: vals['ref'] = _('Reversal of: %s', self.refunded_order_ids.account_move.name) self.refunded_order_ids.account_move.name is supposed to be a singleton, but in the case where a transaction has several refund order, this isn't the case anymore, causing the error. ## Explanation of the fix After the fix, when you select a second refund after selecting one, the previous one will be replaced by the current one, preventing users to select 2 refunds in the same transaction. In the code, this is translated as: in the point_of_sale/static/src/app/screens/ticket_screen.js file, in the onDoRefund() function, when a refund (= orderline) is created, we check that there are less than 2. If not, we remove the previous ones. ______________________________________________________________ opw-4791231 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Problem:** Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled. **Steps to reproduce:** 1. Create a Sales Order, do not confirm 2. Change the customer → no log in chatter 3. Confirm the SO, then cancel it 4. Set it back to Quotation → no log in chatter **Current behavior:** No chatter entry is created for either change. **Expected behavior:** Both changes should appear in the chatter since `partner_id` (tracking=1) and `state` (tracking=3) have tracking enabled. **Cause of the issue:** `_track_finalize` discards ALL tracking data whenever the SO is in `draft` state. This was originally intended to avoid noise from catalog product additions, but it also suppresses legitimate field changes like customer updates and state transitions back to draft. **Fix:** Instead of blanket-suppressing all tracking on draft SOs, only discard tracking when the change originates from the product catalog (`_update_order_line_info`), which sets a `catalog_skip_tracking` context flag. This preserves the original noise-reduction intent while allowing real user-initiated field changes to be tracked. Backport of: 311bf3426fb241cd5036db58c6c317fe0e81ab87 opw-6106537

**PROBLEM** When importing an invoice, we don't want to round the discounts, to avoid discrepancy between the subtotal computed by Odoo, and the subtotal of the file we import. To do this, we change the decimal precision of discount to 100 digits when importing files. However, float_round wasn't built with this in mind, in float round, we add a small epsilon to fix some rounding issue. This small epsilon changes the amount of the discount (50.0 -> 0.5000000000004) and this changes the subtotal. **STEP TO REPRODUCE** 1. Install l10n_edi_it. 2. Change the VAT number of IT Company to 05098540288 (to match the one on the file to import). 3. Import the file present in the bug ticket. 4. Notice the subtotal of the line doesn't match what's in the invoice. **FIX** We skip rounding of the discount on import. Ticket [link](https://www.odoo.com/odoo/project.task/6046324) opw-6046324

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359