Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#112811
Forward-Port-Of: odoo/enterprise#107671

**Steps to reproduce:**
- Create 2 products, set their price to 0
- Create a combo product, set it's price to 10
- The combo choices should be the 2 products created before
- Go to the self order, order the combo and change the qty to 3
- The price is 30, correct in the frontend
- Go to the order in the backend, the price is 0

**Why the fix:**

In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines.
This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code
https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 
But the total price has been computed to zero, so the previously computed price_unit is overriden and set to zero.

We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line.

The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation.

opw-6032408

**Problem:**
The cost is not correctly computed on sale order 
line when the product is dropshipped.

**Steps to reproduce:**
- enable "margins" and "dropshipping" settings
- create a tracked, fifo product with dropship route
- add a vendor in the purchase tab
- confirm a sale order for 1 unit
- set a unit price of 10 in the PO and confirm it
- validate the dropship picking
- come back to the sale order and unhide de cost column

**Current behavior:**
the cost is 0

**Expected behavior:**
the cost should be 10 based on the unit price of the PO

**Cause of the issue:**
To compute the purchase price, when there is valued moves 
linked to the sale order line and the product is fifo/avco, 
we call _get_price_unit() on the moves.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/sale_stock_margin/models/sale_order_line.py#L21
Which uses the value of the moves
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/stock_move.py#L237-L243
But for dropshipped move the value on the moves is always 0.
So the return value will be 0 and purchase price will be 0.

**fix:**
- The idea of the fix is to use _get_value() instead of the move 
value for dropship moves. 
This approach is already used in the code inside 
_run_average_batch()
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/product.py#L474-L475

- In case there is not only dropship moves we need to do 
a weighted average


opw-6051004

Forward-Port-Of: odoo/odoo#256089

Steps to reproduce:
1- Install Inventory, Purchase and Manufacturing
2- Enable 'multi-step routes' in the settings
3- Create Product A and create a Bill of Materials (BoM type: subcontracting,  Component A)
4- Repeat the same for Products [B,C] with components [B,C] correspondingly.
5- Assign the same subcontractor to all of them
6- Create a Purchase Order for both Product A and Product B with vendor as the subcontractor and confirm it
7- Add a new order line with Product C and save

Description of issue:
A second resupply picking is created

Expected behavior:
Should group the new product's component with the existing picking

Why this happens:
When assigning the resupply picking for the new product's component, the search domain for the existing picking includes production_group_id, which is different for the added product.
This prevents merging of components into a single resupply picking despite sharing the same destination and purchase order

Fix:
We ignore production_group_id since it is not necessary in the resupply stock moves domain.

opw-5906451

Forward-Port-Of: odoo/odoo#251713

## Versions
18.0+

## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.

## Steps to reproduce
- Create a new SO for any customer:
  - Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
  - Save manually;
  - Change the product for a combo or variant one (e.g. "Customizable Desk");
  - With the opened dialog, change from browser tab then come back;
  - The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).

## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.

## Test
No test as we cannot simulate a browser tab change then come back to the first tab.


opw-5494089

Forward-Port-Of: odoo/odoo#257846
Forward-Port-Of: odoo/odoo#247797