**Problem:**
Exiting a barcode picking will assign the remaining quantity, which 
can be problematic in the case of a product tracked by serial number
because if the client scans another serial number, at validation a backorder
is created.

**Steps to reproduce:**
- Create a product tracked by serial number
- create 4 quants (S1,S2,S3,S4) in stock
- create a delivery of this product for a quantity of 3
- make sure the source location is stock
- save but do not mark as todo
- open it in barcode
- scan s1 scan s2
- exit and come back to the picking in barcode
- notice how a a new line with "0 / 1" has been added
- scan s4 and validate

**Current behavior:**
A back order is created

**Cause of the issue:**
When we exit the operation on barcode, the post_barcode_process method is called.
This method calls split_uncompleted_move
https://github.com/odoo/enterprise/blob/1764381e3b3d4d78286a80b9ec32e2f68a946a86/stock_barcode/models/stock_move.py#L65
Which creates and confirm a new move (and thus a new 
move line) with the remaining quantity (here 1).
https://github.com/odoo/enterprise/blob/1764381e3b3d4d78286a80b9ec32e2f68a946a86/stock_barcode/models/stock_move.py#L37 
Then post_barcode_process calls truncate_overreserved_moves 
on self but because the quantity difference was added on an other 
move the method does nothing.

**fix**
The fix is essentially a backport of https://github.com/odoo/enterprise/pull/89967
In v18 the bug does not happen because at the end
of split_uncompleted_moves, the new move is merged with the existing one (since the linked PR).
https://github.com/odoo/enterprise/blob/b3a80334f375b8dc66d73cb13599d81b48470218/stock_barcode/models/stock_move.py#L37 
This allows truncate_overreserved_moves to decrease the 
quantity on the move and remove the extra move line.

opw-5172820

#### Issue:
- Some replenishment lines appear several times in MO Overview

#### Step to reproduce:
- Create a product B
- Activate Manufacture in the Inventory tab
- Add a BoM to B
- Add a reordering rule (min qty: 0, max qty: 0)
- Create a product A
- Activate Manufacture
- Add a BoM to A which consume 1 unit of B
- Create a MO for 6 units of A
- Confirm it
- It should have created a MO for 6 units of B
- Confirm the MO for B.
- Produce all
- Go to the MO for A
- Set the quantity to 1 (out of 6)
- Click on the Scrap Button
- Scrap 2 units of B and replenish quantities.
- Click on the overview Button

#### Current behavior:
- Several lines appear for the MO to replenish quantities. (2 lines if state in 'draft', 3 line if state in 'confirmed')

#### Expected behavior:
- one line appear for the MO to replenish quantities.

#### Cause of the issue:
[In `_get_replenishments_from_forecast()`](https://github.com/odoo/odoo/blob/17.0/addons/mrp/report/mrp_report_mo_overview.py#L693-L694) we call `self.env['stock.forecasted_product_product']._get_report_lines()` which creates line for confirmed move (but neither done, nor draft move). Then in `_add_origins_to_forecast()` it tries to link a `document_in` to the previous lines using `line['move_out']._rollup_move_origs()`.

There is 2 issues:
- the `document_in` of a line created through `_get_report_lines()` was being displayed a second time if used to reconcile the `document_in` of another line.
- a "document" used as `document_in` can be used for multiple lines regardless of its distribution in previous lines.

#### Solution:
- prevent lines from being displayed a second time
- add a system to remember the already distributed quantity of document_in among lines

opw-4882391

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