Odoo Changelog — 2025-10-22

Wednesday, October 22, 2025

10 changes · master

Bug Fixes(10)

Resolved issues and error corrections

[REV] account_reports: CTA currency translation: using closing rate instead of current

Enterprisemasteraccount_accountantaccount_reportsMEDIUM

Financial reports now use the correct closing exchange rate for currency translation adjustments, reverting a prior change that used the current rate. This helps ensure reported balances are more accurate and consistent for accounting and reporting decisions.

Original PR description

This reverts commit 0719c63a646c360a4b090745cd8105128332ef38.

task-5085888

Forward-Port-Of: odoo/enterprise#97541
Forward-Port-Of: odoo/enterprise#97271

#currency#financial_reports#exchange_rates

[FIX] ai: execute non "code" server actions when triggered manually

PR #97785

Enterprisemasteraiai_documentsMEDIUM

Manual AI server actions now include the current record information they need to complete follow-up actions such as creating records, scheduling activities, or sending emails. This makes manually triggered AI workflows behave consistently with automated ones and also improves access to AI auto-sort tools from the documents setup modal.

Original PR description

Purpose:
--------
Currently, when an AI server action is triggered manually, the child server actions with state != code are not executed.
Nothing happens because inside `_run`, the server action is executed on each record obtained by browsing the ids given by the `active_ids` and `active_id` keys in the context, which are not present (it works fine when the action is triggered by an automation because the record info is added in the context in `_process` in base automation).

This commits adds the current records info in the context of the ai tools so that these server actions (such as create record, create activity or send mail) are now executed).

Task-5107876

Forward-Port-Of: odoo/enterprise#95343

#AI#server actions#manual workflow#documents

[FIX] accountant: Make write-off type explicitly 'entry'

PR #97806

Enterprisemasteraccount_accountantMEDIUM

This fix ensures write-off entries created during journal item reconciliation are always treated as standard journal entries. It prevents errors caused by customized default entry types, helping accountants complete reconciliations reliably.

Original PR description

Behavior before commit:
On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type.

Root cause:
The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised.

Fix:
Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`.

Steps to reproduce:
1. Have unreconciled Journal Items.
2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry".
3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard.
4. Observe the exception pointing to a missing `partner_id` or incorrect account type.

opw-5107155

Forward-Port-Of: odoo/enterprise#97130
Forward-Port-Of: odoo/enterprise#97028

#accounting#reconciliation#write-off

[FIX] delivery_ups_rest: add tax info in shipment request

PR #97825

Enterprisemasterdelivery_ups_restMEDIUM

UPS shipment requests now include the VAT numbers for the sender and customer. This ensures commercial invoices generated for cross-border UPS deliveries show the required tax information instead of leaving VAT fields blank.

Original PR description

**Current behavior:**
There is currently no tax information supplied in the UPS
shipment request. So, for example, the VAT number section on a
commercial invoice generated from a shipment will always be
blank.

**Steps to reproduce:**
- Create a quotation, chose a customer that is not is the same country as your company.
- Add a delivery and chose UPS.
- Validate the delivery.
- Check the invoice generated in the chatter.
- The VAT is not in the invoice

**Cause of the issue:**
The VAT of the company and the VAT of the customer were never given to UPS.

**Fix:**
The VATs are now added to the UPSRequest class before making the call to the API.

As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper.

opw-4591744

Forward-Port-Of: odoo/enterprise#82356

#UPS#VAT#shipping#invoice

[FIX] l10n_*_hr_payroll: use correct groups in tests w/o demo

PR #96766

Enterprisemasteraccount_reportshr_payroll_accountl10n_au_hr_payroll_apil10n_ch_hr_payroll_accountl10n_cl_edil10n_ke_hr_payroll_accountMEDIUM

This update fixes several payroll accounting setup issues so salary structures receive the correct default journal regardless of installation order or active company. It also improves reliability of localization tests without demo data and prevents Chilean electronic invoicing logic from affecting documents for other countries.

#payroll#accounting#localization#testing

[FIX] account_budget: duplicated amount in budget report

PR #97836

Enterprisemasteraccount_budgetaccount_budget_purchaseMEDIUM

Fixed an issue where budget line reports could show committed amounts twice when a bill used analytics from multiple plans. The report now matches the specific budget line, giving users accurate committed amounts for budget tracking.

Original PR description

Steps to reproduce:

- Create analytic plan A and B
- Create new budget with 2 lines:
  1. Plan A: Analytic account A, Budget: Any
  2. Plan B: Analytic account B, Budget: Any
- Create bill with line having:
  - Unit price: 100
  - Analytic distribution: planA -> account A, planB -> account B
- Open the Budget

Issue:

While the committed amount in each budget line is correct (100),
when opening the line budget report, the committed amount is doubled (200 instead of 100).
This occurs because the system matches the whole budget instead of the specific budget line.

opw-5039677

Forward-Port-Of: odoo/enterprise#97514

#budget#reporting#committed-amounts#analytics

[FIX] delivery_iot: auto print multiple documents

PR #97840

Enterprisemasterdelivery_iotiotMEDIUM

Automatic printing after validating a delivery now includes both shipping labels and shipping documents in the normal validation flow. This prevents missed print actions when the page reloads, making delivery processing more reliable for users with connected IoT printers.

Original PR description

The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads.

This reload makes our broadcasted action not to be caught by the client if there is only one connected.

Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it.

Forward-Port-Of: odoo/enterprise#97761
Forward-Port-Of: odoo/enterprise#97462

#delivery#iot#printing#shipping

[FIX] planning, knowledge, website_knowledge: fix blank print of public articles

PR #97791

Enterprisemasterknowledgeplanningwebsite_knowledgeMEDIUM

Public and portal users can now print or export shared Knowledge articles without getting blank pages. The fix ensures the right print styling is loaded and removes conflicting Planning print rules, improving reliability for customer-facing documentation and shared content.

Original PR description

### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing CSS rules (Public View)**
   The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode.

### Fix

This PR fixes problems 2, 3 and 4 by:

* Removing the unused/irrelevant planning print styles
* Ensuring `web.assets_web_print` is loaded in portal
* Creating a new print bundle for the frontend view
* Hiding the knowledge header in the public view when printing (to improve layout)


The first issue is tackled in odoo/odoo#223434

opw-4816241

Forward-Port-Of: odoo/enterprise#96656
Forward-Port-Of: odoo/enterprise#92665

#printing#portal#public_articles#knowledge

[FIX] account_report: allow filter per group name if present in the e…

PR #97869

Enterprisemasteraccount_reportsMEDIUM

Trial Balance PDF exports now correctly respect search filters when hierarchy and subtotals are enabled. Users can filter exported reports by account details or account group names, ensuring the PDF matches the report view and shows the expected lines.

Original PR description

…xported pdf

#### Issue
In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name.

#### Step to reproduce:
- Create an account group (e.g Group_101 from 101 to 101)
- Create some AML in an account related to the previously created group (e.g. in 101501 Cash)
- Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance )
- In the Options select "Hierarchy and subtotals"
- Add a filter including your group name (e.g. Group_101)
- Export to pdf

#### Current behavior:
- No lines are displayed in the pdf as the backend uses only the account name to apply the filter

#### Expected behavior:
- Lines are displayed using account name and group name to filter

#### Cause:
- Filter was applied only on account name

#### Solution:
- If hierarchy is enabled, display accounts where filter appears on either account or group

opw-4906593

Forward-Port-Of: odoo/enterprise#96338
Forward-Port-Of: odoo/enterprise#90403

#trial-balance#pdf-export#filters#accounting

[FIX] account_accountant: deferred with receipt type

PR #97886

Enterprisemasteraccount_accountantMEDIUM

Fixed an accounting issue where deferred dates on bill receipts could be cleared and related deferral entries could use the wrong account. This helps ensure receipt-based deferred accounting is handled consistently with bills and sales documents.

Original PR description

## Steps to reproduce

### Bug 1
1. Create a bill receipt
2. Add deferred dates
3. They're reset to False

### Bug 2
1. Create a bill
2. Set the deferred dates
3. Switch to receipt type
4. Confirm
5. The account of the generated deferral entries is incorrect

## Fix

While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value.

In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates.

In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator.

For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account.

opw-5129561

Forward-Port-Of: odoo/enterprise#97824
Forward-Port-Of: odoo/enterprise#97653

#accounting#deferred accounting#receipts

Purpose: -------- Currently, when an AI server action is triggered manually, the child server actions with state != code are not executed. Nothing happens because inside `_run`, the server action is executed on each record obtained by browsing the ids given by the `active_ids` and `active_id` keys in the context, which are not present (it works fine when the action is triggered by an automation because the record info is added in the context in `_process` in base automation). This commits adds the current records info in the context of the ai tools so that these server actions (such as create record, create activity or send mail) are now executed). Task-5107876 Forward-Port-Of: odoo/enterprise#95343

Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028

**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356

Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514

The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97761 Forward-Port-Of: odoo/enterprise#97462

### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#96656 Forward-Port-Of: odoo/enterprise#92665

…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create an account group (e.g Group_101 from 101 to 101) - Create some AML in an account related to the previously created group (e.g. in 101501 Cash) - Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance ) - In the Options select "Hierarchy and subtotals" - Add a filter including your group name (e.g. Group_101) - Export to pdf #### Current behavior: - No lines are displayed in the pdf as the backend uses only the account name to apply the filter #### Expected behavior: - Lines are displayed using account name and group name to filter #### Cause: - Filter was applied only on account name #### Solution: - If hierarchy is enabled, display accounts where filter appears on either account or group opw-4906593 Forward-Port-Of: odoo/enterprise#96338 Forward-Port-Of: odoo/enterprise#90403

## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561 Forward-Port-Of: odoo/enterprise#97824 Forward-Port-Of: odoo/enterprise#97653