Odoo Changelog — 2026-01-17

Saturday, January 17, 2026

13 changes

Branch: saas-18.4

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_hu_edi, l10n_de: keep manual currency rate when posting invoices

PR #244310

Coresaas-18.4accountl10n_del10n_hu_ediMEDIUM

This update ensures that manually set currency rates on customer invoices (specifically for German and Hungarian invoices) are correctly applied during the posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This change maintains the user's intended rate, improving invoice accuracy and financial reporting.

Original PR description

Initial setup: Install  l10n_hu_edi and l10n_de.

When creating a customer invoice DE in a foreign currency, a manually edited
currency rate was overridden at posting time with the rate from the currency
table.

Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes.

Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves.

task-5391774

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#242192

#currency#invoice#reporting#financials

17.0 FIX Decimals in TotClauVta tag

PR #104169

Enterprisesaas-18.4l10n_cl_ediMEDIUM

This update resolves a problem where Odoo invoices exported to the SII system (Chile) were being rejected due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential disruptions to sales processes.

Original PR description

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

#SII#export invoices#Chile

[PERF] account_budget: optimize budget report SQL query plan

PR #104652

Enterprisesaas-18.4accountMEDIUM

This update optimizes the SQL query used to generate the budget report, resulting in significantly faster performance, especially with large datasets. The change refactors the query to better utilize database optimization techniques, reducing processing time and improving report generation speed. This enhances the overall user experience for this key financial report.

Original PR description

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104531
Forward-Port-Of: odoo/enterprise#104299

#performance#reporting#SQL

Branch: saas-18.3

3 changes

Bug Fixes(3)

Resolved issues and error corrections

17.0 FIX Decimals in TotClauVta tag

PR #104141

Enterprisesaas-18.3l10n_cl_ediMEDIUM

This update resolves a problem where Odoo invoices exported to the SII system (Chile) were being rejected due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate invoice exports and avoids potential rejection by the SII system.

Original PR description

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

#SII#export invoices#Chile

[FIX] l10n_pt: Automate tax based on state

PR #236005

Coresaas-18.3l10n_ptMEDIUM

This update automatically determines the correct VAT rate for sales orders based on the warehouse location, ensuring compliance with Portuguese tax regulations. Previously, VAT rates were manually set, leading to potential errors and delays. This change streamlines the process and reduces the risk of incorrect invoicing.

Original PR description

Implements automation to correctly set the sales order fiscal position based on the warehouse, ensuring compliance with "place of supply" VAT rules.

Problem:
- The VAT rate must be determined by the supply location (warehouse), not the customer's delivery address.
- Manually selecting the fiscal position on every sales order is slow and highly prone to user error, leading to incorrect invoicing.

task-5088046

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

Forward-Port-Of: odoo/odoo#235887
Forward-Port-Of: odoo/odoo#227994

#VAT#Tax#Portugal#Compliance

[PERF] account_budget: optimize budget report SQL query plan

PR #104643

Enterprisesaas-18.3accountMEDIUM

This update optimizes the SQL query used to generate budget reports, resulting in significantly faster performance, especially with large datasets. The change refactors the query to utilize a more efficient join strategy, reducing processing time and improving report generation speed. This directly impacts user experience and report loading times.

Original PR description

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104531
Forward-Port-Of: odoo/enterprise#104299

#performance#reporting#SQL

Branch: saas-18.2

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] mail: fold the chat window when clicking odoo links in mobile

PR #208440

Coresaas-18.2mailMEDIUM

This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the window to remain open and block the display of new pages. The change now automatically folds the chat window after a link click, ensuring users can easily view the linked content. This enhances usability and prevents a frustrating user experience.

Original PR description

Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window.
This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window.

task-4762503

#mobile#chat#user experience

17.0 FIX Decimals in TotClauVta tag

PR #104040

Enterprisesaas-18.2l10n_cl_ediMEDIUM

This update resolves a problem where Odoo invoices for export invoices were being rejected by the SII system due to incorrect decimal formatting. The code now ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential issues with tax authorities.

Original PR description

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

#SII#export invoices#decimal precision

[FIX] l10n_it: Remove integer rounding from monthly VAT

PR #243671

Coresaas-18.2l10n_itMEDIUM

This update removes unnecessary integer rounding from monthly VAT reports for Italian businesses (l10n_it). Previously, rounding was incorrectly applied to these reports, leading to potential inaccuracies. This change ensures accurate monthly VAT reporting, aligning with Italian tax regulations.

Original PR description

**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662.

**Current behavior before PR**: Integer rounding on monthly l10n_it tax reports.

**Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports.

[opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#243100

#VAT#Italy#Tax Reporting

Branch: master

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] l10n_ar_reports: Correct total computation in VAT summary report

PR #101415

Enterprisemasteraccountl10n_arMEDIUM

This update fixes an issue in the Argentinian VAT summary report where VAT amounts were incorrectly duplicated when multiple IIBB taxes were applied to an invoice. The fix ensures that VAT totals accurately reflect the true tax amounts by restructuring the report's calculation logic. This improves the accuracy of financial reporting.

Original PR description

**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…

**Steps to Reproduce**
1. Install the Accounting app and the Argentinian localization (l10n_ar)
2. Set the 21% VAT Purchase tax as Included in Price
3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes
4. Open the VAT summary report for that bill

Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once.

**Root Cause**
The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist.

**Fix**
The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals.

opw-4776861

Forward-Port-Of: odoo/enterprise#98933
Forward-Port-Of: odoo/enterprise#85873

#VAT#Argentina#reporting#tax

[FIX] l10n_br_avatax: disable tracking during tax `_load`

PR #104535

Enterprisemasterl10n_br_avataxMEDIUM

This update resolves a problem that prevented the tax module from correctly loading after database upgrades. The fix ensures tracking computations are temporarily disabled during module loading, preventing errors and ensuring a smooth upgrade process. This improves stability and avoids delays during module installations.

Original PR description

During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py…

During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.

```py
  /home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
  /home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
  /home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
  /home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```

Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.

```py
  File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
    tracking = records.with_context(context)._message_track(fnames, initial_values)
  File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
    record._message_log(
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
    self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
    diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```

This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae

The resulting tracking computation crashes with a KeyError when processing repartition line diffs.

Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.

opw-5467986
upg-3753990
tbg-2380

Forward-Port-Of: odoo/enterprise#103931

#l10n_br#avatax#upgrade

Branch: 19.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

17.0 FIX Decimals in TotClauVta tag

PR #104196

Enterprise19.0l10n_cl_ediMEDIUM

This update resolves a problem where Odoo invoices for export invoices were being rejected by the SII system due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential delays in processing.

Original PR description

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

#SII#export invoices#decimal precision

Branch: 18.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_mx_edi: Round exchange rate for Solucion Factible CFDI

PR #104195

Enterprise18.0l10n_mx_ediMEDIUM

This update ensures that invoices generated with the Solution Factible PAC in Mexico comply with Mexican tax regulations regarding exchange rate precision. Previously, a bug prevented valid invoices from being processed due to insufficient decimal places in the exchange rate. This fix applies a rounding adjustment to all PACs, resolving this compatibility issue.

Original PR description

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#102557

#mexico#cfdi#invoice#exchange rate

Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192

Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862 Forward-Port-Of: odoo/enterprise#104531 Forward-Port-Of: odoo/enterprise#104299

Implements automation to correctly set the sales order fiscal position based on the warehouse, ensuring compliance with "place of supply" VAT rules. Problem: - The VAT rate must be determined by the supply location (warehouse), not the customer's delivery address. - Manually selecting the fiscal position on every sales order is slow and highly prone to user error, leading to incorrect invoicing. task-5088046 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 Forward-Port-Of: odoo/odoo#235887 Forward-Port-Of: odoo/odoo#227994

Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503

**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243100

**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#98933 Forward-Port-Of: odoo/enterprise#85873

During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py /home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate() -> env['account.chart.template'].try_loading('br', company) /home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading() -> return self._load(template_code, company, install_demo, force_create) /home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load() -> self._l10n_br_init_avatax_code(company) /home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code() -> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code'] ``` Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages. ```py File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize tracking = records.with_context(context)._message_track(fnames, initial_values) File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track record._message_log( File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char']) File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines diff_keys = [key for key in old_value if old_value[key] != new_value[key]] File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp> diff_keys = [key for key in old_value if old_value[key] != new_value[key]] KeyError: 'Porcentagem fatorial' ``` This occurs due to the interaction between: - the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e - the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae The resulting tracking computation crashes with a KeyError when processing repartition line diffs. Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading. opw-5467986 upg-3753990 tbg-2380 Forward-Port-Of: odoo/enterprise#103931

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#102557