Odoo Changelog — 2026-09-05

Saturday, September 5, 2026

8 changes · saas-19.2

Bug Fixes(8)

Resolved issues and error corrections

[FIX] l10n_fr_pdp: correct Flow 10 tax data

Coresaas-19.2l10n_fr_pdpMedium

French PDP Flow 10 reporting now checks tax rates before submission and keeps VAT breakdowns aligned with invoice totals. Untaxed line amounts and exemption reasons are included correctly, helping prevent inaccurate tax XML reports and missed journal entry errors.

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

#France#PDP#VAT#e-invoicing

[FIX] l10n_lu_reports: correct investment account mapping

PR #130601

Enterprisesaas-19.2l10n_lu_reportsMedium

The Luxembourg Balance Sheet now places own shares and related undertaking shares in the correct investment categories. This helps companies produce statutory reports that align with official Luxembourg mapping rules and avoids swapped values in exported reports.

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 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

[FIX] base: prevent OCR flag transfer on partner merge

PR #286828

Coresaas-19.2base

Merging contacts now avoids copying the OCR-created marker from one contact to another. This prevents an incorrect validation error when combining duplicate contacts with the same name, making contact cleanup more reliable.

Original PR description

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when…

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR.

But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint.

Fix:
`is_created_by_ocr` should have `copy=False` and should not be transferred when merging. Make the merge skip fields that are not copyable.

This prevents the True value from being transferred to the destination, avoiding the unique constraint error.

A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed.

Steps to Reproduce on Runbot:
1. Create 2 contacts with the same exact name and have one created by OCR.
I used a server action to manually set the value of
'is_created_by_ocr' to simplify this process.
2. Select the contacts and merge. In the merge window,
set the non-ORC contact to be the destination contact.
3. Upon confirming merge contacts, the validation error will appear.

Related ticket:
opw-6513607

Forward-Port-Of: odoo/odoo#285150

[FIX] account_invoice_extract: no OCR flag transfer on partner merge

PR #130563

Enterprisesaas-19.2account_invoice_extract

Merging a contact created through invoice OCR into an existing contact with the same name no longer triggers a validation error. The OCR-created marker is kept from being copied during the merge, so users can clean up duplicate contacts without disruption.

Original PR description

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when…

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR.

But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint.

Fix:
is_created_by_ocr should have copy=False and should not be transferred when merging. Make the merge skip fields that are not copyable.

This prevents the True value from being transferred to the destination, avoiding the unique constraint error.

A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed.

Steps to Reproduce on Runbot:
1. Create 2 contacts with the same exact name and have one created by OCR.
I used a server action to manually set the value of
'is_created_by_ocr' to simplify this process.
2. Select the contacts and merge. In the merge window,
set the non-ORC contact to be the destination contact.
3. Upon confirming merge contacts, the validation error will appear.

Related ticket:
opw-6513607

Forward-Port-Of: odoo/enterprise#129623

[FIX] planning: multi-edit not working with default "Employees" filter

PR #130580

Enterprisesaas-19.2planningMedium

Fixes an issue where Planning users could not create or edit multiple Gantt entries when the default Employees filter was enabled. This restores expected bulk scheduling behavior and reduces friction for teams managing employee 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

Forward-Port-Of: odoo/enterprise#130369

#planning#gantt#employees#multi-edit

[FIX] l10n_in_reports: fix GST token refresh cron

PR #130530

Enterprisesaas-19.2l10n_in_reports

The GST token refresh job now correctly detects when any company’s token has been refreshed before scheduling the next run. This helps ensure Indian GST reporting integrations continue refreshing reliably in multi-company environments.

Original PR description

The `_cron_refresh_gst_token` method is called by a cron job. Previously, when scheduling the next cron execution, it checked
`self.company_id.l10n_in_gstr_gst_token`.
However, since the cron can process multiple companies, relying on `self.company_id` could result in incorrect behavior.

In this commit, a flag is introduced to track whether at least one GST token was refreshed successfully. If a token was refreshed, the cron is scheduled to run again after 6 hours.

Forward-Port-Of: odoo/enterprise#130317

#GST#India#cron#multi-company

[FIX] l10n_fr_pdp: correct Flow 10 invoice type codes

PR #286873

Coresaas-19.2l10n_fr_pdpMedium

French PDP Flow 10 now labels vendor bills and credit notes with the correct document codes. This helps prevent purchase invoices from being wrongly treated as credit notes and rejected due to missing prior invoice references.

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

#France#e-invoicing#PDP#invoices

[FIX] account_saft: exclude journal entries with current asset accounts from SAF-T

PR #130581

Enterprisesaas-19.2account_saftMedium

This fix prevents SAF-T report generation from failing when journal entries include current asset accounts. It ensures those entries are excluded from the affected SAF-T partner account logic, allowing Norwegian SAF-T exports to complete successfully.

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 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

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

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

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint. Fix: `is_created_by_ocr` should have `copy=False` and should not be transferred when merging. Make the merge skip fields that are not copyable. This prevents the True value from being transferred to the destination, avoiding the unique constraint error. A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed. Steps to Reproduce on Runbot: 1. Create 2 contacts with the same exact name and have one created by OCR. I used a server action to manually set the value of 'is_created_by_ocr' to simplify this process. 2. Select the contacts and merge. In the merge window, set the non-ORC contact to be the destination contact. 3. Upon confirming merge contacts, the validation error will appear. Related ticket: opw-6513607 Forward-Port-Of: odoo/odoo#285150

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint. Fix: is_created_by_ocr should have copy=False and should not be transferred when merging. Make the merge skip fields that are not copyable. This prevents the True value from being transferred to the destination, avoiding the unique constraint error. A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed. Steps to Reproduce on Runbot: 1. Create 2 contacts with the same exact name and have one created by OCR. I used a server action to manually set the value of 'is_created_by_ocr' to simplify this process. 2. Select the contacts and merge. In the merge window, set the non-ORC contact to be the destination contact. 3. Upon confirming merge contacts, the validation error will appear. Related ticket: opw-6513607 Forward-Port-Of: odoo/enterprise#129623

## 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

The `_cron_refresh_gst_token` method is called by a cron job. Previously, when scheduling the next cron execution, it checked `self.company_id.l10n_in_gstr_gst_token`. However, since the cron can process multiple companies, relying on `self.company_id` could result in incorrect behavior. In this commit, a flag is introduced to track whether at least one GST token was refreshed successfully. If a token was refreshed, the cron is scheduled to run again after 6 hours. Forward-Port-Of: odoo/enterprise#130317

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

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