Picking, Packing, and Handling Unit Management in Outbound Deliveries

Explanation

Once an outbound delivery is created, it typically cannot post goods issue until picking (and, where configured, packing) is complete. In simple warehouse setups without a Warehouse Management system, picking is confirmed directly on the delivery by entering the picked quantity in the pick quantity field, which updates the delivery item's picking status. In more sophisticated setups integrated with classic Warehouse Management (WM) or with Extended Warehouse Management (EWM) in S/4HANA, the delivery instead triggers creation of a transfer order (WM) or a warehouse task (EWM) in the connected warehouse system. The delivery's picking status only turns green once that transfer order or warehouse task is confirmed back into the delivery, meaning picking is really a cross-system status synchronization problem, not a single-system field update. A very common advanced-level support issue is a delivery stuck in 'picking not confirmed' status even though the physical goods have left the warehouse, because the transfer order confirmation never posted back correctly, often due to storage type control issues, a locked transfer order, or an interface failure in a decentralized WM/EWM scenario.\n\nBatch determination frequently occurs during picking for materials that are batch-managed (e.g., by expiry date, production lot, or quality status). The delivery item can generate a batch split, creating multiple sub-items each pointing at a different batch, driven by the batch determination strategy assigned to the item category or the sold-to/material combination. Consultants must understand that a batch split changes the item structure of the delivery, which has downstream effects on picking confirmation (each sub-item needs its own confirmed pick quantity) and on billing (each batch line can appear separately on the invoice unless combined).\n\nPacking introduces handling units (HUs), which represent physical packages (cartons, pallets) with their own unique identifier, often an SSCC barcode. Packing can happen at the delivery level using the packing screen, or upstream in EWM as part of the warehouse task confirmation. A delivery can be HU-managed (all picked quantity must be packed into HUs before goods issue is allowed) or non-HU-managed depending on configuration at the shipping point/warehouse level. Nested HUs (cartons packed onto a pallet HU) are common in outbound logistics for parcel carriers and retail distribution, and packing instructions can be automated using packing proposal logic tied to packaging material master data. A frequent production issue is 'delivery blocked for goods issue - packing incomplete' even when items are physically packed, usually because the HU was created but not properly assigned/confirmed against the delivery item, or because partial quantities remain unpacked due to a picking discrepancy.\n\nSerial numbers add another layer: for serial-managed materials, the delivery may require serial number entry during picking or packing, validated against the serial number profile on the material master, and unconfirmed serials will also block goods issue. In S/4HANA with embedded/decentralized EWM, much of this picking, packing, and serial capture happens on RF (radio frequency) devices or Fiori warehouse apps, with the ERP delivery document reflecting only the final synchronized status rather than the transactional detail, which changes how support teams diagnose issues: they must look in the warehouse system's task/HU tables, not just the ERP delivery, to find the root cause.

Code example

* Illustrative logic for goods issue eligibility checks (conceptual, not actual code)\n\nIF delivery_item-picking_status <> 'C'.       \"C = Completed\n  RAISE gi_blocked_picking_incomplete.\nENDIF.\n\nIF delivery-hu_managed = 'X' AND delivery_item-packing_status <> 'C'.\n  RAISE gi_blocked_packing_incomplete.\nENDIF.\n\nIF material-serial_profile IS NOT INITIAL\n   AND delivery_item-serials_confirmed_qty <> delivery_item-picked_qty.\n  RAISE gi_blocked_serials_missing.\nENDIF.\n\n* Batch split conceptual check\nLOOP AT delivery_item-batch_split_lines INTO batch_line.\n  IF batch_line-picked_qty <> batch_line-planned_qty.\n    RAISE gi_blocked_batch_split_incomplete.\n  ENDIF.\nENDLOOP.

Real project scenario

A consumer goods client using decentralized EWM reported dozens of deliveries stuck in 'picking incomplete' status every morning even though night-shift pickers confirmed all warehouse tasks. Root cause analysis showed an intermittent idoc/queue delay in the confirmation interface between EWM and the ERP delivery, meaning physical picking was done but the status update had not synchronized yet. The team implemented a monitoring job to flag deliveries where warehouse task confirmation timestamps were older than a defined threshold but ERP status was still open, allowing early detection of interface delays before they affected the goods issue and billing schedule.

Common mistakes

• Treating delivery picking status as a single-system field when WM/EWM integration is in place, ignoring the confirmation sync step\n• Forgetting that a batch split creates multiple sub-items each requiring individual pick confirmation\n• Assuming packing completion is automatic once picking is done, when HU-managed shipping points require explicit packing confirmation\n• Not validating serial number profile requirements before goods issue, leading to last-minute GI blocks\n• Diagnosing goods-issue blocks purely in the ERP delivery without checking the connected warehouse system's task or HU status\n• Overlooking that nested handling units must be fully confirmed at every packing level before the top-level HU is considered complete

Best practices

• Build monitoring for stale picking/packing statuses when integrated with decentralized WM or EWM to catch interface delays early\n• Educate warehouse and customer service teams on how batch splits change delivery item structure and picking confirmation requirements\n• Confirm HU-managed configuration at the shipping point level before assuming packing is optional for a given delivery\n• Validate serial number profile requirements against expected order volume to avoid last-minute goods issue blocks\n• Use delivery item status fields (picking, packing, GI) together as a checklist rather than relying on a single overall status\n• When troubleshooting, always check the connected warehouse system's task/HU records, not just the ERP delivery document

Interview angle

Advanced interview questions in this area typically test whether a candidate understands that picking and packing status on the ERP delivery is often a reflection of an external warehouse system's confirmation, not a standalone field, and whether the candidate can describe a realistic diagnostic path (check transfer order/warehouse task status, check HU assignment, check batch split completeness) rather than jumping straight to 'reset the status field,' which is a red flag in production support contexts.