Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Warehouse
Planned moves that nobody executed leave pick faces empty
Where your setup uses transport tasks, IFS Cloud creates one when stock needs to move: a putaway after receipt, a replenishment to a pick face, a relocation between areas. The task names a from-location and a to-location and waits for someone to execute it. When it is never executed, the stock stays where it started while the plan behind it assumes the move is done. A picker sent to the destination finds an empty slot, even though the goods exist a few aisles away. The open task and its age are recorded in IFS Cloud, and it is worth checking in your setup whether anything raises the ones that have waited too long.
Key takeaways
- A transport task is a planned move between two locations. Until it is executed, the stock is physically at the source, not at the destination the next process expects.
- An open replenishment task can leave a pick face empty while orders wait on it, so a shortage appears at the destination while the same part sits at the source.
- Stock received but not put away is the first move after arrival. A transport task covers any internal move, including replenishment that runs long after receipt.
- Stock in transit between sites has left the building. Here the stock stayed inside it, and the move is a shelf-to-shelf task nobody closed.
- The open task, its from-location and to-location, and its age are recorded in IFS Cloud, so a read-only monitor can list the moves that were planned but never done, writing nothing back.
1.A transport task records a planned move, and only execution moves the stock
A transport task in IFS Cloud represents a required move of stock from one location to another. The warehouse creates it for a putaway after a receipt, for a replenishment that tops up a pick location, or for an internal relocation. The task records where the stock is and where it should go, and it stays open until an operator executes it and confirms the move.
Until that confirmation, the stock is still at the source location. A replenishment task that says a pick face should be topped up puts nothing on that pick face by existing. Only the execution does.
The risk is a task that is created and then left. The stock is in the system, because it exists somewhere in the warehouse, and it is not where the next process is going to look for it. The open task holds that information, but only someone reading the open tasks will see it.
2.Which open tasks need attention
A task created a minute ago and waiting for the next operator is normal. A replenishment task that has been open for a shift, feeding a pick face with orders queued against it, is a shortage in the making. The difference is age and whether demand is waiting at the destination, and both are measurable.
| What you see | What it can point to |
|---|---|
| Replenishment task open, orders queued on the destination pick face | The highest risk. Picking will come up short against stock that exists in the warehouse but was never moved to where the pick expects it. |
| Putaway task open long after the receipt | Stock held at a receiving or staging location, where normal picking may not reach it until the move happens. |
| Task open against a location now being counted or blocked | The move cannot complete cleanly, and the stock is held between a source it cannot leave and a destination it never reached. |
| A specific area or shift where tasks stay open repeatedly | A process gap in that area, where creating tasks and executing them have drifted apart. |
The first row is where the disruption is. The part is in stock, the order cannot be picked, and nobody has connected the two. An operator working the task queue one entry at a time cannot see which open tasks are now blocking live demand. A list of the open tasks set against the demand at their destinations puts the urgent few at the top.
3.Finding the moves that were planned but never done
The transport task, its state, its from-location and to-location, and the time it was created can be read through OData projections without touching a record (the exact projection is worth confirming in your environment). Detection looks at two things:
- Open beyond a sensible window - tasks that have not been executed within the time a move of that kind should take, so the ones that have stalled appear as a list instead of sitting in the queue.
- Destination has demand waiting - open replenishment or relocation tasks whose to-location has orders or reservations queued against it, so a move that is now blocking a pick ranks above one with no one waiting.
Because it is a read-only monitoring pattern, it runs beside the warehouse 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. Executing the move stays with the warehouse operator. The monitor tells the supervisor which tasks are stalling picks before the order is short. It sits alongside the check for stock picked but not shipped, which reads the same location and order data.
4.Rolling it out without noise
- Start with replenishment tasks feeding live picks - the moves that top up pick faces with orders waiting are where a stalled task hurts first, so watch those before the rest.
- Dry-run first - log which tasks would have been flagged across a full period before a single alert reaches a supervisor.
- Tune the waiting window per task type - a putaway and a cross-warehouse relocation take different times, so set the threshold that fits each kind of move.
- Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.
Related reading
5.Frequently asked questions
What is a transport task in IFS Cloud?
A transport task is a planned move of stock from one warehouse location to another, created for a putaway after receipt, a replenishment to a pick face, or an internal relocation. It records the from-location and the to-location and stays open until an operator executes and confirms the move. Until it is executed, the stock remains at the source location, not at the destination the next process expects.
Why is an order short when the stock is in the warehouse?
Picking looks for stock at the location the pick expects, which can be a pick face fed by replenishment. If a replenishment transport task was created but never executed, the pick face is empty while the same part sits at the source location the task was meant to move it from. The stock exists in the warehouse and is in the wrong place for the pick, so the order is short.
How is an open transport task different from stock received but not put away?
Received but not put away is the first move after a receipt, from the receiving area into storage. A transport task can be any internal move, including a replenishment or a relocation that happens long after receipt. Both leave stock in a place the next process does not expect, and a transport task covers moves throughout the warehouse, beyond the arrival step.
Does monitoring open transport tasks write anything to IFS Cloud?
No. The task state, the from-location and to-location, and the creation time are read through OData projections and evaluated outside IFS. Nothing is written back, so there is no upgrade footprint and no new object inside the client system. Executing the move stays a warehouse decision.
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.
Know which planned moves never happened
Tell me where a stalled move hurts your picking most. On a 30-minute fit call we check whether a rule that reads open transport tasks and the demand at their destinations 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, read-only, with a dry-run period before anything reaches a supervisor.
