Daily updates from Odoo
Monday, July 6, 2026
10 changes · 19.0
Enhancements to existing features
UK VAT returns now guide users to file through the relevant tax unit when their company belongs to one. This helps ensure HMRC connections and submissions use the tax unit’s VAT number instead of the individual company’s VAT number.
Original PR description
BEFORE: - Before this commit, when the current company is a member of the tax unit, there is no blocking level error for the user to select the tax unit. - And the vat used while creating a connection to the HMRC or while sending a tax report to the HMRC is of the current company. AFTER: - After this commit, there is one blocking level error, which tells the user that the current company is part of a tax unit, and on confirmation, the tax unit will automatically be selected for the current report. - And if the return contains the data of a tax unit, then the vat set on the tax unit will be considered while establishing the connection and sending the tax report to HMRC. Task-5865605 Forward-Port-Of: odoo/enterprise#122908 Forward-Port-Of: odoo/enterprise#107253
GSTR-1 JSON generation for Indian tax reporting has been optimized to use less memory and complete faster. This should improve performance when preparing GST filings, especially for larger datasets, without changing the report's business purpose.
Original PR description
This PR intends to improve both memory and time performance by using precomputing required values for GSTR-1 JSON generation. task-3941950 Community PR - https://github.com/odoo/odoo/pull/273087
Hong Kong payroll now participates in the automatic payroll data update process. This helps keep standard salary rules up to date for users, reducing manual maintenance while preserving rules that have been edited.
Original PR description
Currently, the "Payroll: Update data" cron doesn't work for HK payroll as we never set up the _get_data_files_to_update. We can set up the list of data files to keep up to date to better support our users by automatically keeping non-edited salary rules up to date. task-6360339
Budget reports now use the same analytic profitability criteria as profitability reporting. This helps ensure budget figures are based on the right analytic entries, improving consistency for financial review and decision-making.
Original PR description
Use the new field analytic_profitability in the conditions of the query to get the account analytic lines of the budget report task-4959636 Forward-Port-Of: odoo/enterprise#121760
Resolved issues and error corrections
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.
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
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
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-6169802This 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
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.