Steps:
- Install account app.
- Create a branch company under the main company.
- Create a tax for the branch company.
- Add a main company tax on a product.
- Switch to branch company.

Issue:
- Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form.

Cause:
- After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company.

Fix:
- Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents.

[PR]: https://github.com/odoo/odoo/pull/194881
[17.0 PR]: https://github.com/odoo/odoo/pull/125642

opw-5042833

Forward-Port-Of: odoo/odoo#233720

Behavior before:
When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors.

Behavior after:
Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets.

Root cause:
The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation.

Benchmark:

| Period size (journal items)  | Before patch   | After patch   |
|----------------------------------------|----------------------|--------------------|
| ~15k                                        | 7s                      | 5s                   |
| ~200k+                                    | Timeout error| 21s                 |


opw-5046077

Forward-Port-Of: odoo/enterprise#97471
Forward-Port-Of: odoo/enterprise#95047

Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged.

Cause:
- The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns.

Fix Applied:
- Updated frontend (`filters.js`) to call `format_column_values_from_client` via
  `dispatch_report_action` instead of calling `format_column_values` directly.
  (this enables proper routing through the custom handler system)
- Added `format_column_values_from_client` override in `JournalReportCustomHandler`
  that intercepts the formatting call and applies special handling for tax summary
  lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines`
  monetary fields using their `_no_format` counterparts.
- The custom handler then delegates to the base method via
  `report.format_column_values_from_client()` to format standard columns.
- Also added missing `_no_format` fields in `account_journal_report.py` for
  `base_amount` and `tax_amount` to enable proper reformatting.

Forward-Port-Of: odoo/enterprise#98508
Forward-Port-Of: odoo/enterprise#94660

HOOT test "can handle command and disable mentions in AI composer" fails non-deterministically on runbot with the following error:

```
Cannot find a definition for model "hr.employee": could not get model from server environment (did you forget to use `defineModels()?`)
```

Somehow this test requires `hr.employee` model, which explained why it had `defineHrModels()`. This was replaced to enterprise livechat models, since new test need livechat and `hrModels` lacked livechat.

The way to `defineModels()` on modules with lots of dependency sucks: `hr` and `im_livechat` and `ai` have no explicit dependency among each other, but a module such as `test_discuss_full_enterprise` has to combine all of their behaviors and definitions. `defineModels()` is designed to extend a model by makin a subclass of a definition of same model in a dependent module, which is not practical here.

This commit doesn't solve the problem of defining livechat and hr models in the `test_discuss_full_enterprise` test suites, but for the quick and immediate fix it moves the problematic AI test in its own suite with `defineHrModels()`.

Fixes https://runbot.odoo.com/runbot/build/92414152

Forward-Port-Of: odoo/enterprise#98642

HOOT test "can handle command and disable mentions in AI composer" fails non-deterministically on runbot with the following error:

```
Cannot find a definition for model "hr.employee": could not get model from server environment (did you forget to use `defineModels()?`)
```

Somehow this test requires `hr.employee` model, which explained why it had `defineHrModels()`. This was replaced to enterprise livechat models, since new test need livechat and `hrModels` lacked livechat.

The way to `defineModels()` on modules with lots of dependency sucks: `hr` and `im_livechat` and `ai` have no explicit dependency among each other, but a module such as `test_discuss_full_enterprise` has to combine all of their behaviors and definitions. `defineModels()` is designed to extend a model by making a subclass of a definition of same model in a dependent module, which is not practical here.

This commit doesn't solve the problem of defining livechat and hr models in the `test_discuss_full_enterprise` test suites, but for the quick and immediate fix it moves the problematic AI test in its own suite with `defineHrModels()`.

Fixes https://runbot.odoo.com/runbot/build/92414152

If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records.

As a result, the contact page shows a banner indicating other partners use the same bank account, even though those res_partner_bank records have been archived.

Steps to reproduce the issue:

1. Create a new bank account which has the same bank account number as another bank account already associated to a partner
2. Assign this new bank account to another partner
3. Archive this new bank account
4. Go to the contact page of the partner (from step 1) which has a bank account with the same bank account number as the new bank account just created
5. A banner will pop up at the top of the contact saying that this partner uses the same bank account as the partner you set on the bank account in step 2

Solution:

Add a condition to the JOIN clause that checks “other.active = TRUE” to ensure that other res_partner_bank records to search for that have the same account number are active.

Also add a condition to the WHERE clause that checks “this.active = TRUE” to ensure that the current res_partner_bank record doing the search is active itself.

opw-4967083

Forward-Port-Of: odoo/odoo#232018
Forward-Port-Of: odoo/odoo#231585

Steps:
- Install account app.
- Create a branch company under the main company.
- Create a tax for the branch company.
- Add a main company tax on a product.
- Switch to branch company.

Issue:
- Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form.

Cause:
- After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company.

Fix:
- Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents.

[PR]: https://github.com/odoo/odoo/pull/194881
[17.0 PR]: https://github.com/odoo/odoo/pull/125642

opw-5042833

Forward-Port-Of: odoo/odoo#233720

Steps:
- Install account app.
- Create a branch company under the main company.
- Create a tax for the branch company.
- Add a main company tax on a product.
- Switch to branch company.

Issue:
- Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form.

Cause:
- After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company.

Fix:
- Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents.

[PR]: https://github.com/odoo/odoo/pull/194881
[17.0 PR]: https://github.com/odoo/odoo/pull/125642

opw-5042833

Forward-Port-Of: odoo/odoo#233720