Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404

Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.

Steps to Reproduce on Runbot:

1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location. 
5. Create a new route.
6. Create new rules on this new route with the following configurations:
   1. Rule 1
      1. Action: Pull
      2. Source location: WH/Stock
      3. Destination location: Partners/Customers
      4. Operation type: The new pick operation type
   2. Rule 2
      1. Action: Push
      2. Source location: New pack location
      3. Destination location: WH/Output
      4. Operation type: Pack
   3. Rule 3
      1. Action: Push
      2. Source location: WH/Output
      3. Destination location: Partners/Customers
      4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it. 


opw-6026918

Forward-Port-Of: odoo/enterprise#114020
Forward-Port-Of: odoo/enterprise#112543

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

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

Forward-Port-Of: odoo/odoo#259076
Forward-Port-Of: odoo/odoo#257012

**Purpose:**
Since a stock.quant is a combination of the stock move lines of a product
and a location, it should be restricted by the product's company.

**Before this commit:**
In a multi-company environment. If a purchase order with product from
company 1 is being confirmed, received, and validated when company 2 is
being selected as the primary active company while company 1 is also
checked. It will create a stock.quant that is searchable for company 2.
However, it will raise an error when company 2 is trying to access it.

**After this commit:**
Even if the stock.quant is created when company 2 is the primary active
company, it will not be searchable for company 2 since the product's
company is company 1.

**Steps to Reproduce on Runbot:**

- Create a storable product exclusive to Company A
- Create & validate a receipt for that product in Company A.
- Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible.

opw-6082330

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

Forward-Port-Of: odoo/odoo#259733
Forward-Port-Of: odoo/odoo#257211

### Steps to reproduce:

- In the settings Dropshipping
- Put you warehouse in 2 steps delivery
- Create a kit product with 2 components: COMP1, COMP2
- Set a vendor on COMP2 and the dropship route
- Create and confirm an SO for 1 unit of your kit
- Validate the ship and pick for COMP1
- Confirm the PO for COMP2 and validate the associated dropship
#### > The qty_delivered on the sol is still at 0

### Cause of the issue:

The `delivered_qty` is computed via the `_prepare_qty_delivered`: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale/models/sale_order_line.py#L887-L902 However, since at least on of the component is dropshipped, the qty_delivered is computed by this condition: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L54-L63 Which is 0 since the pick `location_dest_id.usage` is not `customer`.

### Additional issue:

The delivered quantity of a Kit with at least one dropshipped component can only be 0 or the full demand.

- In the settings enable Dropshipping
- Create a kit product with 2 components: COMP1, COMP2
- Set a vendor on COMP2 and the dropship route
- Create and confirm an SO for 3 unit of your kit
- Validate the delivery for COMP1 for 2 units and backorder
- Confirm the PO for COMP2 and validate the associated dropship for 1 unit and do not backorder
#### > The qty_delivered on the sol is 0 instead of 1
- Cancel the backorder for COMP1
### > The qty_delivered on the sol is 3 instead of 1

### Cause of the issue:

This is caused by the exact same dropship computation: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L63-L66

### Note:

The behavior should be consistent if the components are fully dropshipped or MTO buy and as such they should not be considered to be in all or nothing shipping policy.

opw-6040640

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

Forward-Port-Of: odoo/odoo#258739
Forward-Port-Of: odoo/odoo#257617

Steps to reproduce:
- Go to knowledge
- Type "/view" in the article -> add a list view
- Open a dropdown in that list view (e.g. the cog icon next to "New")
- Click outside the list view (e.g. first paragraph of the knowledge
  article that contains the list view)
=> The dropdown does not close

Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though).

[1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478
[2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36
[3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e

Forward-Port-Of: odoo/enterprise#114082

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.

**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.

- This leads to runtime issues such as:
    - Cannot convert field to SQL because it is not stored
    - Failures in search, domains, and reporting
    - Inconsistent behavior depending on usage context

- Currently, no validation prevents users from configuring such invalid related fields.

**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.

- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.

This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.

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

…e_journal_ids and it differs from the current journal_id

This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company."

Description of the issue/feature this PR addresses:

The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company."

Current behavior before PR:

When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal.

Desired behavior after PR is merged:

When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it.


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

Forward-Port-Of: odoo/odoo#259573

**Issue**:
Even when creation of new Serial Numbers for components is disabled
on the Manufacturing Operation Type, it is still possible to create
them from the shopfloor application.

**Steps to reproduce**:
- Enable "Lots & Serial Numbers", on the global settings
- Create two products, one tracked by unique serial number
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Select Manufacturing and disable "Create New Lots/Serial Numbers for Components"
- Create and confirm a MO using the tracked product as component
- Go to shopfloor
- Click the "+" button next to the component, then "New"
-> No error is raised when creating a serial number

**Cause**:
The `_check_create` constraint relies on `active_mo_id`:
https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19
However, the shopfloor does not pass this, in context:
https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199

As a result, the check is bypassed.

opw-6041241

Forward-Port-Of: odoo/enterprise#111408

## Problem:
Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for meetings that occurred in the past.

It is not yet clear why this is happening (needs more investigation), but we
quick fix this by correctly checking that an attendee is not part of an event
on an past date before triggering emails during the `write`.

## Steps to reproduce the bug:
1. Create an new event in the past and save
2. Add a new attendee (partner) to the event SHOULD NOT create a notification email (but it does)

## Remarks:
- readapting existing unit test for `test_event_creation_mail`, but a proper new unit test might be needed in a proper refactor. As of now we were never testing if emails are triggered when adding new attendees on an event in past
- giving this, this bug might be affecting previous versions. Might need to be backported and tested if needed
- added time freeze to `test_event_creation_internal_user_invitation_ics` to account for the fact that implicitly the tested event was in the past
- `freeze_time` for certain tests using the class event, which has hard coded dates

OPW-6125052

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

Forward-Port-Of: odoo/odoo#259844

1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)

To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
    result = func()
             ^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
    edi_users._peppol_get_message_status()
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
    processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
    peppol_response = uuid_to_record[uuid]
       ^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```

task-None

Forward-Port-Of: odoo/odoo#259834

### Problem:
When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to another company will debit the stock output account, but returning the delivery will create an account move that credits the stock input account. Compare this to normal return behavior which will credit the stock output account to reverse the original delivery's entry.

### Solution:
When deciding whether a stock move is a return, we will include transit locations as valid locations.

### Steps to reproduce (Runbot v18)
- Automatic accounting
1. Create a SO for the automatically accounted product, selling to another company in the system
2. Validate the delivery, check the valuation and note there is a debit on the stock output account
3. Create a return for the delivery and validate it, check the valuation and note the credit on the stock input account

To clarify, this differs from when the customer on the SO is anything other than a res.company, where we will see a credit on the stock output account when the return is validated.
Also, this flow is the same for POs, and the same bug is addressed by this fix.

### Before
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td style="{color: red}">Stock input</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

### After
(Or normal behavior without inter-company transfer)
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td>Stock output</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

opw-5993147

Forward-Port-Of: odoo/odoo#255439

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