**1) Context**

Some reports (typically Balance Sheets) compute themselves over the whole accounting history, up to a certain date. On big databases, this is a problem, as the more the accounting grows, the slower those reports get.

To handle that, a lot of softwares (as well as Odoo, before 9.0) require creating opening entries at the beginning of every fiscal year, to just carry the balance of each account from period to period. The report would then only consider the entries of the current year, which would include the initial balance.

The problem with opening entries is that they can very easily get desynchronized from actual accounting history. You can't modify something coming before them without needing to fix them as well, and it's very error-prone. Moreover, they do have an existence into the accounting itself, cause noise, and are far from ideal for handling customer accounts. For all those reasons, they were removed in Odoo 9.0, and we are not reintroducing them.

What this commit does, however, is introducing a new mechanism that precomputes and somehow caches those parts of the reports that consider the entire history. This new mechanism is designed to be at the same time completely invisible to the users (outside of the obvious performance gains, that is), resilient, and not too technically complex (I promise).


**2) How it works**

The key idea is to cache the results of the calls to report engines. For this, we introduce a new model: account.report.snapshot. An instance of this object corresponds to the result of a single engine call.

- Snapshot generation

Snapshots are generated asynchronously, via a cron. This cron does not run periodically by itself (to avoid useless server load). Instead, it is only called via explicit triggers, when snapshots need to be refreshed. It is made to be as lightweight as possible, and will create only one snapshot at a time, retriggering itself if needed, so that other crons' execution can easily be interleaved with it.

The cron is typically triggered when modifying the lock date: a new snapshot is then created for the appropiate engine calls at that new lock date. If no snapshots were done before, we basically generate them on the last 5 years, so that period comparisons can also benefit largely from it.

Snapshots are incremental: when a new snapshot is taken, it uses the previous snapshot made for the same parameters on an earlier date, and only calls the report engine on the period that's not already covered.

- Impact on engines

A report engine (custom or standard) can be made snapshotable using a dedicated decorator. When it's declared like that, its call will be wrapped in another function that will make sure to only call the engine on the period that's not already covered by a snapshot. If the period is fully covered, the engine will simply not be called, and we hence will run no additional SQL. This makes for tremendous performance gains.


**3) Requirements and limitations**

- Not all engines are snapshotable

The computation of an engine needs to be dividable into summable "partitions" in order to allow snapshots. I other words, computing all the parts separately and then putting them together must give the same result as directly computing the full thing. These partition will be created by the cron, splitting the data by date and company (a snpashot is always made for a single company, at a given date).

If an engine's computation can be partition, but requires some post-processing using the global results, it's possible to snapshot a single subfunction instead of the engine itself. We call that a subengine. See what account_codes standard engine is doing for an example.

- Snapshots are generated for default options only

The cron only generate snapshots for the default values of the report's filters. So, if the user changes the value of one of those filters (except the date, of course), the recomputation of the report will not find any snapshot. This is deemed acceptable : the goal is not to make every single possible case super fast. We just want the basic and most common flows to be seamless.

- No multi-currency consolidation

As it is, multi-currency consolidation is not supported by snapshots.


**4) Partners, read this**

Snapshots can of course be generated by custom code as well. This could be the key to long-going performance issues in specific flows : just make an additional snapshot for the specific options dict involved in that flow.
We'll refine the feature a little more in the future to give even more flexibility to those cases.


**5) Additional changes made by this commit**

- Record Rules don't impact report computation anymore

Before this commit, and since the dawn of times (AKA, version 9), the computation of the report applied custom-made record rules created for account.move.line. This was an old implementation choice that we kept for years because we had no need of removing it, despite the fact we saw no use for it. This has now been removed: if we kept it, snapshots would have been impossible, since using them on a database with such record rules could have given wrong results (because different users could technically have needed to see different amounts for the same report, with the exact same filters).

- Custom engine signatures

All custom engine signatures change: they now use exactly the same parameters as standard engines, and not a simplified version of it anymore. The format of their return values changes in the same way. This is done so that the @snapshotable_engine decorator can be used indistinctly on both standard and custom engines.

- Engine function names

Engine functions used to require different prefixes in their names for standard and custom engine ; not anymore. Everything is now prefixed _report_engine_. It's clearer and makes the computation of snapshots easier.

task-5891829

Introduce a VoIP feature that allows users to transfer an ongoing call from one tab/device to another (e.g., from desktop Chrome to desktop Firefox or a mobile device).

The transfer follows a pull model: the target device (Device B) initiates the process via "Switch here". It requests the source device (Device A) to send a SIP REFER to its own AOR (Address of Record). The PBX then issues a new INVITE to the AOR, which Device B automatically accepts, completing the transfer.

Task-4417476

```mermaid
sequenceDiagram
    participant A as Device A
    participant PBX
    participant B as Device B
    participant C as Device C

   Note over B: create pull

    B->>A: bus: voip.call.pull/initiate
    
    Note over A: create push

    A->>C: bus: voip.call.pull/suppress_invite
   Note over C: _ignorePhoneNumbers(phone_numbers)

    A->>B: bus: voip.call.pull/pending_entries
    Note over B: store pendingEntries on pull


    B->>A: bus: voip.call.pull/pending_entries_received
    Note over A: _ignorePhoneNumbers(phone_numbers)
    A->>PBX: REFER (own AOR)

    par Invitation sent
    PBX->>A: INVITE (new call)
 Note over A: phone_number in _ignoredPhoneNumbers <br/> not shown + no ringing

    PBX->>C: INVITE (new call)
    Note over C: phone_number in _ignoredPhoneNumbers <br/> not shown + no ringing   
    PBX->>B: INVITE (new call)
Note over B: pendingEntries matches phone_number <br/>auto-accept + no ringing

   end

    B->>PBX: 200 OK

    PBX->>A: REFER 202 Accepted
    Note over A: onAccept -> hangup()
    A->>PBX: BYE

B->>A: bus: voip.call.pull/result
Note over B: display stats + delete pull
Note over A: display stats + delete push

```

Task-4417476

**Problem:**
Clicking on the Analytic Distribution field in the expense form triggers a traceback: "Cannot read properties of undefined (reading 'fields')".

**Steps to reproduce:**
1. Enable Analytic Accounting in Settings > Accounting
2. Go to Expenses > New
3. Click on the Analytic Distribution field
4. Observe the JS error in the console

**Current behavior:**
TypeError: Cannot read properties of undefined (reading 'fields') in HrExpenseFormRenderer.getBoxType

**Expected behavior:**
Clicking the Analytic Distribution field should not cause any error.

**Cause of the issue:**
The `ExtractMixinFormRenderer` mixin listens to all `focusin` events and calls `getBoxType` to determine the OCR box type for the focused field. When a nested widget like `AnalyticDistribution` gains focus, `getFullFieldName` returns a dot-separated name (e.g. `analytic_distribution.x_plan_id`), causing the code to enter the dotted-name branch in `getBoxType`:
`this.props.record.data[parentField]?._config.fields[fieldName]` The `analytic_distribution` data is a JSON object, not a relational record, so it has no `_config` property. Optional chaining on `data[parentField]` prevents a crash when the field is missing, but the missing `?.` on `_config` causes `undefined.fields` to throw.

**Fix:**
Adding optional chaining on `_config` is consistent with the existing defensive pattern already used on the same line for `data[parentField]?` and `[fieldName]?.type`. This makes `getBoxType` gracefully return no box type for non-relational nested fields, which is correct since OCR box overlay is not applicable to them.

opw-6108576

In German location with Fiskaly setup.
POS users hit an AccessError on read when closing the session from the frontend,
then had to finish closing in the backend with admin (base.group_erp_manager) rights.

Steps to reproduce:
-------------------
* Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly
* Use a user with POS rights only (no Access Rights)
* Open POS, sell, then close the session from the POS UI

> Observation:
A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read).

Why the fix:
------------
The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is
already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials.
Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required;
this change fixes unnecessary reads of protected fields in the tax helper,
not the security model of the credentials themselves.

opw-6074960

Forward-Port-Of: odoo/enterprise#114006
Forward-Port-Of: odoo/enterprise#112618

This PR removes the technical field `manual_consumption` logic from mrp.

Before this PR:
If a move is marked as `manual_consumption=True`, its consumed quantity is not automatically updated on the MO. `manual_consumption` logic basically depended on the move being linked to an operation on the bom_line_id.

After this PR:
No more `manual_consumption` field. A move's consumed quantity is not automatically updated if it's picked.
How the move is being picked is the same which is by marking a move as consumed in the shopfloor app, marking a work order that has component moves as done or simply editing the consumed quantity on the MO form.


Changes in behavior:
- If the move is marked as picked => it's no longer automatically updated.
- Using barcode for mrp: When updating the qty_producing on the finished product, exiting the barcode and entering again => the quantity on the move lines reflect the new changed qty_producing and no more unpicked split move lines are created. However, changing the quantity on the move Lines (instead of the qty_producing) causes the move lines to split as expected [this is not necessarily a limitation but it can be improved if needed].

Community PR: https://github.com/odoo/odoo/pull/253649
Upgrade PR: https://github.com/odoo/upgrade/pull/9794
Task: 5882264

This commit refactors and improves the follow-up system to make reminder
handling more consistent and user-friendly.
1. Configuration flow updated
Follow-up levels were previously configured under:
Invoicing → Configuration → Follow-up Levels
They are now available under:
Invoicing → Settings → Automatic Invoice Reminder

2. Reminder timing improvement
Previously, users had to enter a negative delay to send reminders before the due
date.
A new field reminder_timing has been introduced to explicitly choose whether
the reminder is sent before or after the due date.
Delay values are now always positive.

3. Reminder logic refactored
Automatic follow-ups were previously based on the partner's follow-up level,
which could lead to inconsistencies.
Follow-ups are now based on the account move line follow-up level, ensuring more
accurate and consistent reminder progression.

4. Follow-up status removed
The `followup_status` field has been removed from `res.partner` as it is no
longer required.

5. Manual reminder from invoice
Users can now send invoice reminders directly from the invoice.
If `Send & Print` is executed again on an overdue invoice, the email template
automatically switches to the appropriate reminder template and attaches
the follow-up report.

6. Last reminder tracking
A new field last_reminder has been added to `res.partner` and `account.move`
This field stores the date of the last reminder sent for the customer or invoice.

7. New mail templates added
3 templates for manual reminders from invoice
2 templates for automatic reminders and batch reminders from invoice list view

task-5241209

com: https://github.com/odoo/odoo/pull/245403
upg: https://github.com/odoo/upgrade/pull/9587