Independent IFS Cloud practice · Supply Chain
Three order states that should never sit unquestioned. One of them, nobody owns.
Key takeaways
- Released without confirmation, arrived without receipt, and partly received for more than a week look identical on a summary report. The order exists, the line is there, nothing is red.
- None of the three is a system error. IFS Cloud recorded each state correctly; the failure is that nobody was asked to look.
- The first two already have dedicated fixes on this site. The third, a partial receipt stuck mid-transaction, is the one most practices have never assigned an owner.
- The same mechanism closes all three: a Custom Event that asks one named person one specific question after a set number of days.
Released without confirmation. Arrived without receipt. Partly received for more than a week. Pull up a summary report and none of these look like a problem. The purchase order exists. The line is there. The status field is a reasonable colour. But each of these three states shares the same property: it is a decision nobody has made yet, and every day it sits unmade, the eventual cost of making it goes up. Released without confirmation means you are scheduling production around a supplier promise you have not actually received. Arrived without receipt means goods are sitting on your dock while the system insists they do not exist yet. Partly received for a week means somebody started closing out a delivery, got pulled onto something louder, and never came back to finish it. Two of these three already have a dedicated fix on this site: unconfirmed orders and goods received without an invoice. This article treats all three as one pattern, and gives the third, the stuck partial receipt, the attention it has not had yet.
1.Why do these states pile up unquestioned?
None of the three states is a system error. IFS Cloud recorded exactly what happened: an order was released, a receipt was partially posted, a delivery arrived. The record is correct. What is missing is a second step nobody assigned to anyone. Somebody was supposed to come back and check whether the state was still expected, and nobody did. Confirmation is treated as the supplier’s job. Receipt posting is treated as finished the moment the first click happens. Ownership stops exactly at the point where the interesting question begins.
The three states also share a trigger for how they start: an interruption. A buyer moves on to the next order before confirmation clears the inbox. A warehouse operator gets called away mid-receipt with a partial quantity already keyed in. A goods-in team scans a delivery against a PO that nobody has flagged as arrived. None of these interruptions is a mistake by itself. The mistake is a workflow with no mechanism to reopen the question later. Once the interruption happens, the state looks stable. It can sit exactly where it was left for weeks.
2.What does an unquestioned state actually cost?
The three states convert into cost differently, but the shape is the same: a small unmade decision compounds quietly until it becomes expensive to fix, then surfaces as a line item that never mentions its own cause.
- Production planned on a promise. A release awaiting confirmation is treated as reliable in the plan; if it slips, the plan slips with it, discovered only when the line stops.
- Inventory the system cannot see. Goods on the dock without a posted receipt do not exist for planning, so the system happily reorders stock that is already sitting fifty metres away.
- A remainder stuck mid-transaction. A partial receipt left open for a week blocks the invoice match and confuses anyone checking coverage, and nobody remembers why it is still open.
- A cost with no name on it. None of this ever appears on a P&L as “unconfirmed PO” or “stuck partial receipt”. It shows up as expediting, as a duplicate order, as a finance query nobody can answer quickly.
Three different states, the same failure mode: the record is technically correct and operationally wrong.
3.How do you see them in IFS Cloud?
All three states are visible with a filter you can build today, because IFS Cloud already tracks the fields that matter: order status, confirmation date, receipt date, and received quantity against ordered quantity. Released orders past a threshold with no confirmation, and goods receipts posted without a matching invoice past a threshold, are both covered start to finish in the dedicated articles on unconfirmed purchase orders and goods received without an invoice.
The partial receipt case deserves its own explanation, because it hides differently. A purchase order line with received quantity greater than zero and less than ordered quantity, where the last receipt posted more than, say, five working days ago, is your working definition of stuck. It will not appear on an exceptions view built around “open” versus “closed”, because a partially received line is neither. It is technically still open, technically has activity against it, and technically nobody’s job to close. Filtering purchase order lines on that exact combination (received quantity between zero and ordered quantity, last receipt date older than the threshold) is the query most practices have simply never written.
4.Manual re-check versus systematic routing
Whichever of the three states you tackle first, the comparison is the same. A manual re-check depends on someone remembering to reopen a record that already looks finished. A systematic rule watches the field combination continuously and routes the exception to a named owner without anyone asking.
| Manual re-check | Systematic routing | |
|---|---|---|
| Runs when | Someone happens to reopen the order | Continuously, on a schedule |
| Coverage | Whichever state someone remembers | All three states, every order, every site |
| Owner | Unclear across all three | Named per state, by rule |
| Audit trail | None | Logged flag or alert per order |
| Fails when | Busy weeks, handovers, headcount changes | Never sleeps |
The comparison holds because the underlying pattern is identical in every case: a record that is technically active but has had no human attention past a reasonable age. Once you have built the rule for one state, extending it to the next two is configuration, not a new project.
5.How do you roll this out safely?
Treat this as three related automations built the same way, not one big project. Start with the state that has the least existing coverage.
- Pick a starting state. If unconfirmed orders and GRNI already have escalations running, start with partial receipts. It is the one most practices have never assigned to anyone.
- Define “stuck”. Agree the day count and the exact field combination (received quantity, order quantity, last receipt date) that marks a line as needing a decision.
- Run in dry-run. Log what would fire for two weeks before a single alert reaches anyone. The list itself is usually the first surprise.
- Assign a named owner. A flag with no recipient is just another report; route it to the person who can actually close the line.
- Extend to the other two states. Once one automation is trusted, the same Custom Event pattern applies to the other two. Reuse the mechanism, not just the idea.
This is built inside the IFS Extensibility Framework, using standard Custom Events, Workflows and PL/SQL. None of it touches the core, so it survives the next upgrade instead of becoming part of the upgrade tax.
6.Frequently asked questions
What do these three order states have in common?
Each one is recorded correctly by IFS Cloud, and each one still needs a human decision that nobody has been asked to make. None trips an error; all three simply sit, looking normal, until the cost of the eventual decision has grown.
Why treat a partly received order as an exception if the PO is technically still open?
Because “still open” is exactly the state a real exceptions view misses. It is neither closed nor obviously wrong, so it never surfaces on a report built around pass or fail, and it can sit for weeks with nobody noticing.
Do I need three separate automations to fix this?
You need three separate rules, but one mechanism. Each state gets its own Custom Event and threshold; all three reuse the same trigger-and-action pattern, so building the second and third is far faster than the first.
Is this update-safe?
Yes. Every rule described here is a standard Custom Event, Workflow or PL/SQL routine inside the IFS Extensibility Framework. Nothing modifies the core, so nothing here is at risk from the next R1/R2 release.
7.About the author
Dariusz Myśliwiec has spent 25+ years in ERP and supply chain, 17+ of them on IFS (Apps 7.5-10 and IFS Cloud). He is an IFS Certified Associate Consultant and PRINCE2® 7 certified. His practice is based in Krakow and works remotely across Europe and beyond. You talk to the consultant who builds it, not a sales layer.
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.
Stop letting the quiet states go unquestioned
If you suspect these three states are costing you and cannot yet prove it, a two-week dry-run across all three will show you the real numbers. On a 30-minute call I’ll map thresholds and owners to your process: fixed price, dry-run before anything sends.
