Odoo Changelog — 2025-08-28

Thursday, August 28, 2025

3 changes · saas-18.1

Bug Fixes(3)

Resolved issues and error corrections

[FIX] account_payment: preserve vendor payment number after modification

Coresaas-18.1accountaccount_paymentMedium

Vendor payments now keep their original payment number when they are edited and reposted, even when an Outstanding Payments account is configured. This prevents confusing number changes and helps accounting records remain consistent with the original transaction history.

Original PR description

**Steps to Reproduce**
1.Install the Accounting module.
2.Go to Accounting > Configuration > Journals, and open a Bank journal.
3.In the Outgoing Payments tab, set an Outstanding Payments Account.
4.Go to Accounting > Vendors > Payments.
5.Create and post two vendor payments (e.g., 00001 and 00002).
6.Reset the first one (00001) to draft, change any field (e.g., amount), and repost it.
7.The number changes to 00003 instead of preserving 00001.

**Root Cause**
When a vendor payment is modified and reposted, Odoo cancels and regenerates the associated account.move. If an Outstanding Payments account is configured — or was configured at any point — this triggers additional logic causing the move name to be reset to '/'. This placeholder indicates that the move is treated as if it were new, prompting Odoo to assign it the next number in the journal’s sequence. As a result, the payment loses its original number even though it conceptually refers to the same transaction.

**Fix**
The fix ensures the original number is preserved by restoring the payment's previous name only when it's clear that the move is being regenerated, not newly created. This is determined by checking that the move is linked to exactly one payment (i.e., a one-to-one relationship) and that its name is '/', indicating the move was regenerated.

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

Forward-Port-Of: odoo/odoo#211629

#vendor payments#payment numbering#accounting

[FIX] pos_restaurant: fix order table transferring

PR #211713

Coresaas-18.1pos_restaurantpoint_of_saleMedium

Restaurant staff can now transfer an order from one table to another more reliably, even when the network is slow. This prevents orders from appearing lost or unavailable after a quick table transfer, reducing checkout and service disruptions.

Original PR description

Before this change, when transferring a command from one table to
another, the order was not saved correctly if the network was slow.

As we no longer wait for the command to be synchronized, the transfer of
the table was reset when the RPC call was not completed on time.

This leads to an error when the user is on the product screen of the new
table, as the order is not found due to the reset.

Details:
- Click transfer button leave the table and launch a SYNC RPC.
- Click to fast on another table to transfer the order will mount the
  product screen of the new table. Which will read the current state of
  the order. If the first RPC is not completed, the order state is still
  the old one, and the transfer is not done.

#restaurant#table transfer#slow network#orders

[FIX] stock_barcode: convert uom in barcode package

PR #89558

Enterprisesaas-18.1stock_barcodeMedium

Scanning a package in the Barcode app now correctly converts quantities when the package and transfer line use different units of measure. This prevents inventory operators from seeing or validating incorrect partial quantities, such as 10 g instead of 10,000 g.

Original PR description

**Problem:** when scanning a package with a different uom than the barcode line, the conversion is not made **Steps to reproduce:** - enable the "packages" settings - create a new storable product…

**Problem:**
when scanning a package with a different uom
than the barcode line, the conversion is not made

**Steps to reproduce:**
- enable the "packages" settings
- create a new storable product and set  uom of kg
- click on the on hand smart button
- add a new line
- in the package column create a new package
- set a quantity of 10 kg
- create a new internal transfer and select your product
- set a demand on 10000 and the uom of g
- mark as todo
- open the barcode app
- inside internal operations click on your move
- scan the name of the pack

**Current behavior:**
the quantity on the line is now 10/10000g

**Expected behavior:**
it should be 10000/10000g

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505 remaining_qty is expressed in the uom of the quant so it will be 10 but qty_needed is expressed in the uom of the line is it will be 10000.
qty_used beeing the minimum of those two it will be 10.

**fix**
for the comparison to work we need to convert qty_needed before compairing.

Also we need to make sure that the line is updated with the quantity converted in its own uom.
Adding the uom to fieldsParam enables _udpdateLineQty to do the conversion
https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1669

opw-4860064

Forward-Port-Of: odoo/enterprise#89157
Forward-Port-Of: odoo/enterprise#87642

**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than preserving the original. This issue only occurs when the Outstanding Payments account is configured for the journal. **Steps to Reproduce** 1.Install the Accounting module. 2.Go to Accounting > Configuration > Journals, and open a Bank journal. 3.In the Outgoing Payments tab, set an Outstanding Payments Account. 4.Go to Accounting > Vendors > Payments. 5.Create and post two vendor payments (e.g., 00001 and 00002). 6.Reset the first one (00001) to draft, change any field (e.g., amount), and repost it. 7.The number changes to 00003 instead of preserving 00001. **Root Cause** When a vendor payment is modified and reposted, Odoo cancels and regenerates the associated account.move. If an Outstanding Payments account is configured — or was configured at any point — this triggers additional logic causing the move name to be reset to '/'. This placeholder indicates that the move is treated as if it were new, prompting Odoo to assign it the next number in the journal’s sequence. As a result, the payment loses its original number even though it conceptually refers to the same transaction. **Fix** The fix ensures the original number is preserved by restoring the payment's previous name only when it's clear that the move is being regenerated, not newly created. This is determined by checking that the move is linked to exactly one payment (i.e., a one-to-one relationship) and that its name is '/', indicating the move was regenerated. Opw-4805870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211629

Before this change, when transferring a command from one table to another, the order was not saved correctly if the network was slow. As we no longer wait for the command to be synchronized, the transfer of the table was reset when the RPC call was not completed on time. This leads to an error when the user is on the product screen of the new table, as the order is not found due to the reset. Details: - Click transfer button leave the table and launch a SYNC RPC. - Click to fast on another table to transfer the order will mount the product screen of the new table. Which will read the current state of the order. If the first RPC is not completed, the order state is still the old one, and the transfer is not done.

**Problem:** when scanning a package with a different uom than the barcode line, the conversion is not made **Steps to reproduce:** - enable the "packages" settings - create a new storable product and set uom of kg - click on the on hand smart button - add a new line - in the package column create a new package - set a quantity of 10 kg - create a new internal transfer and select your product - set a demand on 10000 and the uom of g - mark as todo - open the barcode app - inside internal operations click on your move - scan the name of the pack **Current behavior:** the quantity on the line is now 10/10000g **Expected behavior:** it should be 10000/10000g **Cause of the issue:** https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505 remaining_qty is expressed in the uom of the quant so it will be 10 but qty_needed is expressed in the uom of the line is it will be 10000. qty_used beeing the minimum of those two it will be 10. **fix** for the comparison to work we need to convert qty_needed before compairing. Also we need to make sure that the line is updated with the quantity converted in its own uom. Adding the uom to fieldsParam enables _udpdateLineQty to do the conversion https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1669 opw-4860064 Forward-Port-Of: odoo/enterprise#89157 Forward-Port-Of: odoo/enterprise#87642