Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
    - weight: 10 kg
- Create a delivery picking:
    - Add one unit of P1
    - Mark as “To Do”
    - Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0

Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
    - `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
    - `pack.shipping_weight` is 0 on creation.
    - The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13

opw-5357843

Forward-Port-Of: odoo/odoo#245223
Forward-Port-Of: odoo/odoo#238917

__
Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 
__
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

Nothing happens

When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546

The company isn't taken into account in the domain, applying the holiday for every company.
 __
opw-5222883

Forward-Port-Of: odoo/odoo#246994

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#248318
Forward-Port-Of: odoo/odoo#236276

Issue before this commit:
=========================
When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")`
in the `Number of SN` field of the Generate Serials/Lots wizard, 
a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`.

Steps to Reproduce:
=========================
- Install the "stock" module.
- Create a receipt for a serial-tracked product.
- Open the detailed operations.
- Click on "Generate Serials/Lots".
- Enter a string value in the "Number of SN" field.

Result: A traceback is raised with:
InvalidNumberError: `"dhha" is not a correct number.`

Cause of the issue:
=========================
The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) 
field is defined as type="text", which allows users to enter string values, 
even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), 
which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139).

With This Commit:
=========================
The input type is changed from type="text" to type="number", ensuring that 
only numeric values can be entered. This prevents invalid input and avoids the 
traceback when generating serial or lot numbers.
Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`,
ensuring that only integer values are allowed.

Forward-Port-Of: odoo/odoo#248529
Forward-Port-Of: odoo/odoo#248221

The aim of this commit is to prevent a csv import to timeout by applying the `limit_time` parameter for real.
We also added the `company_id` parameter to the caller to maximize the chances of processing the lines of the statement being imported first.

Context:
1) `_cron_try_auto_reconcile_statement_lines` was modified a few times in
   the last months with the bank reco widget revamping, the perf issues,
   etc.

   During that revamp, the timing limitation was made irrelevant if a
   `batch_size` wasn't provided.

   While it makes sense that the time limitation is irrelevant without a
   batch, not raising an error resulted in the client code letting the
   caller think the time limitation will be applied.
   Instead, we could provide a default batch_size.

2) The `company_id` parameter wasn't set which combined with no
   batch_size results in trying to reconcile the entire accounting
   from every company to which the user has access.

Before this commit:
- The limit_time parameter is ignored if the `batch_size` parameter isn't provided processing everything in the current transaction.
- The company_id parameter wasn't set resulting in trying to reconcile the whole accounting from all accessible companies in the current transaction.

After this commit:
- We provide a default `batch_size` of 100 and thus we really apply the timing
- We provide the `company_id` parameter to limit the reconciliation to the company of the statement.

opw-4890008