Friday, September 4, 2026
12 changes · 19.0
Enhancements to existing features
Updates Finland’s mid-rate VAT from 14% to 13.5% to reflect the upcoming tax rate change. This helps Finnish accounting, invoicing, and tax reporting stay compliant with the new rate.
Original PR description
VAT rate for mid rate will change from 14% to 13.5% task-6517918
Resolved issues and error corrections
The SAF-T export now excludes current asset journal entries that previously caused the report generation to fail. This helps Norwegian companies produce the required audit file reliably when their general ledger includes these accounts.
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
The DHL REST shipping integration no longer creates a pickup request when arranging shipments. This aligns DHL with other carriers in Odoo and avoids extra scheduling steps and DHL errors when pickup windows are not configured.
Original PR description
Before this commit, the DHL REST module had the pick-up request set, which led to an unnatural use flow, needing to set up an scheduled date for pick-up, and several errors from DHL when these were not properly configured. This feature was unique to this module among the shipping carriers as we don't normally request pick-up for packages and leave it to user to decide how to do it. This commit removes the request for pick up and the logic that was needed to make it work. This will make the behavior consistent with other carriers in Odoo, and avoids the need to set scheduled pick-up windows and having to deal with unnecessary errors. opw-6148927 Forward-Port-Of: odoo/enterprise#123773
This fixes an issue in Planning where creating or editing multiple shifts in the Gantt view could fail when the default Employees filter was enabled. Managers can now use multi-edit reliably with that filter, reducing disruption during schedule planning.
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
This update refreshes Odoo's spreadsheet component with several bug fixes that improve chart handling, pivot table ranges, formula recalculation, and editing stability. Users should see fewer crashes and more accurate spreadsheet results, especially when working with charts, pivots, and formulas.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/39266880f2 [REL] 19.0.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/39266880f2 [REL] 19.0.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/952d78083d [FIX] carousel: cannot add non-existing chart to carousel [Task: 6455790](https://www.odoo.com/odoo/2328/tasks/6455790) https://github.com/odoo/o-spreadsheet/commit/b12bb0cfd7 [FIX] svg: avoid rjsmin issue caused by nested template literals [Task: 6317134](https://www.odoo.com/odoo/2328/tasks/6317134) https://github.com/odoo/o-spreadsheet/commit/efec68bc83 [FIX] chart: fix funnel chart show value [Task: 6475094](https://www.odoo.com/odoo/2328/tasks/6475094) https://github.com/odoo/o-spreadsheet/commit/1b987bbbcd [FIX] pivot: unbounded ranges in the pivot side panel [Task: 6478220](https://www.odoo.com/odoo/2328/tasks/6478220) https://github.com/odoo/o-spreadsheet/commit/fc1dc64b80 [FIX] composer: crash when hovering a composer token [Task: 5153319](https://www.odoo.com/odoo/2328/tasks/5153319) https://github.com/odoo/o-spreadsheet/commit/baf19d7431 [FIX] evaluation: wrong dependencies invalidation with spread formulas [Task: 5103328](https://www.odoo.com/odoo/2328/tasks/5103328) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
The event booth registration page now ignores outdated loading results when visitors switch booth categories quickly. This prevents the wrong booth list from appearing and avoids failed registrations or the need to reload the page.
Original PR description
Before this commit, the "Get A Booth" page of an event could keep listing the booths of the category checked on load after the visitor picks another one. Only a page reload brought the right ones…
Before this commit, the "Get A Booth" page of an event could keep listing the booths of the category checked on load after the visitor picks another one. Only a page reload brought the right ones back. The tour webooth_exhibitor_register timed out on that list: FAILED: [5/13] Tour webooth_exhibitor_register -> Step Choose Booth (trigger: .o_wbooth_booths div:contains(OpenWood Demonstrator 2) input:not(:visible)). TIMEOUT step failed to complete within 10000 ms. This happens because the page fetches the booths of the category checked on load, and clicking another category fetches its booths while that first answer is still on its way. The answer coming back last fills the list, and the widget caches it under the category active on arrival, so the booths of the first category land in the cache of the clicked one. This commit fixes the issue by caching an answer under the category it was asked for, and by filling the list only while that category is still the chosen one. https://runbot.odoo.com/odoo/error/110527 https://runbot.odoo.com/odoo/error/161834 Forward-Port-Of: odoo/odoo#286552 Forward-Port-Of: odoo/odoo#286266
Users managing bank reconciliation models from a foreign currency bank statement will now see the correct models linked to that journal. This fixes a filtering issue caused by currency labels being added to journal names, helping accounting teams manage reconciliation rules without confusion or missing entries.
Original PR description
### Issue before this commit: When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal. ### Steps…
### Issue before this commit: When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal. ### Steps to reproduce the issue: 1. Download Accounting 2. Go to Currencies and activate another currency like EUR 3. Go to Journals and create a new one with bank type and curency EUR 4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal 5. Go to test bank journal and create a new bank matching 6. After the line is created click the 3 dots and go to Manage Models 7. See that the new model Tester created does not appear ### Cause of the issue: Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100 ### Reason to introduce the fix: The filter is not working correctly. In this case it's better to change it to a domain instead of a default filter. opw-6481970
The website builder now correctly tracks changes to form field default values and translation field values so undo restores what users expect. This prevents stale values from remaining on the page after editing or switching date field types, reducing confusion while building websites.
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#281232
Refunds for valued products purchased in a foreign currency now avoid posting currency exchange differences to the stock valuation account when goods are returned. This keeps inventory valuation cleaner and prevents accounting distortions when exchange rates change between purchase and refund.
Original PR description
When refunding the purchase of a valued product that was received in a foreign currency. If the rate of the currency has changed between the purchase and the refund, the exchange difference line was impacting the valuation account. Steps to reproduce: ------------------- * Activate any other currency * Create a valued product and set a cost price * Create a purchase order in the foreign currency for the product * Confirm the purchase order and receive the product * Change the rate of the foreign currency * Create a return for the product and validate it > Observation: An exchange difference line is created and impacting the valuation account. Why the fix: ------------ When selecting the exchange account to use, we now check if we are in a return context. If it's he case we do not use the stock valuation account. opw-6313904 Forward-Port-Of: odoo/odoo#278047
Corrects a rounding mismatch in Mexican electronic invoicing payment complements for USD invoices paid in MXN. This prevents valid partial or exchange-rate-affected payments from being rejected by the certification provider with CRP20268.
Original PR description
**Steps to reproduce:** * Install the **l10n_mx** localization. * Enable **USD** and fetch the latest currency exchange rate from the settings. * Configure **Quadrum** as the **PAC** in the settings.…
**Steps to reproduce:**
* Install the **l10n_mx** localization.
* Enable **USD** and fetch the latest currency exchange rate from the settings.
* Configure **Quadrum** as the **PAC** in the settings.
* Create and sign a USD invoice with **16% IVA** (e.g. 4,500 USD + 720 USD tax = 5,220 USD total).
* Send the invoice to **CFDI**.
* Register a **partial MXN payment** that does not convert to a round USD amount (e.g. 30,000 MXN = 1,762.45 USD).
* Send the payment complement to the PAC by clicking **Update Payments** on the invoice.
**Observed behavior:**
The PAC rejects the CFDI with error **CRP20268**:
> El campo BaseP que corresponde a Traslado, no es igual a la suma de
> los importes de las bases registrados en los documentos relacionados
> donde el impuesto del documento relacionado sea igual al campo
> ImpuestoP de este elemento y la TasaOCuotaDR del documento
> relacionado sea igual al campo TasaOCuotaP de este elemento.
**Cause:**
* The SAT validator enforces a strict arithmetic relationship between three fields that are printed in the payment complement XML:
```
BaseP == round(BaseDR / EquivalenciaDR, 6)
```
* When `percentage_paid` is a non-terminating decimal (which happens for any partial MXN payment against a USD invoice), the internal `raw_base` float carries more precision than the 6-decimal-place `BaseDR` that is actually written to the XML:
```
percentage_paid = 1762.45 / 5220 = 0.33763409961685825...
raw_base = 4500 × 0.33763... = 1519.353448275862...
BaseDR (XML) = float_round(raw_base, 6) = 1519.353448
```
* The old code then used `raw_base` (the unrounded internal value) as the dividend when computing BaseP:
```
BaseP (old) = float_round(1519.353448275862... / 0.0587483333, 6)
= 25862.068980 ← written to <TrasladoP BaseP="...">
```
* The PAC performs the same division using only what it can read from the XML. The already-rounded BaseDR:
```
BaseP (PAC) = round(1519.353448 / 0.0587483333, 6)
= 25862.068975
```
* The 6th-decimal mismatch (25862.068980 ≠ 25862.068975) triggers CRP20268 and the document is rejected.
* The same issue occurs with a full MXN payment on a different date than the invoice when multiple invoice lines cause the rounded aggregate to diverge from the sum of per-line raw values.
**Fix:**
In `_l10n_mx_edi_add_payment_cfdi_values` (`account_move.py`), the block that builds the BaseP aggregation list was changed from iterating over raw per-`base_line` amounts to building a single synthetic entry per invoice using the already-rounded document-level `BaseDR` values (`tax_details['base']`) as the dividend:
- Before : wrong: raw_base ≠ BaseDR printed in the XML
'raw_base': tax_details['raw_base'] / inv_rate
- After : correct: 'base' == BaseDR, the exact value in the XML
'raw_base': tax_details['base'] / inv_rate
This guarantees that Odoo and the PAC divide the identical value, producing the identical 6-decimal result.
The `base_line_cfdi_values_mx_curr_list` path (used only for the `Totales` summary fields rounded to 2 dp) is left unchanged because the CRP20268 rule does not apply to that block.
opw-6468077
Forward-Port-Of: odoo/enterprise#128357This fixes an issue where importing multiple Belgian SODA files at once could copy lines from the first file into the next accounting entry. Each imported file now keeps its own lines, helping avoid incorrect duplicate accounting data.
Original PR description
Due to this commit: https://github.com/odoo/enterprise/commit/93c05b380e3c939e3c0b44eafcd7a41e86042d2d When importing 2 sodas from drag and drop. Due to the placement of the line_ids variable, the second move would have the line of first. By placing the variable in the loop we don't have that problem anymore task-6528101
This update resolves several issues across Attendance, Accounting, Email, eCommerce, IoT, Sales, Website, and localizations. It helps users avoid blocked check-ins, installation crashes, missing email details, access errors, and incorrect localization behavior.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr