Tuesday, October 21, 2025
13 changes · saas-18.3
Resolved issues and error corrections
Customers who navigate back during checkout and choose another delivery address are now handled safely instead of seeing an error page. If the cart is no longer available, the shopper is redirected back to the shop, reducing checkout disruption and support incidents.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801 Forward-Port-Of: odoo/odoo#226781
Spanish Facturae invoice XML now uses the correct total tax amount when global tax rounding is enabled. This prevents mismatches between invoice totals and the electronic invoice file, reducing the risk of rejected or inaccurate e-invoices.
Original PR description
When `l10n_es_edi_facturae` is installed, creating an invoice with 25 identical lines (price_unit: 230.83, quantity: 1, tax: 21%) and global tax rounding enabled results in: - Untaxed amount: 5770.75 - Tax amount (globally rounded): 1211.86 However, the generated Facturae XML incorrectly reports `TotalTaxOutputs` as 1211.75, as if tax was rounded per line. This was caused by the `_l10n_es_edi_facturae_export_facturae` method which round lines individually before the summing them even if the rounding method is global. opw-5111038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adjusts Swiss payroll employee views so payroll data can be handled correctly in environments with more than one company or country. It helps businesses using Odoo payroll in Switzerland avoid configuration or visibility issues when operating across multiple entities.
Original PR description
task-5159023 Forward-Port-Of: odoo/enterprise#97489 Forward-Port-Of: odoo/enterprise#96733
This fixes an issue where saved payment methods were not offered when registering payment for an invoice tied to an individual contact within a company. The payment form now uses the invoice's actual customer, helping users reuse stored payment details correctly.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
The returns wizard now generates all applicable returns from the opening date chosen by the user, instead of limiting results to the current fiscal year. This helps businesses produce complete return periods when starting or reopening accounting from a specific date.
Original PR description
If the user generates the returns with the wizard of the opening date, he expects to generate all the returns from this date, and not just for the current fiscal year like it used to be. backport of a request of task 5030701
A new action is available on the accounting returns screen so users can create returns directly when needed. This makes the process easier and avoids relying only on automated or indirect creation flows.
Original PR description
Add a new button on the returns view to create new returns. task-4627315
Italian point-of-sale setups using a fiscal printer and cash drawer now print receipts correctly when completing a sale. This prevents checkout interruptions for businesses that need the cash drawer option enabled.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480 Forward-Port-Of: odoo/enterprise#97379
This change prevents spreadsheet print styling from interfering with other areas of Odoo by removing it from a shared backend asset bundle. It helps avoid blank pages when printing or exporting content while keeping spreadsheet printing available through its dedicated print setup.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing Print Assets (Public View)** The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode. ### Fix This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle. The remaining issues are tackled in odoo/enterprise#92665 opw-4816241 Forward-Port-Of: odoo/odoo#230552 Forward-Port-Of: odoo/odoo#223434
Public and portal users can now print or export shared Knowledge articles without getting blank pages. The update fixes missing print styling and removes a Planning style conflict, improving reliability for shared article access.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#96625 Forward-Port-Of: odoo/enterprise#92665
Accounting users can now create SEPA Direct Debit mandates without encountering an access error. This ensures authorized invoicing and banking staff can complete mandate setup without requiring administrator permissions.
Original PR description
Have the Payment Provider Sepa Direct Debit module installed. Connect with a user with access right for Accounting: Invoicing & Banks. Create a Direct Debit Mandate => Get an access error. Reason: the compute does a read_group with a value on payment.provider, which non System Admin have no access to. Solution: Add a sudo for these _read_group
VoIP contact search now combines phone keypad search terms correctly with other contact filters. This should make matching contacts appear more reliably when users search from VoIP.
Original PR description
t9_search should be ORed to the subdomain, which in turn should be ANDed to the domain. Currently, both the subdomain and the t9_search are ANDed to the domain, resulting in a "subdomain AND t9_search" condition, which is not correct and unlikely to match anything.
This fixes an issue where reconciling journal items could fail in setups with customized default journal entry types. The reconciliation wizard now consistently creates write-offs as standard journal entries, reducing interruptions for accounting users.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
UPS shipment requests now include the company's and customer's VAT details, so commercial invoices generated for international deliveries show the correct tax information. This helps businesses avoid incomplete shipping documents and reduces manual follow-up for cross-border shipments.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356