Tuesday, October 21, 2025
10 changes · saas-18.2
Resolved issues and error corrections
Customers paying overdue invoices from the portal now see and pay only the remaining unpaid balance, not the original full invoice total. This prevents accidental overpayments when invoices have already been partially paid and keeps related payment records accurate.
Original PR description
Issue: When customer pays overdue amount from the portal, it shows the total amount of the overdue invoices. However, if overdue invoices are partially paid then the customer of the invoices would be overpaying. Purpose of this PR: We should display the residual amount of the overdue invoices so that when the transaction and payment records are created, they are created with the residual amounts of the overdue invoices and not the total amount of invoices. Steps to Reproduce on Runbot: create an invoice for Joel Willis that is overdue. partially pay for the invoice. go to the portal view with Joel Willis logged in and click 'Pay Overdue' the amount shown at the top and the corresponding transaction and payment records will have the total amount of the invoice. opw-4745031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210702
Customers who return to checkout and switch delivery addresses after payment navigation are no longer shown a technical error. Instead, if the cart is no longer available, they are safely sent back to the shop so they can continue browsing or restart checkout.
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
Fixed payment registration so saved payment methods are matched to the customer on the invoice, not the company partner shown on the payment line. This lets users reuse stored payment tokens when registering payments for repeat invoices, reducing failed or manual payment handling.
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
Spanish Facturae e-invoicing tax classifications are now loaded correctly for relevant Spanish tax templates, including mainland and Canary Islands setups. This helps ensure electronic invoices use the right tax information and avoids applying Facturae tax values to unrelated taxes.
Original PR description
Currently the tax data defined in l10n_es_edi_facturae is incomplete and never loaded. This commit makes sure that the l10n_es_edi_facturae_tax_type is loaded correctly and adds the appropriate templates for es_common_mainland and es_canary_common. The default is also removed on the field l10n_es_edi_facturae_tax_type to avoid the value being assigned for unrelated taxes. task-4981325 Forward-Port-Of: odoo/odoo#231277
Job applications created by email now keep the company from the job position when the linked department has no company set. This prevents missing company information that could block adding recruiters or interviewers to the application.
Original PR description
When an applicant applied to a job position with a company_id and department_id, but the department itself had no company_id set, the application would have company_id set to False rather than the company_id from the job position. This caused bunch of issues such as the inability to add a recruiter or interviewers to the application.The bug seems to come from the default values created in the method `_alias_get_creation_values` on the job position, which sets the default company_id to the department's company_id when the job has a department that can result in False when the department exists but has no company set. task-5184275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Email loop detection now counts only actual email messages, not other internal message types. This prevents legitimate incoming emails from being blocked too early because unrelated messages inflated the loop counter.
Original PR description
When detecting loops with _detect_loop_sender if the count of these messages exceeds the LOOP_THRESHOLD, the next email from that user is blocked, even if the number of new emails alone hasn't yet crossed the threshold due to mail messages that are not email triggering the loop detection. This happens because it searches for messages in the mail.message model that share the same model name and author irrespective of the message type. To correct this, the function's search criteria must be modified to explicitly filter for messages where the message_type is set to 'email'. opw-5122962 Forward-Port-Of: odoo/odoo#232026
This fix ensures Italian point-of-sale receipts are printed correctly when the cash drawer option is enabled. It prevents sales from being disrupted for businesses using Italian fiscal printers with connected cash drawers.
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
Trial Balance PDF exports now respect the search filters entered by users, including account names, account codes, and account group names when hierarchy is enabled. This prevents exported reports from showing unrelated lines and helps finance teams produce accurate filtered PDFs.
Original PR description
### Issue: No filter is applied when exporting a PDF, although a filter from the filter_search_bar is provided. ### Step to reproduce: - Create an account group (e.g. Group_101 from 101 to 101) -…
### Issue: No filter is applied when exporting a PDF, although a filter from the filter_search_bar is provided. ### Step to reproduce: - Create an account group (e.g. Group_101 from 101 to 101) - Create some AML in an account related to the previously created group (e.g. in 101501 Cash) - Go to the Trial Balance - Add a filter including either an account name or account code (e.g. Cash), - Export to PDF - In the Options, select "Hierarchy and subtotals" - Add a filter including your group name (e.g. Group_101) - Export to PDF ### Current behaviour: - all lines are displayed in both PDF as the backend doesn't apply the filter ### Expected behaviour: - lines are displayed using groups and accounts names and codes to filter ### Cause: From the refactor of Trial Balance (see: https://github.com/odoo/enterprise/pull/73298), filter from filter_search_bar wasn't applied anymore. ### Solution: Bring back the domain to apply the filter that was used in the general ledger before the refactor. If hierarchy is enabled, fetch accounts where filter matches either account or group. As Group_id isn't stored, it requires an explicit computation. Some tests were made to merge the query from the field compute method and the one from this commit. However, as their `FROM` and `WHERE` clauses differ, it was a bit messy. opw-4906593 Forward-Port-Of: odoo/enterprise#93634 Forward-Port-Of: odoo/enterprise#90403
This fix ensures write-off entries created during journal item reconciliation are always treated as standard journal entries. It prevents errors in customized setups where a different default entry type could require extra information or reject certain accounts.
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 sender and customer VAT information, so commercial invoices generated for cross-border deliveries show the correct tax details. This helps businesses avoid missing VAT information on UPS documents and reduces manual follow-up.
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