Independent IFS Cloud practice · Sales
The delivery date you promised that the plan cannot keep
A promised date is a calculation dressed up as a commitment. At order entry the system offers a date, someone accepts it, and the customer hears a promise. Behind that promise sits an assumption about components, capacity, and timing. When the assumption holds, the promise holds. When the plan moves and the promise does not move with it, you have told a customer something the supply chain can no longer deliver, and you will find out when it is late.
Key takeaways
- Order promising gives a customer a date based on the availability of what the order needs. The date is only as trustworthy as the components and capacity it was calculated from.
- The failure is drift: the promise is made once, the plan keeps moving, and the two quietly diverge until the gap shows up as a late delivery.
- This is upstream of the metric problem. An on-time-delivery number tells you the promise was missed after the fact; watching the promise-to-plan gap tells you while you can still act.
- It is different from a sales order without coverage: coverage asks whether supply exists at all, promising asks whether it exists in time for the date you gave.
- For configured products the promise depends on the structure resolving first, which is why dynamic structures and MRP and order promising are two halves of the same order.
1.What a delivery date actually rests on
When a promise date is calculated, it reflects a picture of the world at that instant: what is on hand, what is on order, what capacity is free, and how long each step takes. Give the same order to the system a week later and the picture has changed. A supplier moved a date. A shared component was consumed by another order. A work centre filled up. None of that is unusual. It is what a live supply chain does.
The promise, though, was captured at a single moment and does not automatically re-plan itself as the world moves. It sits on the order as the number the customer was told. High fidelity means the promise and the plan stay close enough that the date is still real. Low fidelity means the promise is a fossil: accurate the day it was made, wrong ever since, and nobody looked.
2.Coverage asks if. Promising asks when.
These two questions get confused because both end in a worried planner. They are not the same check, and they fail in different ways.
| Question | What it checks | How it fails |
|---|---|---|
| Coverage | Does supply exist for what the order needs at all | An order with no supply behind it, covered in sales orders without coverage |
| Promising | Does that supply arrive in time for the date the customer was given | Supply exists, but later than the promise, so the date is quietly no longer achievable |
An order can pass coverage and still miss its promise. The parts are coming. They are just coming after the date you quoted. That is the gap this article is about, and it is the one that turns into a late delivery without anyone having made an obvious mistake.
3.Watching the promise against the plan
Promised dates on sales lines and the planned supply behind them are readable through standard OData projections, without touching a record. Detection is a matter of comparing the two on a daily cycle, so the drift is caught while there is still room to act:
- Promises now later than their supply - lines where the planned arrival of what the order needs has moved past the promised delivery date, so the date is no longer achievable on current supply.
- Promises that drifted since they were made - a date that was fine at entry but whose underlying supply has slipped points at a specific change worth chasing, rather than a vague worry about the whole order book.
- Promises resting on supply that itself is at risk - a date built on an order or component that is already flagged elsewhere inherits that risk, so it is worth surfacing before it becomes a surprise.
This is a read-only pattern. It runs beside IFS, writes nothing back, and does not re-quote the customer or move the promise for you. It surfaces the orders whose date and plan have come apart and lets a planner decide whether to expedite, re-plan, or call the customer early, which is a far better conversation than an apology after the fact.
4.Rolling it out without noise
- Start with your key accounts - watch the promises where a missed date costs the most in trust first.
- Dry-run before anyone acts - log which promises would have been flagged for a full window before a planner is asked to chase them.
- Flag the drift, not just the state - a promise that slipped since yesterday points at a recent change and is easier to trace than one drifting for weeks.
- Read-only by design - standard OData reads only, nothing written back to IFS and no new object installed in the client system.
5.Frequently asked questions
What makes an order promise high fidelity?
A promise is high fidelity when the date given to the customer still matches what the plan can actually deliver. It is calculated from the availability of the components and capacity the order needs, and it stays close to the plan as that plan changes. Fidelity is lost when the promise is made once and never reconciled against later movement.
How is this different from a sales order without coverage?
Coverage asks whether supply exists for the order at all. Promising asks whether that supply arrives in time for the date the customer was given. An order can have full coverage and still miss its promise, because the parts are coming later than the date quoted.
Why not just track on-time delivery?
On-time delivery tells you the promise was missed after the delivery has already happened or failed. Watching the promise-to-plan gap tells you while the order is still open and there is time to expedite, re-plan, or warn the customer. One is a scorecard; the other is a chance to act.
Does watching promises require writing to IFS Cloud?
No. Promised dates and the planned supply behind them are read through standard OData projections and compared outside IFS. Nothing is written back, so there is no new object inside the client system and the monitor cannot move a date or re-quote an order.
6.About the author
Dariusz Myśliwiec brings 18 years of hands-on work 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.
Catch the promise before it becomes an apology
Tell me which customers hold your tightest dates. On a 30-minute fit call I’ll show you how the SCM Automation Pack lists the orders whose promise and plan have drifted apart, with a dry-run week before anyone is asked to chase them.