Monday, July 27, 2026
4 changes · 18.0
Resolved issues and error corrections
Customer follow-up reports now exclude invoices that have already been fully paid, even when they were paid as part of a grouped payment. This prevents customers from seeing settled invoices as still outstanding and makes follow-up communications more accurate.
Original PR description
Steps to reproduce: - Configure a bank journal with Outstanding Receipts/Payments accounts - Create two customer invoices for the same partner (e.g. 1000 and 2000) - Select both, Register Payment,…
Steps to reproduce: - Configure a bank journal with Outstanding Receipts/Payments accounts - Create two customer invoices for the same partner (e.g. 1000 and 2000) - Select both, Register Payment, enable Group Payments, pay 1500 so that the first invoice is fully paid and the second remains partially paid (1500 due) - Validate and reconcile the payment, then open the Customer Follow-up Report Issue: The fully paid invoice still shows up in the Follow-up Report, alongside the partially paid one. Cause: The report's 'unreconciled' domain (account.report. _get_options_unreconciled_domain) filters on full_reconcile_id, which is set per matching-number group rather than per line: when several invoices are settled together through a grouped payment, they all share the same matching number, and the group only gets a full_reconcile_id once *every* line in it is fully paid. Since the second invoice is still open, the group stays without a full_reconcile_id, so the first invoice is wrongly treated as unreconciled too, even though its own residual amount is zero. Fix: Override _get_aml_values on the Follow-up report handler to drop lines that are individually reconciled (amount_residual = 0), instead of relying on the group-level full_reconcile_id. The generic unreconciled domain is left untouched since Partner Ledger and Aged Receivable also rely on it and may depend on keeping partially settled matching groups grouped together. opw-6323401
Ecuador branch users can now create customer invoices without being blocked by an access error. The fix avoids requiring direct access to the parent company when checking the journal’s country, keeping normal accounting workflows working in branch setups.
Original PR description
Steps to reproduce: - Install `l10n_ec` module - Create one branch of the EC company - Give user(not admin) access to company branch and login with user - Go to Accounting > Customers > Invoices - Click New > AccessError Cause: This error occurs because the user is working within a branch of the main company. The code tries to access the journal’s company, which is set to the parent company. As the user does not have access to the parent company, fetching the country code fails. Solution: In some cases, strict company access rules cause `AccessError` and block normal flows, especially with parent–child company setups where a child needs data from the parent. To ensure smooth processing, we use a related field on the journal to retrieve the country code without directly accessing the company. opw-6087460
Ri.Ba. payment validation now accepts San Marino IBANs as well as Italian IBANs, preventing valid batch payments from being blocked. The payment file generation was also adjusted to keep San Marino records within the required format length.
Original PR description
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a…
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a Batch Payment using the Ri.Ba. payment method. - Validate the Batch Payment. **_Observed behavior :_** The validation fails with the error: `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments` **_Cause :_** The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs. **_Fix :_** - Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files. - While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format. **_opw_** - 6303820
This fixes where Mexican CFDI invoice fields are placed so they no longer disappear when Colombian electronic invoicing is also installed. It ensures users can reliably see and use the CFDI Origin field on Mexican invoices regardless of other localization modules.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269 Forward-Port-Of: odoo/enterprise#124545