Collective purchase orders are procurement documents for ordering goods from a vendor for a DC, and they are used in the Pull planning process of merchandise distribution. At DC level, you use a collective purchase order to bundle existing requirements of the DC recipients, which are stores or customers. Their requirements are recorded in the system as stock transport orders, or sales orders (PO/SO in the previous figure, Collective Purchase Order).
Remember: Planning for merchandise distribution is done centrally, either using an allocation table (push planning process) or a collective purchase order (pull planning method). Distribution data is updated during the planning phase using both methods. This data forms the link between procurement documents and issue documents from the DC’s point of view. The collective purchase order thus results from one or several issue documents (stock transport orders and sales orders) being assigned to this procurement document. The same is true for the vendor purchase order and stock transport orders/sales orders generated from an allocation table in the push planning process. In that case, too, the issue documents are assigned to the procurement document, the vendor purchase order.
In the pull planning process, when you create the collective purchase order, the system uses the article’s distribution profile in the Logistics: DC view for the relevant DC to decide about the processing method. In the push planning process, the allocation table item category is used to control merchandise distribution.
No matter if the push or pull planning approach was used, for merchandise distribution processing, the same processing methods are available: cross-docking, flow-through, and putaway, as well as the optimizing procedures cross-docking/flow-through, and cross-docking/putaway.
In contrast to Cross Docking, the Flow-Through merchandise is not pre-picked by the vendor. This means that in Flow-Through, picking at the DC is required. However, the usual putaway and picking process is avoided, as the merchandise is posted to a distribution zone (separate Flow-Through storage location in the DC), where picking happens right after goods receipt and adjustment, so that the merchandise can be moved on to goods issue in a timely manner. Two flow-through process variants are available. The difference is the picking document used: in recipient-driven flow-through, it’s the outbound delivery, in merchandise-driven flow-through, it is the distribution order.
Merchandise-driven flow-through requires the activation of *Lean-WM for the relevant storage location, as the distribution order (picking document) is technically a WM transfer order document. The outbound deliveries, which are then generated after picking was completed via the distribution orders, are of course not picking relevant. They are used as a reference document for goods issue posting, and for creating the delivery note.
Recipient-driven flow-through: At goods receipt in the DC, the merchandise is posted to a storage location for recipient-driven flow-through. The merchandise distribution data is adjusted, and the relevant outbound deliveries are generated for the recipients. Picking is then carried out for the outbound deliveries that have been generated. This means, for each recipient, one after the other, all ordered articles are picked. The picked merchandise is then sent to the outbound doors, and goods issue posted.
Merchandise-driven flow-through: At goods receipt in the DC, the merchandise is posted to a storage location for merchandise-driven flow-through. The merchandise distribution data is adjusted, and the articles are picked using distribution orders. The distribution order contains the quantities of each article that are to be picked for the individual recipients. This means, with merchandise-driven flow-through, one article after the other is distributed to the recipients.
Merchandise-driven flow-through requires Lean-WM, as the distribution order (picking document) is technically a WM transfer order document.
After picking, deliveries (not picking relevant) are generated, and goods issue is posted.