[18.0][FIX] purchase_all_shipments: list only pickings of the reception chain

[les-adhoc]

Problem

all_picking_ids is computed by searching every picking that shares a procurement group with the order receipts:

groups = rec.mapped("picking_ids.group_id")
all_picking_ids = self.env["stock.picking"].search([("group_id", "in", groups.ids)])

The procurement group identifies the demand that originated the transfers, not the document that created them. It is therefore shared whenever a purchase exists because of a sale order, which is the case with:

• dropshipping, where the Vendors -> Customers buy rule propagates the group of the sale order;
• purchases generated from a sale order through a make to order route.

In those cases the group also holds the pickings of the originating document, so the All Pickings button of a purchase order lists customer deliveries and pickings of other purchase orders.

Two examples taken from a database where this happens:

• a purchase order whose only transfer is a dropship shows 2 pickings: its dropship and the pick of the sale order that generated it;
• a purchase order with 2 receipts and 2 storage transfers of a two-step reception shows 5 pickings, the fifth one being the pick of the originating sale order, for a different partner and still pending while the purchase is fully received.

The dropship case has been there for as long as the group is propagated by the buy rule. Since 93882d69, merged in 18.0 on 2026-07-30, stock_dropshipping also sets the group of the sale order on the receipts of any purchase order line linked to a sale order line, so regular warehouse receipts are now affected too. The field is a poor proxy for "the pickings of this purchase order", and upstream keeps making that more explicit.

Solution

Compute the field from the receipts of the order and the moves pushed by the reception route, so only the pickings of the reception chain are listed.

Walking the chained moves is what keeps the intermediate pickings of multi-step receptions, which is the purpose of the module. Restricting the walk to moves created by a push rule is what stops it where another document pulls the goods: a move pushed by the reception route continues the reception, while a move pulled by the demand of a sale order belongs to that sale order.

Filtering by operation type instead would not work, because the intermediate picking of a multi-step reception and the pick of an outgoing delivery are both internal transfers.

Tests

Added a test asserting that a picking of another document sharing the procurement group is not listed. The existing multi-step reception tests are unchanged and still pass.