Daily updates from Odoo
Thursday, August 6, 2026
2 changes · 17.0
Resolved issues and error corrections
Dutch SBR tax return exports now use the Tax Unit VAT number when a tax unit is selected, instead of incorrectly using the individual company's turnover tax number. This prevents fiscal unity returns from being rejected by the tax authority due to a mismatched identifier.
Original PR description
**Steps to reproduce:** * Install the **Netherlands - SBR** (`l10n_nl_reports_sbr`) and **Netherlands - SBR OB Nummer** (`l10n_nl_reports_sbr_ob_nummer`) modules. * Create two companies with Dutch…
**Steps to reproduce:** * Install the **Netherlands - SBR** (`l10n_nl_reports_sbr`) and **Netherlands - SBR OB Nummer** (`l10n_nl_reports_sbr_ob_nummer`) modules. * Create two companies with Dutch localization. * Go to **Accounting → Configuration → Tax Units** and create a Tax Unit with its own **Tax ID** (e.g. `NL826317558B01`), adding both companies. * On the main company form, fill in the **Omzetbelastingnummer** field (e.g. `123456782B90`). * Go to **Accounting → Reporting → Tax Return**, select the Tax Unit in the filter, and click **XBRL → Download XBRL File**. **Observed behavior:** * The `<xbrli:identifier>` in the exported XBRL file contains the company's **Omzetbelastingnummer** (`123456782B90`) instead of the Tax Unit's VAT (`826317558B01`). * The tax authority rejects the return because the identifier does not match the fiscal unity registration. **Cause:** * `_get_sbr_identifier()` in `l10n_nl_reports_sbr_ob_nummer` unconditionally returns `self.env.company.l10n_nl_reports_sbr_ob_nummer` before consulting the Tax Unit. * The `super()` call, which correctly routes to `tax_unit.vat` via `report.get_vat_for_export()`, is only reached when the company field is empty — so the Tax Unit's VAT is never used when a company OB-number is set. **Fix:** * When a Tax Unit is active in the report options, delegate immediately to `super()._get_sbr_identifier()`, which resolves `tax_unit.vat` through the existing `get_vat_for_export()` logic. * The company-level `l10n_nl_reports_sbr_ob_nummer` override is preserved as a fallback for the `company_only` (no Tax Unit) case. opw-6350840 Forward-Port-Of: odoo/enterprise#125167
Swiss bank payment files generated with the newer PAIN format will no longer include a service level code that banks reject. This helps Swiss customers avoid failed SEPA payment submissions when moving to the newer required payment file version.
Original PR description
Code `NURG` is rejected by Swiss banks. Issue comes back again because of the end of the transition period for PAIN.001: - transition `pain.001.001.03.ch.02` to `pain.001.001.09` - end of transition is November 14th 2026 Many customers complain that when they switch to PAIN version `pain.001.001.09`, their files are rejected because of invalid `NURG` code for `SvcLvl`. The fix was done long time ago, for Odoo 15, and is still there. But it targets only the old schema: - odoo/enterprise#57104 - odoo/enterprise#56704 And the big refactoring happened later, only for Odoo 18: - odoo/enterprise#60393 So this bugfix should land on branch 16.0 and be ported to 17.0 only. Forward-Port-Of: odoo/enterprise#126821