Friday, April 24, 2026
7 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where VAT reports were incorrectly using the company's VAT number instead of the fiscal position's foreign VAT ID. This ensures accurate tax reporting for businesses using foreign VAT schemes, particularly in countries like Belgium. The change corrects a data mismatch in generated reports.
Original PR description
### Issue: When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead For example, with a Belgian fiscal position using…
### Issue: When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040` ### Cause: The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report ### Note: The example above uses a Belgian fiscal position to reproduce the issue Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default A related fix makes the Intervat settings available in that case Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15 ### Steps to reproduce: - Disable demo data and install `accountant` - Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040) - Click the alert to install the Belgian taxes - Create and confirm an invoice for a Belgian customer: - Fiscal Position: Belgium - Any product with a Belgian tax - Invoice Date: 01/01/2026 - Open the Tax Report and select `VAT Return (BE)` for January - Click `Returns` and select the full year - Mark the December return as Completed from the three-dot menu - Review January and fill the missing company data (TIN: 1111111, phone and email) - Click `Validate -> Lock -> Submit` ### Before the fix: The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`). opw-6076540 Forward-Port-Of: odoo/enterprise#112610
This update addresses a critical issue where Odoo would crash when attempting to download a URL document alongside a spreadsheet. The fix ensures stable and reliable downloading of both document types, improving user experience and preventing data loss. This resolves a reported bug impacting users accessing and sharing documents.
Original PR description
Try to download a url document along with a spreadsheet. `onDownload` crash when trying to download a url document. Task: 5485662 Forward-Port-Of: odoo/enterprise#113645 Forward-Port-Of: odoo/enterprise#112513
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The fix ensures accurate tax return calculations by isolating company-specific rounding data.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#110652
This update fixes a security issue where unauthorized users could access asset information within invoices. Now, access to assets is restricted to specific user groups within the accounting module, preventing potential data breaches and ensuring data integrity. This change enhances the security of our invoicing process.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#113858 Forward-Port-Of: odoo/enterprise#112890
This update resolves an issue where the DIAN web service was incorrectly overwriting customer contact information (names and emails) with fiscal data, leading to data loss and incorrect invoice delivery. The fix now intelligently handles email differences, creating a new contact if needed and giving users control over their existing data.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005 Forward-Port-Of: odoo/enterprise#114017
This update resolves an issue where the minimum IS (Insurance Savings) amount was incorrectly calculated in the Swiss payroll module. The change ensures accurate IS calculations for Swiss employees, aligning with local tax regulations. This update improves the reliability of payroll reporting for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
This update fixes a problem where opening a restaurant order with an active Fiskaly transaction on a second device would cause duplicate transaction attempts and errors. The fix ensures that transaction state information is properly saved and shared between devices, preventing these errors and improving the reliability of the POS system.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#114911 Forward-Port-Of: odoo/enterprise#114599