Saturday, September 5, 2026
7 changes · saas-19.1
Resolved issues and error corrections
Flow 10 reports now check unsupported tax rates before sending and keep VAT breakdowns aligned with invoice totals. This helps French e-invoicing reports avoid inconsistent tax summaries and preserves exemption details in the generated XML.
Original PR description
Flow 10 reports currently send unsupported custom tax rates without reporting an error on the related journal entry. Untaxed invoice lines also produce a zero taxable amount, which makes the VAT breakdown inconsistent with the invoice total. Exemption reasons without a code are omitted from the XML. Validate tax rates before sending. Include the base of untaxed lines in the tax summary and preserve exemption reasons so the generated totals and VAT breakdown remain consistent. No Task id Forward-Port-Of: odoo/odoo#286547
The Luxembourg Balance Sheet now places own shares and related undertaking shares in the correct investment categories. This improves the accuracy of statutory financial reports and helps businesses avoid misclassified balances in official filings.
Original PR description
Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch…
Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch to the `LU Company`. - Navigate to Accounting > Accounting > Journal Entries and create and post two journal entries: - One with account `502000 Own shares or own corporate units`. - Another with account `503000 Shares in undertakings with which...`. - Navigate to Reporting > Balance Sheet and check the `III. Investments` section. **Observation:** - `502000 (Own shares...)` is wrongly added under `3. Other investments`. - `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`. In the generated XML report: - `502000 (Own shares...)` balance is added inside `<NumericField id="195">`. - `503000 (Shares in undertakings...)` balance is added inside `<NumericField id="209">`. **Expected behavior:** According to the Luxembourg documentation mapping tables [1], - Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`. - Account `503000 (Shares in undertakings...)` should be mapped to `<NumericField id="195">`. **Root Cause:** At [2], the `account_codes_formula` values are incorrectly assigned: account code `503` is mapped under `2. Own shares`, while account code `502` is mapped under `3. Other investments`. This reverses the expected mapping of the two accounts in the Balance Sheet report. [1]: https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables [2]: https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348 opw-6275340 Forward-Port-Of: odoo/enterprise#128386
Fixed an issue in Planning where adding the Employees filter by default in the Gantt view could prevent multi-create or multi-edit actions from working. This helps managers reliably schedule multiple shifts even when the default employee-focused view is enabled.
Original PR description
## Step to reproduce: - Install Planning - Add "Employees" filter by default to a Gantt ## Result: The multi-create does not work because isManager does not resolve due to the early [return](https://github.com/odoo/enterprise/blob/0bee2f47c7e9d0b9a8d171fccde398a680a73415/planning/static/src/views/planning_gantt/planning_gantt_model.js#L60-L63) task-6535800 Forward-Port-Of: odoo/enterprise#130369
This fix ensures changes to default values in website form fields are properly reversed when users undo their edits. It also prevents old date values from lingering when switching form field types, making the website builder behave more reliably.
Original PR description
The `value` property of the elements is not tracked by the history plugin, because `MutationObserver` does not produce mutations for that. This commit uses custom mutations when the `value` is changed, to restore the previous value on undo. Steps to reproduce: - Open website builder - Add a form - Set a "Default Value" on a text field - Press enter (to end preview) - Undo (with the button, or with focus out of the option's input) - Bug: The value shown in the page did not revert with undo Similar bug in translate mode task-6229671 Forward-Port-Of: odoo/odoo#286542 Forward-Port-Of: odoo/odoo#281232
French PDP Flow 10 now classifies vendor bills and credit notes using the correct document type, preventing purchase invoices from being reported as credit notes. This reduces the risk of electronic invoices being rejected because they appear to reference a missing prior invoice.
Original PR description
Flow 10 used move.is_inbound() to distinguish invoices from credit notes. While this gives the expected result for sales documents, it reverses the codes for purchase documents. Vendor bills were therefore reported as credit notes and could be rejected for having no preceding invoice reference. Determine the document kind from move_type instead. Regular invoices now use code 380 and credit notes code 381. Self-billed invoices and credit notes use codes 389 and 261 respectively. No Task id Forward-Port-Of: odoo/odoo#286526
The Belgian Codabox integration now checks the actual last SODA import date when fetching new salary statements. This prevents statements generated earlier in an accounting period from being skipped, helping companies keep payroll accounting imports complete.
Original PR description
Before v19.1, we used to set the date on the journal entry based on the generation date of the SODA statement during the import. So it was possible to use the last date found in the salary journal as a `date_from` filter when fetching new SODA statements. Starting from v19.1, we now set the date on the journal entry as the last day of the accounting period referenced in the SODA file. However, we didn't change the fetching logic accordingly. If a SODA statement is generated on July 7 for the accounting period of July, the date on the journal entry would be July 31 and, consequently, any other SODA statement generated in-between those dates would be filtered out during the fetch. Ticket: opw-6214589
Generating Norwegian SAF-T reports could fail when journal entries used current asset accounts. The fix excludes those entries from the affected SAF-T partner account logic, preventing the report error and restoring reliable export generation.
Original PR description
Currently, an error occurs when generating the SAF-T report for a journal entries with the `asset_current` account type. **Steps to reproduce:** - Install `l10n_no_saft` and `accountant` modules and…
Currently, an error occurs when generating the SAF-T report for a journal entries with the `asset_current` account type. **Steps to reproduce:** - Install `l10n_no_saft` and `accountant` modules and switch to a NO Company. - Go to Contacts and set the ZIP code and state, then add a contact for the NO Company record. - Create a new Journal Entry, click `Add a line`, and set an account of type `Current Assets` (e.g., `1000 Development, acquired`) with the partner set to the NO Company. - Navigate to Reporting > General Ledger. - Click the gear icon and select `SAF-T`. **Error:** `KeyError: 'accounts'` **Root Cause:** At [1], from `19.0`, `asset_current` was mistakenly included in the second-to-last account type condition of the domain. As a result, partners linked to `asset_current` accounts are included in the `customer_vals_list` at [2]. However, `_l10n_no_saft_get_partners_accounts()` at [3] does not retrieve accounts of type `asset_current`. Therefore, when the `if` condition is not satisfied, the `accounts` key is not added to `partner_vals`. Since the partner has already been added to `customer_vals_list` at [2], the SAF-T template at [4] later tries to access `partner_vals['accounts']` when generating the `BalanceAccount` nodes, resulting in the error. **Fix:** This commit prevents the error by removing `asset_current` from the domain, similar to previous versions. [1]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L307-L313 [2]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L356-L362 [3]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/models/account_general_ledger.py#L37-L42 [4]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/data/saft_report.xml#L27-L37 opw-6441743 Forward-Port-Of: odoo/enterprise#127744