Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Warehouse
Picked, staged, and still waiting at the dock
A picked delivery is off the shelf, sitting in a staging area, and committed to a customer order. The last step, the ship confirm, can still be missing: the truck leaves without it, or the paperwork stalls, and the delivery stays half done. On the system the stock is committed. On the dock it is going nowhere. The customer is waiting for goods that are packed and labelled, and no report calls the order late until the promised date passes.
Key takeaways
- A confirmed pick moves stock out of its shelf location, but the goods have not left until the shipment is dispatched. Picked and shipped are two steps, and the gap between them does not show on a stock balance.
- Depending on your setup, the committed quantity may be unavailable to planning while it sits in staging, in the same way as a stale reservation, yet it has not left the building.
- The delivery that has not shipped has not reached the point of being delivered but not invoiced, so the revenue is held one step earlier, before dispatch.
- The customer feels a late delivery, but the cause is the ship confirm. Production and supply delivered on time.
- The pick time and the delivery status are both recorded in IFS Cloud, so a read-only monitor can list how long a delivery has been picked and staged without being dispatched.
1.Why picked can still mean not gone
A confirmed pick records the warehouse work, and a ship confirm records the goods leaving. Confirming the pick is the moment the warehouse gets credit for the work, so it is the step that reliably happens. The ship confirm slips when a carrier is late, a document is missing, or a shift ends mid task.
Committed and shipped are two different states. Until the dispatch is confirmed, the goods are neither on the shelf for someone else nor in the customer’s hands. How the stock is treated while it waits in staging depends on your setup, and it is worth checking in your own configuration whether it still counts as available to planning.
The system holds the goods for the delivery exactly as it was told. It raises no question about why a delivery picked three days ago is still sitting in staging with no dispatch recorded against it.
2.Which picked deliveries have stalled
A delivery picked this morning and shipping this afternoon is normal flow. The monitor separates deliveries moving through a healthy process from ones that have stalled after the pick.
| What you see | What it can point to |
|---|---|
| A delivery picked and staged, aged past its window | A ship confirm that was never completed: committed on paper, undelivered in fact. |
| Reserved stock that a picker took but nobody shipped | Inventory committed to an order that is not moving, which a coverage check cannot see. |
| A staged delivery past its promised date | A late delivery whose root cause is dispatch, so chasing production would find nothing. |
| Staging areas filling with picked deliveries | A carrier or documentation bottleneck at dispatch, repeated across deliveries. |
The third row sends people to the wrong place. The delivery shows as late, so the reflex is to ask the plant why the goods were not ready, while they were picked and standing in staging while the ship confirm waited. A list across the whole dispatch area shows that stalled delivery as a pattern, which someone processing shipments one at a time cannot see.
3.Reading pick time and dispatch status, not just the balance
The pick confirmation time and the current delivery status are recorded in IFS Cloud and can be read through OData projections without touching a record (the exact projection is worth confirming in your environment). Detection watches deliveries that are picked and staged but not yet dispatched and looks at two things:
- Age since the pick - how long a delivery has been picked and staged past a window you set, so a stalled shipment is listed before the promised date passes.
- Staged stock against a due or late order - a picked but undispatched delivery on an order approaching or past its promised date, which turns a warehouse timing issue into a customer-service alert.
Because it is a read-only monitoring pattern, it runs beside shipping and writes nothing back to IFS. It adds no object inside the client system, so an R1 or R2 release leaves nothing of ours in your IFS to retest. Before each release I check that the standard projections it reads still match, as part of the subscription. It gives the dispatch lead a short list of deliveries to push out the door, and the decision on priority stays on the floor.
4.Rolling it out without noise
- Start with deliveries due soon - watch where a stalled dispatch turns into a late delivery first.
- Dry-run first - log what would have been flagged for a full window before a single alert reaches the dispatch lead.
- Two lenses - one for how long a delivery may sit picked and staged, one for staged stock against a due or late order.
- Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.
Related reading
5.Frequently asked questions
If a delivery is picked, why is it not shipped?
Picking and dispatch are different steps. The pick takes the stock out of its shelf location, and the ship confirm records the goods leaving. A late carrier, a missing document, or a shift ending mid task can leave a delivery picked and staged without a dispatch.
How is this different from delivered but not invoiced?
Delivered but not invoiced happens after dispatch: the goods have left and the invoice has not followed. A picked delivery that was never shipped sits one step earlier. The goods are still in staging, so no invoice is due yet, and the revenue is held before dispatch.
Why does a picked order show up as a late delivery when supply was fine?
The customer sees only the promised date pass. The goods were picked and ready, so production and supply were on time, and the delay sits in the dispatch step. Chasing the plant would find nothing, so separating a dispatch stall from a supply problem avoids the wrong investigation.
Does monitoring dispatch require writing to IFS Cloud?
No. The pick time and the delivery status are read through OData projections and analysed outside IFS. Nothing is written back, so there is no upgrade footprint and no new object inside the client system.
6.About the author
Dariusz Myśliwiec brings 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Get the picked orders out the door
Tell me where deliveries pile up in staging and which orders you cannot afford to ship late. On a 30-minute fit call we check whether a rule that reads pick times and delivery status fits your data. The SCM Automation Pack runs three rules today (unconfirmed purchase orders, late deliveries, stock below minimum), so this would be an additional rule built to order, with a dry-run week before anything reaches your dispatch lead.
