Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Supply Chain
The approved requisition that everyone forgot to turn into an order
A purchase requisition in IFS Cloud clears its approval and then goes quiet. The buyer meant to raise the order after one more check. The task slipped off a busy list. The person who owned it moved on. Nothing is wrong on screen: the requisition is approved, it looks finished. What did not happen is the one thing that mattered. No purchase order was raised, so the material was never ordered. Production or the customer finds out when the material is missing, and by then the lead time is already lost.
Key takeaways
- An approved requisition in IFS Cloud does not order anything by itself. Until it becomes a purchase order, the demand is recorded but the supply is not, and nothing on the requisition shows that the order was never raised.
- This is not slow approval. The approval already happened. The gap is the step after it: the approved requisition that no one converted into a purchase order.
- It is different from an unconfirmed purchase order. There an order exists and waits for the supplier to confirm. Here no order exists at all.
- It is the buy-side twin of a customer order that is entered but never confirmed: a record that looks handled while nothing downstream moves.
- The approval date is in IFS Cloud, so an approved requisition with no linked order is something a read-only monitor can list on day one, not discover at the next stockout.
1.How does an approved requisition end up with no order?
Approval and ordering are two separate steps owned by two separate moments. Approval says the spend is allowed. Raising the purchase order is the act that actually commits it to a supplier. The gap between the two steps gives a buyer room to choose the supplier, confirm a price, or wait for a better quote before committing. That gap is useful. It is also exactly where a requisition can fall through.
The reasons are ordinary. A buyer waits for a supplier to come back with a price and then the thread goes cold. A requisition is one of forty in a queue and the last few never get worked. A person leaves and their open items are never handed over. None of these looks like a failure in the moment. Each one just leaves an approved requisition sitting where a purchase order should be.
The requisition records the demand and the approval. An approved requisition that grows old without a matching order does not announce itself, so the demand simply waits, silent, for someone to notice.
2.Where in the buying process the requisition is stuck
All three sit near the start of the buying process and fail at different points, so the fix for each is different.
| Pattern | Where it is stuck | What is missing |
|---|---|---|
| Approval delay | Before approval | A decision. The requisition is waiting for someone to approve or reject it. |
| Approved, not ordered | After approval, before the order | The purchase order itself. Approval is done; nobody raised the order. |
| Unconfirmed order | After the order | The supplier's confirmation. The order exists but is not acknowledged. |
An approved but unordered requisition is the hardest of the three to see. An approval delay has an owner who is being chased. An unconfirmed order at least exists, so it shows up in order reports. The approved but unordered requisition shows up nowhere useful, because to the process it is finished. It cleared its gate. The evidence that nothing followed lives in the absence of a record, and absence is the hardest thing for a person to notice.
3.Catching it while the lead time is still there
Everything needed to spot this already sits in IFS Cloud and can be read through standard OData projections without touching a record. Detection watches for two things on a daily cycle:
- Approved requisitions with no linked purchase order - any requisition past approval that has no order raised against it, aged from the approval date, so the oldest and the highest value surface first.
- Requisitions aging past a threshold you set - not only the ones with no order at all, but those approved longer ago than the lead time allows, catching them while there is still time to order and receive before the need date.
This is the same discipline behind a manual purchase order check routine, done by a machine every morning instead of by a person when they remember. Because it is a read-only monitoring pattern, it runs beside purchasing and writes nothing back to IFS. It has 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 hands the buyer a short list of requisitions to act on, and the buyer decides whether to order, reassign, or cancel.
4.Rolling it out without noise
- Start with long-lead parts - watch the requisitions where a forgotten order hurts most, because the material takes weeks to arrive.
- Dry-run first - log what would have been flagged for a full window before a single alert reaches a buyer.
- Age from approval - measure the gap from the approval date, so the number reflects how long the order has been missing.
- Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.
Related reading
5.Frequently asked questions
Does an approved requisition order the material automatically?
No. Approval authorises the spend. A separate step raises the purchase order that commits it to a supplier. If that step never happens, the demand stays recorded while the supply is never ordered, and nothing on the requisition shows the order is missing.
How is this different from a requisition approval delay?
An approval delay is stuck before the decision, waiting for someone to approve it. This is stuck after the decision: approval is done, but no purchase order was ever raised. The requisition looks finished, which is why it is so easy to miss.
Is this the same as an unconfirmed purchase order?
No. An unconfirmed purchase order exists and is waiting for the supplier to acknowledge it. Here there is no purchase order at all, only an approved requisition with nothing raised against it.
Does detecting it require writing to IFS Cloud?
No. Requisition status, approval date, and any linked order are read through standard OData projections and compared 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.
See the orders that were approved but never raised
Tell me which parts carry the longest lead times. On a 30-minute fit call we check whether a rule listing approved requisitions with no purchase order behind them, aged from the approval date, 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 a buyer.
