Version:
----------
- 18.0+

Steps to reproduce:
----------------------
1. Install `sale_management`, `purchase`, and `stock` module.
2. Go to Settings and enable Reception Report.
3. Create a storable product with tracking enabled and add
supplier information.
4. Create a Sales Order for the product with a quantity and confirm it.
5. Open the generated Delivery Order and note the deadline value.
6. Create a Purchase Order for the same product and quantity  using the vendor
set on the product and confirm it.
7. Open the generated Receipt and click on the Allocation smart button.
8. Assign the receipt to the delivery order.
9. Go back to the Purchase Order and change the Expected Arrival Date.

Issue
- Updating the Expected Arrival Date on the Purchase Order also updates
the deadline of the related Sales Order delivery.

Root cause:
------------
- Clicking Assign triggers `action_assign`, which links incoming and outgoing moves:
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/report/report_stock_reception.py#L271

- Updating the PO Expected Arrival Date triggers purchase.order.line.write(),
which calls  _update_move_date_deadline(new_date).
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L100-L101

- Then this `_update_move_date_deadline` function updates the incoming move
`date_deadline` and this  triggers stock.move.write().
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L165

- Inside write(), _set_date_deadline() is called.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/models/stock_move.py#L748-L749

- Inside `_set_date_deadline()`, the method calls` _get_moves_to_propagate_date_deadline()`
to collect all related moves that should be updated.
- This method includes `move_dest_ids` in the returned moves.
Since the incoming move is manually linked to the delivery move,
the corresponding outgoing move (from the Sales Order) is part
of `move_dest_ids`, and its `date_deadline` is therefore updated as well.

https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/models/stock_move.py#L553

https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/models/stock_move.py#L545

Solution:
----------
- Limit propagation to moves that share the same `group_id` or
where no formal procurement group/picking link is established.
- This prevents unintended date shifts across unrelated documents (manual links)
 while preserving correct behavior for standard MTO and Manufacturing flows.

---

opw-6085890


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

The planning.slot model has the field timesheet_ids which is computed and non-stored. It also has a dependency on
`project_id.timesheet_ids.unit_amount`. As timesheet_ids is non-stored while it's a dependency of the field `effective_hours`, if a single timesheet is modified on a project, a recomputation is required on all planning slots on that same project. Before this commit, the dependency highlighted earlier was resulting in a huge unnecessary computation since otherwise there's no way for the ORM to scope this computation to only affected slots. This commit elimintates this dependency and manually invalidates the timesheet_ids field on only the associated slots which drastically improves performance. A recomputation should only be done in case of write/create since timesheet_ids is computed nonstored.

## Benchmarks:
### The time it takes to update or create a timesheet in a specific project:

| No. planning slots in project | Before  | After | 
| ----------------------------- | ------- | ----- |
| 699838                        | Timeout | <1s   |
| 107203                        | ~130s   | <1s   |
| 7812                          | ~9s     | <1s   |

opw-5082577

### Issue
A user cannot open their bank journal if some rules are too slow to compute or consumes too much memory.

### Solution
This commit refactors the `_is_eligible_for_early_payment_discount` method on `account.move` to improve performance during bank reconciliation. The method was designed to run on a single record and was being called inside a loop when generating reconciliation suggestions.

A new method, `_is_eligible_for_early_payment_discount_batched`, has been introduced to handle the eligibility check for a recordset of moves. The original `_is_eligible_for_early_payment_discount` method is preserved as a wrapper around the new batched method to maintain backward compatibility.

Enterprise PR: https://github.com/odoo/enterprise/pull/92401

### Benchmarks
Profiling `_get_invoice_matching_amls_result` when using a reconciliation model with a Partner mapping:
| # of amls | Before | After | % |
|:-------------:|:-----------:|:------:|:----:|
| 499           | ~3 min then MemoryError |  230 ms | 99.9 % |
### References
opw-4998109

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

## Problem

In `account_reconcile_wizard.py`, the internal helper `get_reco_currency` (inside `_compute_reco_wizard_data`) returned the single foreign currency found among the selected lines without checking whether any residual in that currency actually remained after the reconciliation plan ran.

When reconciling a company-currency line against a foreign-currency line where the plan fully consumed the foreign-currency residual (leaving only a small company-currency exchange-difference balance), the wizard still set `reco_currency_id` to the foreign currency, inflating the write-off amount by the exchange rate.

## Root cause

```python
elif len(foreign_currencies) == 1:
    return foreign_currencies  # ignores whether the plan left any residual in that currency
```

## Fix

In the `elif len(foreign_currencies) == 1:` branch, iterate over `aml_values_map` (post-plan residuals) and return the foreign currency only if at least one line still has a non-zero residual in it; otherwise fall back to company currency.

## Test

`TestAccountReconcileWizard.test_write_off_receivable_company_currency_vs_foreign_currency`

Reconciles a company-currency debit (111.0) against a foreign-currency credit (−110.0 / −330.0 EUR at rate 3.0). The real remaining difference is 1.0 in company currency. The test asserts that `reco_currency_id` is the company currency and `amount` ≈ 1.0.

Task reported at: https://www.odoo.com/my/tasks/6315581