Thursday, December 4, 2025
3 changes · saas-18.2
Resolved issues and error corrections
This update ensures the NIF (tax identification number) is now included in the BOE export for model 347 reports, as required by Spanish tax regulations. Previously, the system only included VAT, but this change corrects that to align with specific reporting requirements outlined in official documentation. Users are responsible for accurately entering the NIF in the company's VAT field.
Original PR description
[FIX] l10n_es_reports: include NIF in boe export for model 347 The NIF must be included in the BOE export for modelo 347 https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos/347.pdf pages 3 & 12. Before this commit, we read the vat but if it doesn't start with 'ES' we return an empty string because we based on TIN. Now we'll read the vat (without 'ES' if it starts with it). The user is responsible to fill a correct number in the vat field of the company. opw-5207241 Forward-Port-Of: odoo/enterprise#100489
This update resolves an issue where users couldn't assign analytic distributions to batch payments during bank reconciliation, leading to validation errors. The fix removes a restriction that was preventing edits to these payments, now allowing users to correctly apply analytics for improved financial reporting and tracking. This ensures accurate reconciliation processes.
Original PR description
**Issue** Users were unable to set analytic distributions on batch payments via the bank reconciliation widget. This limitation could lead to validation errors. **Steps to Reproduce** 1. Create two customer payments 2. Group them into a batch and validate it 3. Open the bank reconciliation widget 4. Create a bank statement line 5. Navigate to the batch payment tab and click on the batch payment 6. Attempt to click on the batch payment line **Root Cause** The method handleLineClicked was overridden in a way that prevented the call to the parent implementation when the flag was 'new_batch', disabling interactivity for these lines. **Fix** The restrictive override of handleLineClicked was removed. All fields in the Manual Operations tab are made read-only, except for analytic distributions, as this is the only field users should be allowed to edit in this context. Opw-4757131 Forward-Port-Of: odoo/enterprise#89858
This update fixes an issue where the VAT summary report for Argentinian invoices was incorrectly calculating totals when multiple IIBB taxes were applied. The fix ensures that VAT amounts are counted accurately, matching the totals displayed in the accounting form. This improves the reliability of financial reporting for Argentinian customers.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#97951 Forward-Port-Of: odoo/enterprise#85873