### Steps to reproduce:

- Create a storable product P with a vendor and a subcontracting bom for that vendor.
- Create a purchase order for 100 units with that vendor.
- Validate the receipt R1 for 5 units and backorder
- Validate the backorder R2 for 3 units and backorder
- Validate the backorder of the backorder R3 for 1 units and backorder
#### > The on hand qty of the product is at 99 even thought you registered only 9 units.

### Cause of the issue:

Currently, the above flow associate with the last receipt move with a qty of 1 both a move line for 1 unit and a move line for 90 units. As both will be picked at validation time, the receipt for 1 unit will effectively be treated as a receipt of 91 units. Here are the details:

Updating the quantity of the move of R1 to 5 will in turn update the quantity of the move line to 5 and pick it by the "_set_quantity":
https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L78-L82 https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L139-L143
Then, the first validation (of R1) for 5 units instead of 100 is well processed: it creates a backorder with a receipt move for 95 units and assign it with a single move line of 95.

Similarily, setting the quantity on R2 will set the move line to 3 picked units. However, at validation, the situation will be quite different when assigning its backorder since the move of R2 now has an `move_orig_ids`. This will result in R3 to be assigned by 2 move lines:
- one for 2 units
- one for 90 units instead of one for 92 units.

Indeed, during the action_assign of R3 (triggered by the `_create_backorder` of R2), we try to determine the qty available from done move lines related to our move_orig_ids and its `move_dest_ids` in order to see if there is already an available quantity (bacause more was processed in than out for instance). We will then first create a move line for that available quantity:
https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1873-L1886 and finish the assignment with the `missing_reserved_quantity`: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1907 The issue is that in our case, we should not find any available quantity to assign and the method responsible for this computation `_get_available_move_lines` will still find a discrepency between the available_move_lines_in qty and the available_move_lines_out qty for 5 - 3 that is 2 units
-> We will end up with one move line for 2 units and one for 90.

The discrepency is due to the fact that the
`_get_available_move_lines_in` finds one in move line **done** for 5 units of R1. But that the `_get_available_move_lines_out` first finds the move line **done** for 5 units related to R1:
https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1817-L1821 But then erase the values by the demand of 3 provided by the **partially_available** move line of R2 that we are currently validating and that we should not have considered in the present flow: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1822-L1823

In particular, we end with a picking R3 for 92 units and 2 move lines. Now, setting the quantity of R3 to 1 will update the quantity of the first move line to 1 and set it as picked without altering the second one as the update of the quantity can totally be handled by the first move line. We therefore end up with a move with a move with a quantity of 1 and 2 move lines: 1 picked unit and 90 unpicked unit: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L124-L143 Now, this would be fine if the second move line was not automatically picked as it would be ignored by the action done. However, since the move it self was not picked since subcontracted moves are never automatically recomputed as picked from their move lines: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L61-L63 the _pre_action_done_hook of the picking validation will pick the entire move and hence set the other move line as picked: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_picking.py#L1486-L1487 In particular both move lines will be validated and update the related stock quants.

### Fix:

Since in the case where there is no done move line we still find the outgoing partially reserved quantity that we are currently validating we should add the values of both **done** and **reserved** outgoing qties for the behavior on backorders to be the same as on the first picking validation.

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

Forward-Port-Of: odoo/odoo#213768

### Steps to reproduce:

- Install both mrp and quality_control
- Create 2 products:
    - FP (Final Product)
    - COMP (Component) tracked by SN > pu SN1 to SN4 in stock
- Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product.
- Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved
- Click on the wheel icon > Split production > Split in 2
- On the MO-001, SN1 is reserved
- Open the operation in the shopfloor and proceed with the quality check
#### > It is currently refering to SN2 !!
- register SN3
#### > It did not alter the value of the lot referred to on MO-001. It did update the serial number present on MO-002 from SN2 to SN3.

### Cause of the issue:

Confirming the MO will in turn confirm the workorder and create a quality check for the consumed material registration of SN: https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L625-L628 https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L415-L421 At this point, the create quality check is linked to the MO but also to the first move line (sml1) of the raw move (m1) refering to SN in that MO:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L495-L503 However, the `move_id`, `move_line_id` and `production_id` are all three stored non computed fields of the `quality.check` model. The issue will then be that when the production is split, MO will be renamed MO-001 the QC will still refer to MO-001, sm1, sml1 but sml1 will be reassigned to the raw move of the new production MO-002. In particular, while the QC is still accessed from MO-001 and still refer to the raw move sm1 of  MO-001, it actually updates the values MO-002 since performing these kind of quality checks actually updates the qty and lots on the move line it is related to:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/quality.py#L507-L508 Now, the reason why sml1 is reassigned to the mo to back order rather than staying on sm1 and hence on MO-001 is because the order of stock move line is altered to be reassigned by these lines during the `_split_production`:
https://github.com/odoo/odoo/blob/e4bd46930d1841fcd50bf426f5625e9495213ef7/addons/mrp/models/mrp_production.py#L1890-L1895 Currently, this order puts sml with an existing quality check after stock move lines without QC:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/quality_mrp/models/stock_move_line.py#L36-L41 As such, they will end up being assigned with the latest backorder to assign.

### Fix:

Since these kind of QC's are created at confirmation and since the first MO will not be reconfirmed, it is important that the QC created for MO-001 stays linked to that MO. In order to achieve this, move lines associated with a QC should definitely stay assigned to the first MO and the sml should therefore be ordered by these without QC last.

opw-4656240

Forward-Port-Of: odoo/enterprise#85163
Forward-Port-Of: odoo/enterprise#84606