Daily updates from Odoo
Friday, May 15, 2026
4 changes · saas-18.2
Resolved issues and error corrections
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income.' The change ensures that depreciation entries (expenses) are now correctly classified within 'Other Operating Expenses,' providing accurate financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362
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
This update fixes a bug where previously validated manual transactions could incorrectly be matched with new transactions. The change ensures that manual counterpart lines are no longer suggested for matching with subsequent transactions, improving the accuracy of bank reconciliation. This resolves a potential issue with financial reporting.
Original PR description
Currently, after validating a transaction with a manual operation, the aml resulting from the manual operation can still be selected and matched with other transactions. Steps to reproduce: - Create a transaction for 500 dollars - Create a manual counterpart line for the bank statement line with label "test123" and validate - Create another transaction of -1000 dollars and label "test123" Issue: The manual counterpart line matched before is being suggested against the new transaction. The perfect match reconciliation model will reconcile the manual counterpart line with the new bank statement line. Adding test for community branch opw-6045050 Forward-Port-Of: odoo/enterprise#115847