**Problem:**
When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete.

**Cause:**
The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records.

**Solution:**
Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone).

**Performance Stats:**
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|100         |3.1s       |393           |0.8s      |117          |
|1,000       |22.3s      |2,090         |1.5s      |183          |
|10,000      |Timeout    |N/A           |6.7s      |541          |

opw-6087422

Forward-Port-Of: odoo/odoo#269876
Forward-Port-Of: odoo/odoo#263953

`*` = `ewaybill_Stock, sale_stock, purchase_stock`

**Steps to reproduce:**
* Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`.
* Set the Default Tax Price Setting to "Tax Included".
* Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order.
* Generate an E-Way Bill from the Delivery Challan.

**Observed behavior:**
* The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON.
* The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it.

**Cause:**
* `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped.
* `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24).

**Fix:**
* Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before.

opw-6273101

Forward-Port-Of: odoo/odoo#271492
Forward-Port-Of: odoo/odoo#268504

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

Steps to reproduce:

- Create a storable product with a BoM, routes MTO + Manufacturing,
  costing method FIFO + Perpetual (at invoicing)
- Confirm a sale order for 1 unit → a manufacturing order is created
- Set a Delivery Date on the SO (Other Info tab)
- Increase the SO line qty to 2
- Validate the MO → traceback on finished_move.ensure_one()

Problem:
When a delivery date is set on the SO, it propagates to the MO's
finished move via date_deadline. However, `production.date_deadline\
was not updated (guarded by `if not production.date_deadline`) because
the MO already had a deadline set at planning time:
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L476

When the SO qty then increases, change_production_qty copies the
finished move to create a delta move. That delta move receives
production.date_deadline (the stale planning date) instead of the
delivery date, so the two finished moves end up with different
deadlines and cannot be merged:

https://github.com/odoo/odoo/blob/19.0/addons/mrp/wizard/change_production_qty.py#L43

Solution
- always update production.date_deadline from its finished moves
- link the new delivery move to the finished move after the qty
  wizard runs so it gets reserved after MO validation

opw-6273076

Forward-Port-Of: odoo/odoo#269405

When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.

Forward-Port-Of: odoo/enterprise#118824

[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf)
and deduplicating overlaps

* Current Situation: Currently real duration is total duration of each
time tracking which
is not consistent with the time that use to calculate the cost for
valuation , see https://github.com/odoo/odoo/pull/205154 .The real
duration of a work order was incorrectly summing all time tracking
entries regardless of their loss type, and using simple addition which
double-counts overlapping intervals.

* Solution:
- Filter time entries to only 'productive' and 'performance' loss types,
  excluding 'availability' and 'quality' as they represent
downtime/blocking
  time, not actual work duration.
- Pool all productive and performance entries into a single Intervals
call
  so that overlaps across both types are merged in one pass.

Note: the enterprise17 implementation groups time entries by loss_type
into
separate buckets before calling Intervals, which means overlaps between
'productive' and 'performance' entries are not merged and get
double-counted.
Pooling both types together before the Intervals call avoids this.

* This also fix:
- Fix _set_duration to ensure newly created time entries start after the
  latest existing entry's end date. Without this, calling _set_duration
  twice in quick succession (e.g. in tests) produces two entries with
  overlapping timestamps, which Intervals correctly merges into one,
  causing the computed duration to be half the expected value.




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

Forward-Port-Of: odoo/odoo#248381