2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- With a vendor
- Routes: Buy
4. Add a reordering rule to P:
- Min = Max = 0
5. Create and confirm a planned delivery order with 5 x P
6. Run the scheduler, it should create:
- An internal transfer IT (Input -> Stock) with one stock move SM
- A purchase order PO
7. Edit PO:
- 4 x P (instead of 5)
8. Confirm PO
9. List all transfers related to P
Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM
As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From | To | Dest |
|------|-----|---------|-------|------|
| SM01 | 5 | Input | Stock | / |
| SM02 | 5 | Vendors | Input | SM01 |
| SM03 | -1 | Vendors | Input | SM04 |
| SM04 | -1 | Input | Stock | / |
Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.
Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.
When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523
And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.
OPW-2861605
closesodoo/odoo#97599
X-original-commit: 43ca47cdfec696b847f716984f76df16de7b97b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Adrien Widart
136c5a1f95