Sunday, October 12, 2025
4 changes · saas-18.3
Resolved issues and error corrections
The invoice payment button now points to the payment that is actually confirmed and reconciled, instead of an older draft payment in certain duplicate-payment workflows. This helps accounting users avoid confusion and reduces the risk of reviewing or acting on the wrong payment record.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/odoo#202076
Invoices now open the currently reconciled payment instead of an older draft duplicate when payments are reset, duplicated, and reconciled. This prevents users from being sent to the wrong payment record and helps keep invoice payment tracking accurate.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/enterprise#89089
Hierarchy views now better handle circular reporting relationships, such as an employee accidentally set as their own manager. This prevents crashes and endless loading loops, improving reliability for users viewing organization charts and other hierarchical data.
Original PR description
This commit fixes some traceback errors in the web_hierarchy module by refining the cycle detection of records in hierarchies. Infinite loops in case of a cycle's presence in the `removeChildNodes` and `processNode` methods are now prevented. Additionally, tree re-rooting in case of the presence of two nodes in the same tree, which implies a cycle's existence, is now avoided. There was an edge case where an employee could be their own manager, creating two child nodes of that employee. The case is now handled by making sure that records are unique for each parent ID in the `recordsPerParentId` object. task-5022670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231040 Forward-Port-Of: odoo/odoo#228976
Indian GST return processing now looks for a valid purchase journal across all companies in a tax unit, rather than only the main company. This prevents record creation failures when the main company lacks a purchase journal but another company in the tax unit has one configured.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit. OPW: 5159518 Forward-Port-Of: odoo/enterprise#96838