Wednesday, December 10, 2025
8 changes · 18.0
Resolved issues and error corrections
This update fixes an issue where the order partner wasn't being correctly updated in the backend after scanning the online payment QR code. Previously, changes to the partner were not reflected in the order details. Now, the system accurately records the updated partner, ensuring accurate transaction tracking.
Original PR description
# Steps to Reproduce 1. Configure a payment method as **Online Payment**. 2. Select a customer and proceed to pay the order. 3. The QR code for online payment is generated. 4. Note: the partner is correctly loaded in the backend. 5. Close the QR popup and change the partner. 6. Scan the QR again and proceed to pay. # Expected Behavior - The transaction should reflect the updated partner, not the previous one. # Actual Behavior - The transaction is recorded under the previous partner. - The partner is not updated in the order. # Issue - Updating the partner does not immediately update the order in the backend from the POS UI. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where downpayment invoices weren't correctly reflected in the 'Un-invoiced Balance' calculation within the sales quotation. The fix ensures that downpayments are now accurately considered when determining the amount still outstanding, improving invoice accuracy and reporting. This impacts how sales balances are tracked.
Original PR description
#### Versions: 18.0+ ### Issue: Sales' uninvoiced balance (`amount_to_invoice`) is not updated with downpayments. #### Steps to reproduce: Requires Studio - Enter the Sales app: - Change the list view with Studio: - Add the field `Un-invoiced Balance` (amount_to_invoice) as a new column. - Create a new quotation with a product having the `Ordered quantities` invoicing policy; - Confirm the quote; - Create and confirm a downpayment invoice based on fixed amount; - Go back to the quotation list view: - The "Un-invoiced Balance" field is not updated and still shows the total amount of the quotation. ### Cause: Downpayments have no quantity, so they are not considered in the computation of the uninvoiced balance as they are set to 0 in the method `_compute_amount_to_invoice`: https://github.com/odoo/odoo/blob/70d16283b58ab8f379279de54de81bdb680e0887/addons/sale/models/sale_order_line.py#L1146 opw-5274918
This update fixes a problem where payments weren't always being linked to the correct bank account, specifically for tax payments. The change ensures that payments are accurately associated with the intended recipient's bank account, preventing financial discrepancies and improving payment processing reliability. This resolves an issue that could have resulted in incorrect financial records.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Avoid payment wrong initialization when a default value has been set to initialize the `account.payment.register`. Indeed, the `account.payment` also has a `partner_bank_id` property, and so the method `_create_payment`of the `account.payment.register` can initialize payment with wrong `partner_bank_id`. [enterprise#99373](https://github.com/odoo/enterprise/pull/99373) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220)
This update fixes an issue where payroll payments were incorrectly linked to the employee's bank account instead of the correct vendor account (like the IRS). The change ensures payments are accurately assigned to the appropriate bank account, resolving a payment processing error and improving financial accuracy. Automated tests have been added to verify this fix.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`. Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. ## Tests Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error. This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment. [community#235475](https://github.com/odoo/odoo/pull/235475) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220)
This update resolves issues where changes to cover images in nested cards were incorrectly applied to other cards, or where settings leaked between parent and child cards. The fix ensures that image adjustments are now isolated to the specific card being edited, improving the editing experience and preventing unexpected behavior.
Original PR description
This commit fixes three issues occurring when editing nested `s_card` snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover image…
This commit fixes three issues occurring when editing nested `s_card` snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover image option if it contained a child `s_card` with a cover image. Cause: The `querySelector` in `CardImageOption` could detect images inside child snippets. Fix: Now the `querySelector` only searches among direct children of the snippet root element. **Problem 2 - Ratio settings applied to all child cards** Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested cards. Cause: The `we-select` in `s_card` options targeted `.o_card_img_wrapper`, causing the class to apply to all descendants. Fix: The selector is now `>.o_card_img_wrapper`, so the option acts only on the current snippet. **Problem 3 - Parent image positioning leaking to children** Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images. Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements matching `.o_card_img_wrapper`. Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`. task-5349540
This update resolves an issue where SN labels weren't generated and printed correctly when producing multiple units of a product through the manufacturing process. The fix ensures that SN labels are consistently printed for MOs with quantities greater than one, preventing data discrepancies and streamlining production tracking. This improves the accuracy of lot and serial number management.
Original PR description
This commit fixes the issue of not printing Lot/SN labels when generating them on the MO that has more than 1 unit on the quantity to produce. To reproduce the bug: 1- Go to Operation Types → Manufacturing → Hardware → activate the print `Lot/SN Label` (Print When "Create New Lot/SN") 2- Create an MO with quantity of 5 for a tracked product. 3- Click on `Produce All` and use the wizard to generate SNs and produce or confirm the MO. = SNs should be printed but they are not. opw-5347787
This update removes a restriction on displayed stock quantities in the Odoo Enterprise system. Previously, quantities were limited to sublocations within an operation, but this has been removed to provide users with a more complete view of their stock levels. This change ensures accurate stock tracking and reporting.
Original PR description
In order to fix an issue with stock move line's quants not correctly recomputed, the PR odoo/enterprise#95906 backported a part of 18.2 PR odoo/enterprise#55917. The issue is, this PR also backported unwanted changes, like the restriction of displayed quants. Starting with the 18.2, the displayed quants are restricted to the current operation's sublocations because in this version, clicking on a quant updates the move line's fields. This feature doesn't exist prior to the 18.2 and so, the restriction is not needed. This commit removes this part of the field's compute so users have better visibility of where are their quants. [opw-5357557](https://www.odoo.com/odoo/project.task/5357557)
This update corrects a bug where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly when using unreserved products. The fix prevents multiple validation attempts, ensuring accurate stock tracking and avoiding data inconsistencies. This improves the reliability of transfer processing.
Original PR description
**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696
Forward-Port-Of: odoo/enterprise#95329