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#97660
Forward-Port-Of: odoo/enterprise#95047

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#97660
Forward-Port-Of: odoo/enterprise#95047

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#97660
Forward-Port-Of: odoo/enterprise#95047

*: purchase_accountant,sale_account_accountant

This commit adds new menu for SO and PO accruals.
A custom list view (`js_class`) was created for those reports:
`accrual_list_view`.

AccrualListView
===============
This view is used both by `sale.order.line` and `purchase.order.line`.
Its functionnalities are:

- The user can choose a date to see records' values in the past;

- If a line is clicked, instead of opening the line's form view, it will
  open its order form view instead.

Technical notes about this view:

- The chosen date is passed to the context but there is issue when the
  view is grouped (and it is by default): while the grouped lines uses
  the right context with the selected date, the contained lines sometime
  use an old version of this context with a previously selected date
  which means the grouped data are not the same than the single lines
  data. To fix that, we force the context on each group.

- The "at_date" fields are non-stored computed fields. By default, there
  is no sum value for those fields. Server side, we override the
  `_read_group` method to "manually" compute those fields sum. To be
  able to do that, we tweak the aggregate config in this view.

Boolean fields
==============
Four boolean fields are created:

- `prepaid_expense` and `bill_to_receive` for `purchase.order.line`;
- `deferred_revenue` and `invoice_to_be_issued` for `sale.order.line`.

Those fields are usefull to fetch right order lines for the right
accrual and are always a balance between delivered/received quantity and
invoiced quantity.

[task-5075455](https://www.odoo.com/odoo/966/tasks/5075455)
Community PR: odoo/odoo#231510

[IMP] account_fiscal_categories: enhance list view of account_account
======================================================

With this commit, we add a new field `current_rate` in `account.account`. This `current_rate` is a non-stored compute field, used to compute the current applicable rate on the given account.

This `current_rate` and `fiscal_category_id` has been introduced in the list view of `account.account`.

[IMP] account_fiscal_categories: enhance multiple rate warning in fiscal report
===========================================================

Before this commit, the "multiple rate" warning was shown even when no entries for accounts with multiple rates existed in the selected period. This happened because all accounts were considered for multiple rates, regardless of journal entries in that period.

After this commit, only accounts with entries in the selected period are considered for the "multiple rates" warning. The warning is now clickable, redirecting the user to the accounts having multiple rates.

[FIX] l10n_be_fiscal_categories: remove redundant rate on CoA
=================================================

This commit removes the redundant fiscal rate on account-613311. Both fiscal categories 1206 and 1073 were assigned to this account, resulting in two rates. Only 1073 should be there.

ref-https://github.com/odoo/enterprise/commit/f2579a80833ac129b2f21613b93c4e3203646a1b



**task**-5163392
-----------------------

### Summary

Previously, when a user attempted to **register as a Peppol receiver** while already registered through a different Odoo database, the system would raise a **User Error**.  
The user had to **manually deregister** and **re-register** from the desired database.

---

### New Behavior (After This Commit)

With this update:
- The system **detects existing Peppol registrations** across databases.  
- Instead of raising an error, it now **sends an automated email** to the user with a **secure transfer link**.  
- This allows the user to **migrate their Peppol connection** to the current database seamlessly.

---
###  Flow Overview

```text
            ┌────────────────────────────┐
            │  User initiates Peppol     │
            │  registration (becomes     │
            │  sender)                   │
            └────────────┬───────────────┘
                         │
                         ▼
          ┌──────────────────────────────┐
          │  Check existing registration  │
          └────────────┬─────────────────┘
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
┌─────────────────────┐       ┌──────────────────────────────┐
│ User NOT registered │       │ User ALREADY registered      |
│ in any Odoo DB      │       
└────────────┬────────┘       └──────────────┬───────────────┘
             │                               │
             ▼                               ▼
 ┌──────────────────────────┐      ┌──────────────────────────────┐
 │ Proceed with normal      │      │ Send email with transfer link│
 │ registration flow        │      │ to the user                  │
 └──────────────────────────┘      └──────────────┬───────────────┘
                                                  │
                                                  ▼
                                     ┌──────────────────────────────┐
                                     │ User clicks transfer link    
                                     │                                                                              
                                     └──────────────┬───────────────┘
                                                    │
                                                    ▼
                                     ┌──────────────────────────────┐
                                     │ Peppol connection migrated 
                                     └──────────────────────────────┘


```
---
iap pr- https://github.com/odoo/iap-apps/pull/1236
task- 5023252