Currently, accessing the Forecast report on a Product Template causes a crash if the template contains an archived variant that still has active stock moves (e.g., a pending delivery).

## **Steps to Reproduce:**
1) Install `stock` with demo data.
2) Create a Delivery orders(stock picking) for product `conference chair(E-COM12)`
   with demand of 40 qty, click on `Mark as todo`.
3) Navigate to `stock>products>products` and open `conference chair` product form
   view.
4) From the variant smart button archive `E-COM12` variant.
5) Navigate back to product form view and click on `forecast` smart button.

## **Error:**
`TypeError: Cannot read properties of undefined (reading 'free_qty')`

## **Root Cause:**
`this.props.docs.product[line]` at [1] is undefined because the server did not
include an entry for that product id in the report header.

### **Complete Flow:**

On clicking the Forecast button an ORM call is made to [_get_report_values](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L512-L519),
which calls [_get_report_data](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L156-L172) to build the report data.

#### **Header Part:**
- [_get_report_header](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L112-L144) returns metadata only for active variants because,
  [_get_product_quantity](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L69-L72) is called which calls _get_products(see[2]), and _get_products only
  returns active variants for the product template.

#### **Lines Part:**
- [_get_product_lines](https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L239) iterates over products coming from the move search
  and it includes both archived and unarchived variants.
  [_move_confirmed_domain](https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L55-L56) calls _move_domain(see[3]), which searches stock.move using
  product_tmpl_id when given a template id and therefore returns moves for
  every variant of the template (archived or not).

#### **Why the mismatch happens:**
- `_get_products` fetches variants using `browse()` which by default excludes archived variants.
  `_product_domain`(see[3]) uses product_tmpl_id when given product_template_ids,
  which matches moves for all variants of the template. As a result, moves can reference
  archived variant ids that the header never listed.

[1]- https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/static/src/stock_forecasted/forecasted_details.js#L188

[2]- https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L61-L67

[3]- https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L25-L31

## **Fix:**
- This commit ensures that archived product variants are excluded directly
  at move search level by appending `('product_id.active', '=', True)` to
  the product domain used by the forecast report. This ensures that only
  active product variants are considered when fetching stock moves.

### **opw-5440872**

Forward-Port-Of: odoo/odoo#245852

**Problem:**
the cogs do not take into account lot valuation and the standard 
price of the form is not updated after a move out.

**Steps to reproduce:**
- create storable avco perpetual product, tracked and valued by lot
- confirm a purchase order for 2 qty at price 10
- in the receipt add 'lot 1' for the lot
- validate
- confirm a purchase order for 2 qty at price 16
- in the receipt add 'lot 2' for the lot
- validate
- confirm a sale order for a qty of 1, validate the move
- invoice the sale order, and confirm the invoice

**Current behavior:**
1) the cogs line (stock valuation and expenses) have a value of 13
(the avco value)
2) the standard price on the form view is still 13

**Expected behavior:**
1) it should be 10 (the value of lot1)
2) it should have been updated to 14 (weighted average of the lots value)

**Cause of the issue:**
1) get_cogs_price_unit() is taking standard price of the product
if the product is not fifo.
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/stock_move.py#L245 
In case of avco lot valuated product, this is not correct, the value should be 
the sum of (the value of each lot * the number of product from this lot in the 
moves) divided by the total quantity. 
this value can be obtained be dividing the total value of the moves by the total 
quantity. 

2) after the move is validated, the standard price should be updated because 
for lot valued product, the avco value can change after a move out. 
Currently it's only updated for fifo products.
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/stock_move.py#L172

**fix**
For the diff inside _update_standard_price() for problem 2,
I use avg_cost instead of doing the computation directly in 
_update_standard_price() to not duplicate code logic
 because the computation logic for lot valued products is 
already inside _compute_value()
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/product.py#L152-L157

The extra dependency on compute_value on the stock.lot model 
is needed because otherwise total_value of the lot is not 
invalidated in the cache after an out mouve is validated
(in our steps it will stay in cache with a value of 20 even 
after the out move is validated). 
With our steps this does not cause problem because when we use 
the avg_cost value for the product,  \__get__() is called on total_value of the lots, 
but it was not in cache because we didn't compute it before in 
this environment , so it will be recomputed with correct current value . 
But in other cases where the action_done is called on 
the move and there is already a value in cache for total_value 
of the lots (like in the test of this commit for instance), 
this value will become wrong after the move is validated 
and the cache won't be invalidated which will lead to 
incorrect computation of avg_cost because it will use the 
wrong cache value of total_value for the lots.

the test needs to be in sale_stock because the moves used 
for the cogs are being returned via the sale_stock override 
of _get_stock_moves()
https://github.com/odoo/odoo/blob/7ae112acd0c333f09c54e4eabbd22bcef72c32a7/addons/stock_account/models/account_move_line.py#L67

opw-5459082

Forward-Port-Of: odoo/odoo#246821

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Forward-Port-Of: odoo/odoo#248009
Forward-Port-Of: odoo/odoo#241603

**Issue**
When producing a large number of serial-tracked products, a RecursionError can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo
-> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/odoo#247839

### Steps to reproduce:

1. In the settings enable: Multi-steps route
2. Put your warehouse in 2-step deliveries
3. Create a kit product:
   - With one component
   - There is one component in the stock
4. Create and confirm a SO with 1 x K
5. Process the pick and ship
6. Return the delivery
7. Set the sol qty to 0
#### > Two unexpected pickings are created to put the kit in output

### Cause of the issue:

Decreasing the sol quantity to 0 will call the `_action_launch_stock_rule` in order to create and run procurements related to that quantity change. However, the quantity currently handled by other procurements is determined here by the `_compute_kit_quantities`:
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_mrp/models/sale_order_line.py#L154-L166 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/mrp/models/stock_move.py#L578-L580
Now, the issue is that `_compute_kit_quantities` does not handle move chains properly, as all delivery moves contribute to the `incoming_qty` and all return moves contribute to the `outgoing_qty`. This results in an `incoming_qty` of 1 (for the pick) + 1 (for the ship) and an `outgoing_qty` of 1 (for the 1-step return), that is a `qty_processed` of 1. As a result, the procurement will be generated for a quantity of `0 - 1` (rather than 0):
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388-L402 
which leads to the unexpected picking creations.

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

Forward-Port-Of: odoo/odoo#246141

This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines.

Steps to reproduce:
1. Create payment with x amount and validate it.
2. Open the payment journal entry.
3. Reset to draft and update the liquidity line amount from x to (x - y)
4. Create another liquidity line with amount y to balance entry and post it.
5. Draft the payment and try to update the amount.

A traceback will appear. `ValueError: Expected singleton`

Cause:
The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error.

Description of changes made:
While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write.
Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually.

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

Forward-Port-Of: odoo/odoo#246675

## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift

Before this commit, the user could update the shift linked to a rental
order and creating a conflict with another shift for the same resource
and so, it would be impossible for the resource to be in 2 spaces at the
same time (or it is impossible to rent a room to 2 different customers).

This commit returns an Validation Error if the user updates the planned dates
of a rental shift and creates a conflict.

## [FIX] sale_renting_planning: add problematic shifts only if rental order

Before this commit, the previous fix making sure the error, saying no
resource is available during the generation of a shifts when the user
confirms a sale order, is only displayed when the `Sync Shifts and
Rental Orders` is enabled, could potentially never display the error
when it should be expected because we only check if the last SOL of the
batch to generate shifts has the feature enable or not.

This commit makes sure the error is correctly displayed as expected.

## [FIX] sale_renting_planning: update condition of Rental buttons in shift

Before this commit, the user could click on Create order button for an
open shift is the role having the rental feature enabled. To problem is
a resource is required to make sure the rental order can be delivered.
About the other button shown, `Add to Last Order` one, this one could be
clicked even if the shift is in conflict with another shift and so, it
will display a warning saying no resource is available.

This commit makes sure
- `Create Order` button in shift form view is not
visible when the shift is a open shift.
- `Create Order` and `Add to Last Order` buttons in shift form view are
not displayed when the shift is in conflict.

task-5065930

Forward-Port-Of: odoo/enterprise#97024

Currently, an error occurs when selecting a date on a rental product. 

**Steps to Reproduce:**
 - Install the `website_sale_stock_renting` module.
 - Go to `Products` and create a product with the following `configuration`:
   - Enable `Track Inventory` and set `Quantity On Hand` greater than zero.
   - Disable `Sell when Out-of-Stock` under the `eCommerce tab`.
   - Under the `Sales tab`, set `Periodicity to Days`, and set the same time for `Pickup and Return`.
 - Go to `Website > Shop`.
 - Open the product, select the same date for both `Start Date and End Date`, and `click anywhere`.

`ValueError: min() iterable argument is empty`

**Cause:**
 - This error occurs because when the start and end dates are the same, the method returns a set 
   of dates from here [1]. Since there is only a single date, the loop is not executed and it returns 
   an empty list of availabilities [2], which then raises the error [3].
 - The error happens due to the removal of this condition [4] in this [recent commit].
 - The warning message is now handled here [5].

**Fix:**
 - This commit ensures that when a user selects a start date that is greater than or equal to the 
   end date, a UserError is raised and the proper warning message is displayed.

[1]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/sale_stock_renting/models/sale_order_line.py#L616

[2]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/product_product.py#L77

[3]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/website.py#L18-L22

[4]: https://github.com/odoo/enterprise/blob/66f144df6f2056212797547dfef5ed58232698cd/website_sale_renting/models/product_template.py#L175-L176

[5]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_renting/static/src/interactions/daterange_picker.js#L213

[recent commit]: https://github.com/odoo/enterprise/commit/4afdc272e5a7fc4284bbd9f97283b8ec0aa28c34

sentry-7243018656