Odoo Changelog — 2026-07-06

Monday, July 6, 2026

6 changes · 19.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] sale_commission: fix achievement report crash on current period filter

Enterprise19.0sale_commissionMedium

The Sales Commission Achievements report now opens correctly when users apply the Current Period filter. This prevents an error that blocked access to current-period commission achievement data, improving reliability for sales teams and managers.

Original PR description

Steps to reproduce
------------------
1. Install `sale_commission` (Enterprise).
2. Navigate to Sales -> Commission -> Achievements.
3. Click on the "Current Period" search filter.

Issue
-----
A `ValueError` is raised: `time data 'today' does not match format '%Y-%m-%d'`.

The "Current Period" filter sends a domain using the string literal `'today'`. Natively, the ORM handles these special variables on evaluation. However, the `_search` override in `sale.commission.achievement.report` manually intercepted the raw domain leaves and tried to parse them directly via `datetime.strptime(d[2], '%Y-%m-%d')`, which crashes when encountering `'today'`.

Solution
--------
Pass the domain through the modern `Domain` API and use `optimize_full(model)` before extracting dates. This allows the ORM to properly resolve special tokens like `'today'` into actual `datetime.date` objects, which we can then safely filter via `isinstance()` without crashing.

#sales commission#achievements#reporting#current period

[FIX] l10n_mx_edi_sale: uses the return account when creating CN from SO

PR #120975

Enterprise19.0l10n_mx_edi_saleMedium

When a credit note is created from a sales order in Mexican electronic invoicing, its lines now use the company's configured return account instead of the standard sales account. This helps ensure accounting entries are posted correctly when quantities are reduced after invoicing.

Original PR description

**PROBLEM**
When creating a Credit Note from a Sale Order, the credit note lines uses the default account instead of using the return account set on the company.

**STEP TO REPRODUCE**
1. Create a SO with a product.
2. Create an invoice and confirm it.
3. Return to the SO, and reduce the product qty (product invoice policy should be ordered qty for these steps).
4. Click again on create Invoice to create a Credit Note for the SO.
5. Notice the account on the product line is not the return account.

**CAUSE**
In `_create_invoices()` on the SO model, we first create the moves as invoice, and then switch them to credit note if the total is negative. This means the lines are created with the invoice default account.

opw-6266882

#credit-notes#sales-orders#accounting#mexico

[FIX] pos_self_order_iot: verify config on payment

PR #122700

Enterprise19.0pos_self_order_iotMedium

The self-ordering payment flow now verifies that the selected point-of-sale setup is a kiosk and has an IoT payment method before processing payment. This helps prevent incorrect or incomplete configurations from causing payment issues for customers.

Original PR description

This commit makes the payment endpoint more robust by verifying the POS config is indeed a kiosk, and that it has an IoT payment method configured.

Forward-Port-Of: odoo/enterprise#122628
Forward-Port-Of: odoo/enterprise#121894

#payments#self-ordering#kiosk#iot

[FIX] industry_fsm_sale: fix invoice status with zero price lines

PR #119238

Enterprise19.0industry_fsm_saleMedium

Sales orders linked to field service tasks now distinguish between free items that were already on the quotation and free materials added during the job. This prevents valid zero-price quotation lines from being skipped for invoicing and lets orders correctly show as fully invoiced once eligible lines are billed.

Original PR description

## [FIX] industry_fsm_sale: fix invoice status for zero price lines ### Issue: Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines…

## [FIX] industry_fsm_sale: fix invoice status for zero price lines

### Issue:
Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines linked to an FSM task to 'no'

This includes pre-existing lines that were already present on the quotation before confirmation. If a zero price line is pre-existing, it should follow the standard flow and be marked as 'to invoice'
Only lines added as materials from the field service task at a zero price should be considered included in the price and marked as 'no'

### Cause:
In `SaleOrderLine._compute_invoice_status`, the system forced `invoice_status = 'no'` for all zero price lines when Anglo-Saxon accounting was disabled
It failed to check if the lines were actually materials added via the FSM task or original quotation lines

### Fix:
A new `material_sale_lines` compute field is added to `project.task` to distinctly isolate and track lines added specifically as materials during the task execution

In `SaleOrderLine._compute_invoice_status`, the logic is updated to ensure that only zero price lines identified as FSM materials are set to 'no' when Anglo-Saxon accounting is disabled
Other pre-existing zero price lines properly remain as 'to invoice'

### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
Before the fix, the pre-existing SO line with price 0 is 
incorrectly considered as not to invoice ('no')

opw-6169802

------------------------------

## [FIX] industry_fsm_sale: sync sale order invoice status

### Issue:
When a sale order contains FSM material lines with a price of zero and Anglo-Saxon accounting is disabled, the overall sale order invoice status remains stuck on 'to invoice' even after all other invoiceable lines are fully invoiced

### Cause:
The standard `SaleOrder._compute_invoice_status` does not handle FSM business rules regarding zero price material lines that are marked as `invoice_status = 'no'`
Because these lines are never technically invoiced, the global order status fails to transition to 'invoiced'

### Fix:
Override `SaleOrder._compute_invoice_status` to recompute the status of confirmed orders linked to FSM tasks

We use the task's `material_sale_lines` to filter out material components
If all lines on the order are either 'invoiced' or are zero price FSM material lines with Anglo-Saxon disabled, the global sale order status is forced to 'invoiced'

### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
- Add a Product from the Task (Use a price 0 product, or set the unit price to 0 on the SO)
- Create the invoice for the Sale Order
Before the fix, the Service and Pre-existing product are invoiced, but in the Other Info Tab of the SO, the status stays on 'To Invoice' instead of 'Fully Invoiced'

opw-6169802

[FIX] sale_subscription: check constraint on catalog product add

PR #122799

Enterprise19.0sale_subscriptionMedium

This fixes a gap where recurring products could be added to confirmed sales orders through the catalog without requiring a subscription plan. Business users now get the same warning regardless of how the product is added, preventing inconsistent subscription orders.

Original PR description

Steps to reproduce: --------------------------------------- 1. Install Subscription Module 2. Create and Confirm SO with no recurring plan and a non-recurring product 3. Add a recurring product >…

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#122253
Forward-Port-Of: odoo/enterprise#117879

[FIX] website_generator{_sale}: fixes wrong data-filter-id values

PR #122671

Enterprise19.0website_generatorwebsite_generator_saleMedium

This fix ensures generated website snippets use the correct filter settings regardless of the order in which modules were installed. It helps prevent website content blocks from showing incorrect or broken dynamic content for customers with different installation histories.

Original PR description

Our default dynamic snippets filter ids are set based on the order that we install our modules. This can cause issues if the user installs their modules in a different order.
To fix this, we need to update the data-filter-id value to the correct value of the DB.

To be able to do this, we also change the regex replacement to use lxml instead since it's much simpler.

Lxml part from 799f83575e162eb683cfaebb4eb602ccc1fbe466.

#website#snippets#content

Steps to reproduce ------------------ 1. Install `sale_commission` (Enterprise). 2. Navigate to Sales -> Commission -> Achievements. 3. Click on the "Current Period" search filter. Issue ----- A `ValueError` is raised: `time data 'today' does not match format '%Y-%m-%d'`. The "Current Period" filter sends a domain using the string literal `'today'`. Natively, the ORM handles these special variables on evaluation. However, the `_search` override in `sale.commission.achievement.report` manually intercepted the raw domain leaves and tried to parse them directly via `datetime.strptime(d[2], '%Y-%m-%d')`, which crashes when encountering `'today'`. Solution -------- Pass the domain through the modern `Domain` API and use `optimize_full(model)` before extracting dates. This allows the ORM to properly resolve special tokens like `'today'` into actual `datetime.date` objects, which we can then safely filter via `isinstance()` without crashing.

**PROBLEM** When creating a Credit Note from a Sale Order, the credit note lines uses the default account instead of using the return account set on the company. **STEP TO REPRODUCE** 1. Create a SO with a product. 2. Create an invoice and confirm it. 3. Return to the SO, and reduce the product qty (product invoice policy should be ordered qty for these steps). 4. Click again on create Invoice to create a Credit Note for the SO. 5. Notice the account on the product line is not the return account. **CAUSE** In `_create_invoices()` on the SO model, we first create the moves as invoice, and then switch them to credit note if the total is negative. This means the lines are created with the invoice default account. opw-6266882

This commit makes the payment endpoint more robust by verifying the POS config is indeed a kiosk, and that it has an IoT payment method configured. Forward-Port-Of: odoo/enterprise#122628 Forward-Port-Of: odoo/enterprise#121894

## [FIX] industry_fsm_sale: fix invoice status for zero price lines ### Issue: Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines linked to an FSM task to 'no' This includes pre-existing lines that were already present on the quotation before confirmation. If a zero price line is pre-existing, it should follow the standard flow and be marked as 'to invoice' Only lines added as materials from the field service task at a zero price should be considered included in the price and marked as 'no' ### Cause: In `SaleOrderLine._compute_invoice_status`, the system forced `invoice_status = 'no'` for all zero price lines when Anglo-Saxon accounting was disabled It failed to check if the lines were actually materials added via the FSM task or original quotation lines ### Fix: A new `material_sale_lines` compute field is added to `project.task` to distinctly isolate and track lines added specifically as materials during the task execution In `SaleOrderLine._compute_invoice_status`, the logic is updated to ensure that only zero price lines identified as FSM materials are set to 'no' when Anglo-Saxon accounting is disabled Other pre-existing zero price lines properly remain as 'to invoice' ### Steps to reproduce: - Install `industry_fsm_sale` - In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+) - Disable Anglo-Saxon on the current company - Create a product Service (Fixed Price, that create a task in a Field Service Project) - Create and confirm a Sale Order with the Service and one product with unit price 0 Before the fix, the pre-existing SO line with price 0 is incorrectly considered as not to invoice ('no') opw-6169802 ------------------------------ ## [FIX] industry_fsm_sale: sync sale order invoice status ### Issue: When a sale order contains FSM material lines with a price of zero and Anglo-Saxon accounting is disabled, the overall sale order invoice status remains stuck on 'to invoice' even after all other invoiceable lines are fully invoiced ### Cause: The standard `SaleOrder._compute_invoice_status` does not handle FSM business rules regarding zero price material lines that are marked as `invoice_status = 'no'` Because these lines are never technically invoiced, the global order status fails to transition to 'invoiced' ### Fix: Override `SaleOrder._compute_invoice_status` to recompute the status of confirmed orders linked to FSM tasks We use the task's `material_sale_lines` to filter out material components If all lines on the order are either 'invoiced' or are zero price FSM material lines with Anglo-Saxon disabled, the global sale order status is forced to 'invoiced' ### Steps to reproduce: - Install `industry_fsm_sale` - In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+) - Disable Anglo-Saxon on the current company - Create a product Service (Fixed Price, that create a task in a Field Service Project) - Create and confirm a Sale Order with the Service and one product with unit price 0 - Add a Product from the Task (Use a price 0 product, or set the unit price to 0 on the SO) - Create the invoice for the Sale Order Before the fix, the Service and Pre-existing product are invoiced, but in the Other Info Tab of the SO, the status stays on 'To Invoice' instead of 'Fully Invoiced' opw-6169802

Steps to reproduce: --------------------------------------- 1. Install Subscription Module 2. Create and Confirm SO with no recurring plan and a non-recurring product 3. Add a recurring product > Save SO > Observe the User Error 4. Now add the same recurring product through Catalog View Observation: --------------------------------------- No User Error raised stating 'You cannot save a sale order with recurring product and no subscription plan.' Issue: --------------------------------------- When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177 When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint. https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933 Solution: --------------------------------------- Two private helpers are introduced: * `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders). * `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync. `_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points. opw-6194865 Forward-Port-Of: odoo/enterprise#122253 Forward-Port-Of: odoo/enterprise#117879

Our default dynamic snippets filter ids are set based on the order that we install our modules. This can cause issues if the user installs their modules in a different order. To fix this, we need to update the data-filter-id value to the correct value of the DB. To be able to do this, we also change the regex replacement to use lxml instead since it's much simpler. Lxml part from 799f83575e162eb683cfaebb4eb602ccc1fbe466.