[FIX] stock: in forecast report, associate MTO lines only with their source

Behavior prior to this commit:

If I have a pre-existing order (confirmed, but without available
product) on a product with an MTO route, and I now place a new order on
that product then confirm the generated PO, in the forecast report the
quantities from the PO will be shown as being applied to the
pre-existing order first.

For example:
 - create a product with an MTO route (set a vendor)
 - create a SO (SO1) for 5 units of that product and confirm it.  Verify that
 a PO (PO1) was generated.  Cancel the PO.
 - create a new SO (SO2) for 10 units of the product and confirm it.  Confirm
 the PO (PO2) that is generated.
 - run the forecast report.  It should show:

| Replenishment | Quantity | Used By |
|------------------------------------|
|   PO          |   10     | SO2     |
| Not available |   -5     | SO1     |

But instead it shows:

| Replenishment | Quantity | Used By |
|------------------------------------|
|   PO          |    5     | SO1     |
|   PO          |    5     | SO2     |
| Not available |   -5     | SO2     |

When the product is received for PO, the quantity received is correctly
applied to SO2, not SO1.

Behavior after this commit:

 - when generating the forecast report, we have to tie each outgoing
 shipment with 0 or more incoming shipment.  After this commit, the
 computation will be made without considering candidate incoming
 shipments that are linked (via `move_dest_ids`) to a different
 outgoing shipment.
 - for receipts that are not tied to another move (move_dest_ids is
 empty), there is no change of behavior
 - for receipts that are "over-delivering", for example if there was a
 generated PO for 10 units but they manually increased it to 15 to cover
 both SO, there is no change of behavior: it will still show as
 replenishing both SO.

Note:

 - in a multi step environment the report does not correctly allocate
 quantities once some steps of the order are processed (the quantity
 will be shown as coming from stock, but in fact not all steps have been
 processed), this is accepted as a known limitation to prevent making
 too much of a performance hit for the MTO case (this behavior is the
 same as what was present before the commit)

opw-2412137

closes odoo/odoo#63179

Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>

0 files changed, 0 insertions, 0 deletions