Friday, May 15, 2026
2 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where French Intrastat reports were missing crucial quantity data for products with supplementary units. The change ensures that all relevant data is included in the DEBWEB2 XML export, improving the accuracy of Intrastat reporting for French businesses. This resolves a discrepancy in how the system grouped and exported data, leading to incomplete reports.
Original PR description
Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set…
Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.
Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61
opw-6139657
Forward-Port-Of: odoo/enterprise#117033This update fixes an issue where project update descriptions incorrectly showed inflated budget totals after budget revisions. The fix ensures that only the active, confirmed budget revision is used, providing accurate budget information for project updates. This improves the reliability of project cost tracking.
Original PR description
**Problem:** When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting…
**Problem:** When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision. **Steps to reproduce:** 1. Create a project with an analytic account 2. Create an analytic budget of $10,000 and confirm it 3. Create a revision of that budget for $15,000 and confirm it 4. Create a new project update 5. The update shows "$25,000" as the total budget instead of "$15,000" **Current behavior:** The project update displays the sum of all budget revisions ($25,000), regardless of their state. **Expected behavior:** Only the active confirmed budget ($15,000) should be used. **Cause of the issue:** `_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent. **Fix:** Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows. opw-6128855 Forward-Port-Of: odoo/enterprise#115285