Select your language
Select your language
Independent IFS Cloud practice · Sales
A customer price list or agreement is not permanent. It has a date it stops being valid. That date is set once, months ahead, and then everyone forgets it, because the price keeps working right up until it does not. On the day after, new order lines no longer price from it. They fall back to a base price, to another list, or to nothing you expected. Sales keeps quoting the old terms. The system quietly stops honouring them. Nobody set out to change a price, and yet the price changed.
Key takeaways
Pricing in IFS Cloud is not a single number on a part. It is a set of price lists and customer agreements, each valid for a period, each with a date it starts and a date it ends. The valid-to date is a switch. On one side of it, an order line prices from the agreement. On the other side, that agreement no longer applies and the line prices from whatever is next in the order of precedence.
The trouble is that the switch flips by the calendar, not by an action anyone takes. There is no click, no approval, no message. The agreement that was correct on Friday is simply not selected on Monday, and the order picks a different price without comment. The record still exists. It has just aged out of the window where it counts.
That makes it different from the pricing failures you already watch. A line with no price is loud, because the order cannot proceed cleanly. An expired agreement is quiet, because the order prices fine, at a number nobody chose. It can even slip a line below cost if the fallback price is lower than the deal you meant to honour.
No one plans to let an agreement lapse mid-relationship. It happens at the seams of ordinary account management, in three recurring ways.
| Origin | What happens | Why it survives |
|---|---|---|
| Renewal not done in time | The agreement reaches its valid-to date before the new one is entered | The old terms worked yesterday, so nobody notices the gap until an order prices differently |
| Short-dated promotion | A temporary price is set to expire on purpose, and the follow-up plan never lands | The expiry was intended, but the decision about what replaces it was not made |
| Overlapping lists | Several price lists apply, and the one that expires was the one actually being used | Another list still prices the line, so the order looks priced and the drop goes unseen |
In each case the order still prices, which is exactly why the problem is invisible. The gap surfaces later as a margin that came in wrong, a customer disputing an invoice against the terms they were promised, or a sales manager asking why an account is suddenly on list price. By then the orders are placed and the credits are the cleanup.
Price list and agreement validity dates are available through standard OData projections, readable without touching a record. Detection is a matter of looking forward at the dates rather than backward at the damage:
Because this is a read-only monitoring pattern, it runs beside sales and writes nothing back to IFS. It does not extend the agreement, change a date, or reprice an order, and it should not: what a price should be is a commercial decision. It hands the account owner the list of agreements about to lapse, so the renewal is a scheduled task instead of an apology after the fact.
The problem is that the price is no longer the one that was agreed. When an agreement expires, the line prices from the next source in precedence, which might be a base price, another list, or list price. The order looks priced and moves ahead, but the number can be higher or lower than the deal the customer expects, which shows up later as a margin miss or a dispute.
An off-agreement price is a line that did not use the agreement it should have, while the agreement is still valid. This is one step earlier: the agreement itself has passed its valid-to date, so it is no longer available to any line. One is a line that missed a live agreement; this is an agreement that is no longer live.
No. What a price should be, and for how long, is a commercial decision that belongs with the account owner. The monitor reads validity dates through OData and lists what is about to expire or has already lapsed, then leaves the renewal to a person. Nothing is written back to IFS.
Yes, by pairing the expiry with recent order activity. An agreement lapsing on a customer who orders every week is urgent, while one on a dormant account can wait. Ranking expiries by how active the account is keeps the list short and focused on the agreements that are about to misprice real orders.
Dariusz Myśliwiec brings 25+ years in ERP and supply chain, 17+ of them 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.
Tell me how your team manages customer price lists and agreements. On a 30-minute fit call I’ll show you how the SCM Automation Pack lists every agreement expiring in your chosen window, ranked by which accounts are still ordering, with a dry-run week so the renewals are planned before an order prices from the wrong source.
Independent IFS Cloud practice · Upgrades & Extensibility
Key takeaways
A custom PL/SQL package built five years ago checks order states every morning and emails purchasing when something needs attention. It survives two IFS Cloud upgrades without a single change. On the third, an upgrade alters a view the package quietly depends on. The package does not throw an error. It runs on schedule, queries successfully, and returns zero rows. For six months, nobody notices, because zero rows looks exactly like a quiet month in purchasing, and a quiet month is not a support ticket. This is the failure mode that testing plans built around “does it still run” miss completely, and it is a more common story on real IFS Cloud estates than most upgrade retrospectives admit.
Most regression testing after an upgrade asks one question: does the custom code still execute without throwing an error? That question has an honest, comfortable answer almost every time, because IFS Cloud upgrades are designed to be graceful. A renamed column, a restructured view, or a changed join rarely crashes a package outright. It just changes what the query returns, and a query that used to match forty rows a day can start matching zero without any exception being raised at all.
The people who could catch it are not looking for it, because there is nothing prompting them to look. An upgrade project tracks the things that visibly break: failed jobs, error logs, user complaints. A rule that goes quiet produces none of those. It produces the absence of a thing that was never guaranteed in the first place, and absence is the hardest failure mode to schedule a test for.
The cost is not the broken package. It is everything the package was put there to prevent, arriving unannounced during the exact months it was quietly offline.
Custom code that fails loudly is a nuisance you fix in an afternoon. Custom code that fails quietly is a risk you carry into every release without knowing it.
The fix is not more error handling inside the check itself. The check was never throwing an error to begin with. The fix is watching the check from the outside: a heartbeat that compares how many rows a rule returned this run against its own recent history, and flags a rule that has gone quiet the same way it would flag one that suddenly went noisy.
A rule that has averaged five to ten hits a week for a year and then returns zero for three consecutive runs is worth a look, regardless of whether “zero is plausible” on its face. This is the same logic used to keep upgrade readiness checks honest: verifying a control still behaves the way it always has, not just that it still exists in the codebase.
Both are useful. Only one of them would have caught the six-month gap.
| Runs without error | Verified live (heartbeat) | |
|---|---|---|
| What it confirms | The package executes and completes | The package’s output still matches expected behaviour |
| Catches a broken dependency | Only if it throws an exception | Yes, even if the query still runs cleanly |
| Catches zero-row drift | No | Yes |
| When it is checked | Once, at upgrade testing | Continuously, every run |
| Effort to maintain | None after go-live | Light: one baseline comparison per rule |
Upgrade testing that stops at “it still runs” is necessary and not sufficient. The heartbeat is what turns a one-time test into an ongoing guarantee that survives the upgrade after the one everyone tested for.
The heartbeat should be quieter than the rule it is watching, not louder.
Built as standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, both the original rule and its heartbeat stay update-safe and avoid the upgrade tax. That is the same discipline that keeps Custom Events maintainable release after release.
Most regression testing confirms a package still executes without an error. It rarely confirms the package’s output still matches its historical pattern, which is exactly the gap a zero-row failure exploits.
Any scheduled custom check whose failure mode is silence rather than an error is a candidate: typically anything built as a PL/SQL job or Custom Event that queries and emails without a human reviewing the query result itself.
Only if it is tuned poorly. Routed to IT rather than to the business audience, and fired only on a genuine deviation from baseline, a heartbeat alert should be rare enough to always be worth opening.
Yes. Both the original rule and the heartbeat that watches it are built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework. There is no core modification, so there is nothing here for the next R1/R2 release to quietly break.
Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. 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.
A short audit of your scheduled custom checks against their own history will show you, in a day, whether any of them have been silently returning zero since your last upgrade. Fixed price, no changes go live without a review.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A report tells you twelve purchase orders are unconfirmed. A decision tells you which three need a phone call today. Most supply chain reporting confuses the two. It delivers volume — forty pages, eighty line items, a dashboard with six charts — and the recipient scans it, notes that nothing is obviously on fire, and moves on. The value was never in the forty pages. It was in the three lines that needed action. But those three lines were buried among thirty-seven that did not, and the person who could have acted on them never saw them at all. Good exception handling does not report. It routes. It puts the right three lines in front of the right person at the right time, and it does not ask them to hunt. This article looks at why reporting defaults to volume, what interpreting a report actually costs, and how to route exceptions in IFS Cloud instead of reporting them.
Reports are easy to build comprehensively and hard to build selectively. Comprehensiveness is a query: pull every open order, every line, every field. Selectivity requires someone to decide, in advance, which combination of conditions actually matters — and that decision feels like a risk, because leaving something out looks like a mistake later, while leaving everything in never does. So the safe choice, repeated across every dashboard and every export, is to include everything and let the human sort it out.
The human, of course, is usually the same person the report was meant to save time for. They open it between two other tasks, scroll for a pattern, and either catch the three lines that matter through sheer familiarity with the data, or miss them because today was a busy day. The report did its job — it reported. Nobody decided anything, because nobody was asked a specific question.
Handing someone a report instead of a decision does not save work. It moves the work, unpaid and unscheduled, onto whoever opens the report next.
A report that requires interpretation is a task you have given to someone who did not ask for it.
The test is simple: does the output name a person and a next action, or does it name a data set? A Quick Report that lists every open purchase order is a data set — useful, but still a report. A rule that filters that same data set to the handful of orders past a defined threshold, and sends only those to the buyer responsible, is a decision arriving pre-qualified. The mechanics of both are covered in Quick Reports, Custom Fields and Custom Events compared, and the trigger-and-action pattern behind routing specifically is the backbone of the SCM automations for IFS Cloud.
Most instances already have the report. What is usually missing is the second step: a Custom Event that reads the same underlying data, applies the threshold that defines “matters today”, and sends the result to one named recipient instead of publishing it for everyone to interpret.
The two are built from the same data. The difference is entirely in what happens between the data and the person who has to act on it.
| Reporting | Routing | |
|---|---|---|
| Output | Every row that matches the query | Only the rows past the threshold |
| Recipient | A distribution list | The named person who can act |
| Interpretation needed | Yes, every time it is opened | None — the filter already did it |
| Timing | Fixed schedule, regardless of urgency | As soon as the threshold is crossed |
| Fails when | The reader is busy or fatigued | Never sleeps |
Keeping the report is often still worth it — it is the audit trail and the occasional deep dive. Routing does not replace it; it removes the requirement that a human read the whole thing to find the part that matters.
Start from a report you already trust, not from a blank page.
The routing layer is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — so it sits alongside your existing reports without modifying them or the core, and survives the next upgrade untouched.
A report lists everything that matches a query and leaves interpretation to whoever reads it. Routing applies the interpretation in advance — a threshold, a filter, a named recipient — so what arrives is already a decision, not a data set to search through.
No. Reports remain valuable as an audit trail and for the occasional deep dive. The change is to stop relying on a report as the primary mechanism for surfacing something urgent, and to route the urgent cases separately.
Watch what an experienced person actually flags from the full report over a few cycles, then turn that pattern into an explicit threshold. The dry-run period exists precisely to test that the filter matches what a human would have chosen.
Yes. Routing is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, sitting alongside existing reports rather than modifying the core — nothing here is at risk from the next R1/R2 release.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally — 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.
Pick the report your team dreads opening and I will show you, on a dry-run, what routing it would actually send — and to whom. On a 30-minute call we will map the first threshold together — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Procurement
Key takeaways
She knows every supplier by name. She can tell you which orders need chasing without opening IFS. She has done this for eight years, and she is the reason nothing falls through the cracks on her desk. She is also the reason everything could. If she won a competitor’s offer tomorrow, her replacement would inherit a supplier list and a login — not the eight years of pattern recognition that made her effective. This is not a story about one buyer being irreplaceable. It is a property of any role where expertise lives in a person instead of a process: the organisation only feels safe because nobody has priced what leaves with her. This article looks at why that concentration builds up unnoticed, what it costs the day it is tested, and how to move the judgment — not just the task — into something IFS Cloud can carry.
Nobody sits down and decides to make the procurement function dependent on a single buyer. It happens one competent decision at a time. A supplier misses a delivery once, she notices the pattern before it repeats, and the organisation quietly starts trusting her judgment over the system’s default rules. Three years later she is not running a documented process with occasional exceptions — she is the process, and the documented version in the training folder describes a simpler world that stopped being true a long time ago.
The reason nobody intervenes is the reason it is dangerous: she is good at her job. A struggling buyer gets coached, escalated, and eventually supported by a second pair of eyes. A buyer who never drops a ball gets left alone, because there is nothing visibly wrong to fix. The gap between what she knows and what the organisation has captured about what she knows grows every year she keeps performing — and it is invisible for exactly as long as she stays.
The cost does not show up while she is at her desk. It shows up the day she is not — and by then it is too late to build the thing that would have prevented it.
The measure of a healthy procurement function is not how well it runs when the best buyer is in the room. It is how well it runs on the Tuesday she is not.
The concentration itself does not show up as a red flag anywhere in IFS Cloud — it is the absence of something, not the presence of an error. What you can see are its shadows: a small number of buyer codes attached to a disproportionate share of purchase orders that were escalated, chased or rescued outside the standard workflow; suppliers whose confirmation delays never trigger the same generic threshold rule twice, because the buyer intervenes before it fires; and a training folder or SOP that has not been updated since a point release everyone has forgotten the number of.
None of that is visible from a summary dashboard. It becomes visible only when someone asks a specific question: for this buyer’s supplier portfolio, what percentage of exceptions were caught by a system rule versus caught by her noticing first? If the honest answer is “mostly her,” the concentration is already real, whether or not anyone has named it yet.
The goal is not to replace her judgment — it is to stop the organisation’s exposure being entirely proportional to her presence.
| Tacit judgment | Documented system rule | |
|---|---|---|
| Where it lives | One person’s memory | IFS Cloud, applied consistently |
| Survives absence | No | Yes |
| Transfers to a new hire | Only through years of exposure | Immediately, on day one |
| Auditable | No trace of why a call was made | Logged rule, logged trigger |
| Improves with review | Only if she reflects on it herself | Tunable by anyone with visibility |
None of this argues she should stop exercising judgment on the cases that genuinely need it. It argues that the routine ninety percent of what she does by pattern — which supplier is drifting, which order needs a call today — belongs in a rule the system enforces, freeing her judgment for the harder ten percent only she can actually add value to.
This only works if it is framed — honestly — as protecting the function, not auditing the person. Done the wrong way, it reads as a performance review. Done the right way, it reads as building her a backup.
Built this way — standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — the rules stay update-safe and avoid the upgrade tax, the same discipline behind a supplier behaviour-change signal or an unconfirmed-PO escalation. Clear ownership of who can see and change each rule follows the same logic as segregation of duties in IFS Cloud.
Documentation captures what the process is supposed to be. It rarely captures the exceptions an experienced buyer makes by instinct, and it does not act on its own. The goal here is a rule IFS Cloud enforces automatically, not a page someone has to remember to read.
A departure is one moment you can at least plan a handover around. Concentration risk exists every single day she is simply out sick, on leave, or in back-to-back meetings — long before anyone has thought about a resignation.
Only if it is introduced as one. Framed and sequenced correctly — interview first, give her the resulting alerts first, extend coverage only once she trusts the rules — it reads as removing her busywork, not her judgment.
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so there is nothing here for the next R1/R2 release to quietly break.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally — 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.
If your best buyer’s judgment is currently your only safety net, a dry-run month will show you exactly which of her instincts can become a system rule today. Fixed price, nothing goes live until she has seen it work.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A delivery is due today. The buyer means to check it. Then a supplier calls about a different order and the call runs long. A quality issue on the shop floor needs someone right now. The check moves to tomorrow. Tomorrow, the same thing happens again: another fire, another reason, another day added to the queue. By Friday the delivery date was four days ago and nobody has looked at it. Nothing here counts as negligence. It is prioritisation working exactly as designed — the urgent has a person asking for it, and the important has only a date sitting quietly in IFS. The cost of this pattern is real, but it stays invisible, because it is distributed one day at a time across fifty orders and twelve months. This article covers why deferral happens, what it actually costs, how to see it in IFS Cloud, and how to fix it without asking anyone to be more disciplined than they already are.
Deferral is not a character flaw. It is what happens when every open exception competes for the same finite attention, and the loudest one always wins. A supplier on the phone, a machine down, an angry email from a customer — each of these has a person attached to it, asking in real time. A purchase order sitting three days past its confirmation date has no one asking. It waits patiently in a queue, and patience is exactly what lets it slip.
The system reinforces the pattern. Most screens show the exception as a line in a list, not as an event demanding a response. There is no ring, no red banner, no name attached to the delay — just a date that quietly falls further behind the current one. Buyers who are conscientious about the loud problems are, by definition, the same people too busy to go looking for the quiet ones. The check does not fail because someone is careless. It fails because nothing in the workflow makes it compete on equal terms with whatever is happening right now.
The arithmetic of deferral is deceptively small at the level of one order. A day slips, someone catches it a day late, the shipment still arrives, mostly on time. Multiply that by fifty open orders running at once and twelve months of the same daily trade-off, and the accumulated days of inaction stop looking small:
The cost never shows up as a line item called “deferred check.” It shows up as a late shipment, an expedite fee, or a customer call — three steps removed from the day someone meant to look and did not.
IFS Cloud already has everything needed to see deferral, because every open exception carries an age. A purchase order past its confirmation date, a requisition waiting on approval, a delivery running late — each one has a created date and a current date, and the difference between them is the story. What is missing is not data; it is a place that turns “days since flagged” into something someone has to act on before it grows another day older.
Run the numbers today and the picture is usually more sobering than anyone expects — not the count of open exceptions, but the average age of the ones still open, and the tail of orders that have been sitting for a week or more. That tail is where the real cost lives, and it stays invisible in any dashboard that only reports the current snapshot rather than how long each item has been waiting.
The fix is not a reminder to try harder tomorrow. It is closing the gap between how urgent things get attention and how important things get attention, using the same trigger-and-action pattern behind other Custom Events in IFS Cloud: watch the age of the exception, and the moment it crosses a threshold, turn it from a quiet line into an alert with a name attached.
| Manual recall | Automated escalation | |
|---|---|---|
| Runs when | Whenever something louder isn’t happening | On a schedule, every day |
| Coverage | Whatever is left after today’s fires | Every open exception, every buyer |
| Visibility | A date sitting in a list | A named alert with an age and an owner |
| Owner | Whoever happens to notice | Assigned by rule, every time |
| Fails when | Exactly the busy days it matters most | Never — it does not compete for attention, it demands it |
This does not remove judgement from the buyer. It removes the requirement that the buyer remember to apply that judgement on a day already full of louder problems.
Roll this out the same way you would any exception rule: prove it before anyone depends on it.
Because the whole thing runs on standard Custom Events and Workflows inside the IFS Extensibility Framework, there is no core modification for the next release to break. It is update-safe, and it avoids the upgrade tax entirely.
No. It is what happens when every exception competes for the same attention and the loudest one wins by design. The fix is structural, not motivational: give the important item the same visibility the urgent one already has.
Training assumes the constraint is knowledge or willpower. The constraint is usually time and competing signals. An escalation rule changes what competes for attention instead of asking buyers to fight the same losing battle with more resolve.
Not if it is thresholded and capped. The rule fires once an exception crosses an agreed age, not on every minor delay, and a frequency cap stops the same order escalating repeatedly. Dry-run first shows you the real volume before anything goes live.
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so the next R1/R2 release has nothing here to break.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally — 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.
If deferred checks are quietly costing you days across dozens of open orders, a dry-run week will show you the real scale for the first time. On a 30-minute call I’ll map the escalation to your exception types — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Supply Chain
Key takeaways
On-time delivery: 94 percent. The dashboard is green. The monthly review notes the improvement and moves on. What the number does not show: the six percent that were late included the three largest orders of the month. Two of them stopped a production line. One cost a customer. None of that is visible in a single aggregate figure, because 94 percent is an average, and averages are built to erase exactly the kind of detail that would have made someone act sooner. Aggregate metrics are not wrong. They are honest about the wrong thing — they tell you the average, and in supply chain the average is rarely what does the damage. This article covers why on-time delivery in particular hides its worst cases, what that costs, how to surface the outliers inside IFS Cloud, and how to build a rule that treats a late critical order differently from a late routine one, without replacing the KPI you already report.
On-time delivery is calculated the same way almost everywhere: on-time lines divided by total lines, expressed as a percentage. Every line counts exactly once, regardless of what it was carrying. A pallet of low-value consumables that arrived a day late counts the same as the single component that stopped a production line for a week. The formula has no concept of consequence, only of timing.
That is not a flaw in the formula — it is a summary statistic doing exactly what summary statistics do. The problem starts when the number is treated as the finding rather than the starting point. A team that watches the percentage month over month can genuinely improve the average while the handful of orders that actually cost money stay exactly as late as they always were, simply outnumbered by everything that shipped on time.
The gap between the metric and the damage is where the real cost hides. It shows up downstream, in places the on-time percentage never looks:
Ninety-four percent on-time is not a result. It is an invitation to look at the six percent and ask which of them actually hurt.
IFS Cloud already carries what is needed to separate the outliers from the noise: order value, customer, part criticality, and promised versus actual delivery date all live on the same records the on-time percentage is calculated from. The aggregate simply never asks those fields a question.
Filter late lines by order value above a threshold, by a criticality flag, or by top-tier customer, and the six percent stops being an undifferentiated tail — it becomes a short, specific list of the deliveries that were actually expensive to miss. That list is usually a fraction of the size of the full late report, and far more useful.
The fix does not replace the on-time percentage — leadership will keep asking for it. It adds a second, narrower view built on the same automation pattern behind other SCM alerts in IFS Cloud, watching for the late orders that were never supposed to be treated the same as the rest.
| Aggregate KPI | Outlier-weighted monitoring | |
|---|---|---|
| What it measures | Percentage of lines delivered on time | Which late orders actually mattered |
| Weighting | Every line counts the same | Weighted by value, criticality, customer tier |
| What it hides | The orders that stopped production | Nothing — each is flagged on its own |
| Reviewed | Once a month, as an average | The moment a threshold is crossed |
| Fails when | The average stays green while a handful of misses cost the most | Rarely — each miss is visible individually |
None of this argues for abandoning the percentage. It argues for not stopping there.
Building the second view is a modest project, not a re-platforming exercise.
Built inside the IFS Extensibility Framework with standard Custom Events and Workflows, the flagging rule sits alongside the core reporting without touching it — update-safe, with nothing here for the next release to break.
Because the percentage treats every late order as equally bad. A late shipment of low-value stock and a late shipment that stops production both count as one miss out of many, so the average can look healthy while the handful of misses that actually cost money go unnoticed.
Most teams start with what they already know: a value threshold, a small list of top-tier customers, or a criticality flag already used in planning. The dry-run period usually confirms or corrects the first guess quickly.
No. It sits alongside it. Leadership keeps the trend line; the operational team gets a short list of the misses that actually deserve a conversation.
Yes. It uses standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no modification to core on-time delivery reporting.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally — 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.
If you suspect your green on-time delivery number is hiding a handful of expensive misses, a dry-run week will show you exactly which orders they are. On a 30-minute call I’ll map the outlier rule to your critical orders — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A buyer spends two hours a day checking order states. Two hours, five days a week, forty-eight working weeks a year. That is four hundred and eighty hours -close to twelve full working weeks - spent on something a system could do in seconds. Not because IFS cannot do it. Because nobody configured it to. This is the hidden cost of manual monitoring, and it is easy to miss precisely because it never looks like a cost. It looks like diligence. The buyer feels productive, the exceptions get caught, the organisation sees results, and nobody asks whether the same result could have been achieved without quietly consuming a quarter of a full-time employee’s year. The most expensive monitoring is the kind that works well enough that no one ever questions what it costs to run.
Checking order states by hand feels responsible. It is visible, it produces catches, and it never triggers the awkward conversation an automation project does — budget, scope, who owns it. A buyer who scans the screen every morning is doing exactly what a good buyer is supposed to do, and that is precisely why nobody questions whether it should be a screen-scan at all.
It survives because the cost is invisible on the org chart. Two hours a day never appears on an invoice, a project plan, or a monthly report; it simply disappears into “buyer work,” alongside negotiation, expediting and everything else the role covers. Nobody totals the hours, so nobody ever sees the number large enough to act on.
The bill is not one number, it is several, and none of them appear next to “monitoring” on any report:
The most expensive monitoring is the kind that works. It works well enough that nobody ever asks what it costs to keep running.
The starting point is not a system query, it is a short conversation, timed honestly: ask each buyer what they check every day, how long it takes, and why they check it manually instead of relying on a report. Most of what surfaces is repetitive — the same filter, the same sort, the same screen, scanned for the same handful of conditions — which is exactly the pattern a Custom Event is built to replace.
Once the checks are listed, IFS itself can usually already answer the underlying question — unconfirmed orders, orders below a coverage threshold, deliveries running late — through the same data the buyer is reading by eye. The audit does not need new instrumentation, only the discipline to write down what “I just check it every morning” is actually costing, in hours, every week.
The comparison is not about accuracy — a careful buyer is usually accurate. It is about where the hours go and whether coverage depends on a person’s calendar.
| Manual | Automated | |
|---|---|---|
| Time cost | ~2 hours/day per buyer | Seconds, on schedule |
| Consistency | Depends on the day | Same rule, every day |
| Scales with orders | No — more volume means more hours | Yes, at no extra hours |
| Visible as a cost | No — buried in “buyer work” | Yes — a rule with a scope and a log |
| Buyer’s time goes to | Scanning a screen | The exceptions that actually need judgement |
Automating the check does not remove the buyer’s job. It removes the part of the job that was never really a judgement call — scanning for a state that a rule can recognise faster and more consistently — and leaves the buyer with the exceptions that genuinely need a person’s experience.
Start with the check that costs the most hours, not the one that feels most urgent.
Because each rule is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — it is update-safe and stays out of the core, which is also why teams that automate this way tend to see up to 60% less regression testing at the next upgrade: there is simply less bespoke code sitting in the path of the release.
Ask each buyer or planner what they check daily by habit rather than by system alert, and how many minutes each check takes. Multiply by working days and headcount. Most teams are surprised the number reaches hundreds of hours a year once it is added up honestly.
No. It removes the repetitive scanning, not the judgement. The freed hours typically go straight back into negotiation, supplier development and the exceptions that genuinely need a person — work the role was always supposed to prioritise.
Whichever consumes the most hours across the most people, not whichever feels most dramatic. A five-minute daily check done by twenty buyers usually costs more, in aggregate, than one buyer’s occasional deep investigation.
Yes. Each monitoring rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification. Nothing here is the kind of customisation that the next R1/R2 release quietly breaks.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally — 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.
If your buyers are quietly spending hours a week scanning screens IFS could watch for them, a short time-audit will show you exactly how many. On a 30-minute call I’ll map the highest-cost checks to automation rules — fixed price, dry-run before anything changes.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A delivery date passes on the 3rd. The buyer is tied up today, the material isn't critical, and we've heard this from the operations team: “we will catch it at month-end.” Month-end arrives. The exception report shows twelve late deliveries. Three are now critical. One has already stopped a production line. The buyer spends two days firefighting instead of the one hour it would have taken to check on the 4th. This is not a story about a lazy review process — the monthly report did exactly what it was built to do. It is a story about latency: the distance between a record changing state in IFS Cloud and a human finding out about it. This article covers why that distance compounds, how to see the real cost of it, and how to shrink it without adding more meetings or more reports.
Monthly review is inherited from an era of batch reporting, when a report was expensive to run and the finance calendar was the only rhythm a business had. It survives because it is a real, working cadence — it does catch everything eventually — and because nobody has had to prove, with a number, that the delay itself has a cost.
The judgement that a given exception is “not critical today” is made in the moment, with no evidence about how it will look in three weeks. Nobody owns the daily exception list, because it is treated as someone else’s report rather than a live risk. So it waits, along with everything else that seemed fine on the day it was postponed.
The cost of catching an exception on day one is not the same as catching it on day twenty-eight. Every day it sits unaddressed, the cost compounds along several dimensions at once.
A day-one fix costs an email. A month-end fix costs two days, a stopped line, and a harder conversation with the customer.
Every exception that shows up on a month-end report already existed as a state change in IFS Cloud on the day it happened — a delivery date passed, an order stayed unconfirmed, a stock level fell below minimum. The report does not create that information; it simply waits a month to surface it. The same state change can trigger a Custom Event the day it occurs, which means the report and the alert are reading identical data, just at very different latencies.
The practical question is not whether to build same-day detection for everything — that would recreate the alert-storm problem in a different shape. It is choosing the two or three exception types where the cost curve is steepest, and closing the gap there first, following the same trigger-and-action pattern used across the SCM automations for IFS Cloud.
Both approaches surface the same underlying facts. They differ in exactly one dimension — and that dimension is where the cost lives.
| Periodic (month-end) review | Real-time exception detection | |
|---|---|---|
| Detection lag | Up to one full month | Same day the state changes |
| Cost per exception | Compounded by delay | Closer to the base cost |
| Who is affected | Whoever inherits the backlog | The person who can still act on it |
| Scalability | Gets harder as volume grows | Runs the same regardless of volume |
| Trust in the number | Reactive, arrives as a surprise | Expected, arrives while fixable |
Keep the month-end report for what it is genuinely good at: a trend view and a sanity check. Do not ask it to be the thing that catches a problem while it is still cheap to fix — that job belongs to the exception the moment it happens, exactly as covered for one specific case in unconfirmed purchase orders in IFS.
Shrinking detection latency is not a big-bang project. It is picking the highest -cost exceptions first and proving the model before it spreads.
Because each rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, none of it is core modification — it stays update-safe and avoids the upgrade tax while quietly making the month-end report shorter every cycle.
Only if it is built for every exception at once. Starting with the two or three highest-cost types, and tuning thresholds during a dry-run period, keeps volume low enough that each alert still gets read and acted on.
No. The month-end report stays useful as a trend view and a sanity check on totals. Real-time detection takes over the job of catching individual exceptions while they are still cheap to fix — a job the monthly cadence was never fast enough to do.
Look at last month’s exception report and ask which items were mild on day one and severe by month-end. Those with the steepest cost curve over time give you the best return for closing the detection gap first.
Yes. Each rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so nothing here is at risk from the next R1/R2 release.
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally — 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.
If your team is still catching exceptions once a month, the cost of that delay is already visible in last month’s firefighting hours. On a 30-minute call I’ll help you rank your exceptions and map the two worth fixing first — fixed price, dry-run before anything goes live.
Calculate your return on investment