*: account, pos_sale, purchase, purchase_mrp, purchase_stock, sale,
sale_mrp, sale_project, sale_stock, sale_timesheet, stock_account

This commit modifies `sale.order.line` and `purchase.order.line` models
to work with the new accrual reports.

List of changes made:

## Split compute methods
The `purchase.order.line` has two fields, `qty_received` and
`qty_invoiced`, and we would like to be able to know what was those
fields value in the past at a given date. The `sale.order.line` has also
two fields in the same situation, `qty_delivered` and `qty_invoiced`.

Currently, those fields are computed and stored, thus we need a
computed non-stored version of those fields to be able to re-compute
their value depending of the context (so, we can pass the accrual date
into the context.) The non-stored version of those fields have the same
name with the suffix "at_date" (eg.: `qty_invoiced_at_date`.)

To achieve that, we move all the compute code outside of the compute
method to have a method we can call from both fields' compute.
For example, we have now a method named `_prepare_qty_delivered` which
returns the `qty_delivered` value for the SO lines, and both
`_compute_qty_delivered` and `_compute_qty_delivered_at_date` use it.

## "at_date" fields
Those new computed stored fields use the `accrual_entry_date` context
key to compute their value at this date.
This key was already there in the code and already used by the accrual
wizard but before, it was always an actual date object, now it can be a
string (when pass in the context from the client side) and thus needs to
be parsed.

A field `amount_to_invoice_at_date` was also added, both for PO line and
SO line, and this field is simply the difference between the
delivered/received quantity and the invoiced quantity times the price
unit. It is used by the accrual views (see enterprise PR) and the
accrual wizard.
About this field, note that we make the choice to declare it a a `Float`
field and not a `Monetary` field. While a monetary field was our first
option, we figured out it adds complexity while hacking *hum* patching
the `_read_group` method to be able to sum those non-stored computed
fields (again, see entreprise PR for more information.)

## Perpetual valuation
When using the Accrued Orders Wizard, if an order's product uses the
perpetual valuation (needs an expense account and a stock variation
account), addition account moves will be generated for the expense
account and the stock variation account and related product will be
marked by an asterisk (*).

[task-5075455](https://www.odoo.com/odoo/966/tasks/5075455)
Enterprise PR: odoo/enterprise#97151

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
-----------------------