Select your language
Select your language
Independent IFS Cloud practice · Manufacturing
Key takeaways
Every manufacturing site has one. A spreadsheet that is not on the network. It lives on a desktop. It has a dozen tabs, and one person understands the columns that actually drive the numbers everyone downstream relies on. It tracks the things IFS does not track, or tracks in a way that no longer matches how the floor works. It bridges the gap between what was configured at go-live and what the operation turned into over the following three years. The spreadsheet works perfectly — until the author is on leave, or the laptop dies, or someone sorts column F without selecting the whole range. A spreadsheet that runs a factory is not a tool. It is a liability wearing a familiar face, and the familiarity is exactly what makes nobody question it. This article covers why it exists, what it actually risks, and how to bring its logic into IFS Cloud without a disruptive rebuild.
At go-live, IFS was configured to match the operation as it existed on that date. The operation did not stand still. New product lines arrived, a quality step got added, a customer started demanding a report nobody had asked for before — and every one of those changes needed either a proper configuration change or a workaround. A configuration change needs budget, approval and a project slot. A workaround needs Excel and an afternoon.
A power user who understands both the process and a spreadsheet formula solves the gap locally, inside their own authority, without asking anyone. It works, so it stays. Three years later nobody remembers it was meant to be temporary, and the plant now depends on a file that IT does not know exists, finance cannot audit, and only one person can actually maintain.
The risk rarely shows up as a single dramatic failure. It shows up as an accumulation of small exposures that only become visible the day one of them triggers.
The spreadsheet does not fail when it breaks. It fails long before that, the moment everyone stops noticing it is the thing actually running the shop floor.
You will not find a shadow spreadsheet by querying IFS Cloud — by definition it lives outside it. What you can do is instrument the boundary: use Quick Reports and Custom Fields to see what people are actually pulling out of IFS and what fields get manually annotated after export, because that is where a gap between the system and the shop floor tends to surface first. A short, direct conversation with each cell or line supervisor — “what do you keep track of that IFS does not show you?” — usually surfaces the rest within a day.
The comparison covered in Quick Reports, Custom Fields and Custom Events is the right lens here: each shadow spreadsheet column is really an unmet requirement for one of those three tools, and knowing which one it maps to tells you how hard the fix actually is.
The comparison is not spreadsheet versus no spreadsheet. It is an uncontrolled file versus the same logic captured inside a structure IFS Cloud actually manages.
| Desktop spreadsheet | Systematic extension | |
|---|---|---|
| Backup | Whatever the laptop policy is | Standard system backup |
| Access control | Whoever has the file | Role-based, as configured |
| Audit trail | None | Logged change history |
| Single point of failure | One person, one device | None — part of the platform |
| Alignment with source data | Manually re-entered, drifts | Reads live IFS data |
None of this requires ripping the spreadsheet out overnight. It requires identifying which of its columns actually matter and giving each one a proper, supported home — a Custom Field where a value needs to live on the record, a Quick Report where it needs to be seen, a Custom Event where it needs to trigger something. That is the same Clean Core discipline covered in Clean Core in IFS Cloud SCM.
Treat the spreadsheet as a specification, not an enemy. Its author has already solved the problem once; the job is to give that solution a supported home.
Because the replacement is built with standard Custom Fields, Quick Reports and Custom Events inside the IFS Extensibility Framework, it is update-safe — no core modification for the next release to break, and no more single laptop standing between the floor and a working process.
Frame it as protecting their work, not replacing it. Most owners built the spreadsheet because nobody gave them a proper tool, and they are often the most relieved once the logic is safely captured somewhere it cannot be lost with one hardware failure.
It depends on how much of it turns out to be logic versus notes. A spreadsheet with three or four columns that actually drive decisions can often move to Custom Fields and a Quick Report within a couple of weeks, parallel run included.
No. A spreadsheet used for genuine one-off analysis is not the risk. The risk is a spreadsheet that has quietly become a permanent, single-person system of record for something IFS should be tracking and backing up.
Yes. The migration uses standard Custom Fields, Quick Reports and Custom Events inside the IFS Extensibility Framework — no core modification, so nothing here is broken by 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 you suspect a spreadsheet is quietly load-bearing somewhere in your operation, a short discovery pass will tell you exactly which columns matter. On a 30-minute call I’ll map a safe path to bring it inside IFS Cloud — fixed price, parallel run before anything is retired.
Independent IFS Cloud practice · Supply Chain
Key takeaways
For two years, a supplier confirms every order within two days. Reliable enough that nobody thinks about it — until, one week, an order sits unconfirmed for seven days. Then the next one does too. A buyer who has worked with this supplier for years notices immediately: this is not how they behave. But nothing in the system agrees. The order is within the age most escalation rules would allow, so no threshold fires. The only thing that caught the change was one person’s memory of what normal looks like for this specific supplier — and memory does not scale, does not survive a handover, and is not written down anywhere IFS can act on. By the time the pattern is undeniable, several orders are late and the supplier’s trouble is no longer a secret to anyone but the business relying on them. This article covers why pattern changes go unnoticed, what they cost, and how to turn a buyer’s gut feeling into a rule IFS Cloud can watch for you.
Confirmation-lag rules in most IFS Cloud setups — where they exist at all — use one threshold for every supplier: flag anything unconfirmed after, say, five days. That catches the stuck order. It says nothing about a supplier whose average lag just doubled while staying inside the threshold. A supplier who normally confirms in two days and now takes four is still within a five-day rule, and still telling you something is wrong.
The knowledge that would catch it lives in one person’s head. An experienced buyer holds a rough baseline for every supplier they manage — who is fast, who is slow, who never misses. That baseline evaporates the moment the buyer goes on leave, changes role, or the supplier gets reassigned. Newer buyers have no baseline to compare against at all, so a slow week looks the same as any other week. As supplier counts grow, no one can hold a hundred individual rhythms in their head at once — and the system that could was never asked to.
The cost is not the late order itself — that is visible and gets fixed. The cost is everything that happens because the warning arrived only when the pattern had already broken down completely.
The supplier almost always knows before you do. The only question is how many orders pass before you find out too.
The confirmation date, the order date and the supplier are already recorded on every purchase order line in IFS Cloud — the data needed to build a baseline is not missing, it is just never compared to itself. A rolling baseline per supplier, built from a trailing window of confirmed orders (ninety days is a reasonable start), gives you a typical confirmation lag for that specific supplier rather than one number for the whole supplier base.
Detection then becomes a comparison, not a threshold: does the new order’s confirmation lag sit meaningfully outside that supplier’s own history? A supplier who is normally two days and is now six has moved further from their own baseline than a supplier who is normally four days and is now six — even though the raw number is identical. That distinction is invisible to a flat day-count rule, and it is exactly the distinction an experienced buyer makes instinctively — just without documenting it, and without scaling past their own memory. It is a different signal from the flat threshold covered in unconfirmed purchase orders in IFS.
The two approaches are not competitors — a flat threshold and a baseline check catch different failures, and most mature setups run both.
| Static threshold | Behavioural baseline | |
|---|---|---|
| What it catches | Orders stuck past a fixed limit | Suppliers whose normal pattern has shifted |
| Sensitivity to supplier profile | None — one rule for everyone | Personalised — compares each supplier to itself |
| Earliest warning | After the threshold is breached | Often before any single order looks late |
| False positives | Low, but blind to slow drift | Depends on window length and tuning |
| Maintenance | Set once | Recalculates itself as history accumulates |
Run the static rule to keep catching orders that simply sit too long. Layer the baseline check on top to catch the supplier who is still technically within every threshold but no longer behaving like themselves.
Behavioural detection is more sensitive than a flat threshold, so it earns a more careful rollout.
Because the whole thing runs on standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, there is no core modification for the next release to break — it stays update-safe and avoids the upgrade tax. The same discipline protects related rules such as supplier price-change alerts.
An unconfirmed-PO rule flags any order past a fixed age. A behavioural check compares a supplier’s current pattern to their own history, so it can flag a supplier who is drifting while still inside that fixed age — the two rules complement each other rather than replace one another.
Ninety days, or roughly ten to fifteen confirmed orders per supplier, is a workable starting point. Lower-volume suppliers need a longer window or a wider tolerance, since a single slow order swings a thin baseline more than it would a busy one.
Tuned well, no. The deviation threshold is set against each supplier’s own variability, not a flat number, so a supplier who is naturally erratic needs a bigger deviation before it fires. The dry-run month is where you catch and correct that before anyone sees a live alert.
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 a buyer’s memory is currently your only early-warning system, a dry-run month will show you what a baseline check would have caught. On a 30-minute call I’ll map the rule to your top suppliers — fixed price, dry-run before anything goes live.
Independent IFS Cloud practice · Supply Chain
Key takeaways
Monday, 7:30am. Coffee. Open IFS. Run through purchase orders one by one, checking which suppliers confirmed and which stayed silent. It takes forty minutes. It has taken forty minutes every Monday for three years. The person who does it is very good at it — they know the suppliers, they know the patterns, they know which silence means trouble and which means the contact person is on holiday. From the outside this looks like the simplest kind of routine: open a screen, scan a list, close it again. From the inside it is a small act of expertise, performed from memory, that nobody has ever had to explain out loud. That is exactly the problem. Here is the uncomfortable question: what happens to that forty-minute check on the Tuesday that person does not show up? This article covers why that knowledge stays tacit, what it costs when the routine cannot run, and how to turn a private judgement call into something the system can apply consistently.
Nobody sits down to write a specification for a forty-minute Monday routine. It gets learned the way most tacit skills get learned: by doing it, week after week, until the pattern recognition happens faster than the person doing it could explain it. Ask them why supplier X’s silence is fine and supplier Y’s is not, and the honest answer is usually some version of “I just know” — built from three years of watching who is reliably slow to reply and who has never once missed a confirmation without a reason.
There is also no obvious moment to force it into writing. The routine works. It has worked for three years. Nothing about a working process creates pressure to document it — documentation gets written after something breaks, not before, and by then the person who could have written it is exactly the person who is unavailable.
The cost is not visible on any ordinary Monday. It shows up the one Monday the routine cannot run as normal, in four specific ways:
A process that depends on one person showing up at 7:30 is not a process. It is a bet — and bets have a way of being called on the worst possible Tuesday.
The good news is that most of what looks like intuition is actually pattern recognition against data that already exists in IFS Cloud — supplier confirmation history, typical response lag per supplier, which categories routinely run late without consequence. The person doing the Monday check is, in effect, running an informal statistical model in their head every week.
Making that visible starts with one conversation, not one system change: sit with the person who does the check and ask them to narrate a real Monday out loud — which order they skipped past, which one made them pause, and why. Most of that “why” maps cleanly onto data IFS Cloud already holds: supplier, category, historical confirmation lag, order value. The parts that do not map onto data are usually the genuinely judgement-heavy exceptions worth keeping human — and now you know exactly which ones those are.
Externalising the pattern does not mean replacing judgement with a black box. It means moving the part of the check that is genuinely pattern-matching into a rule, and keeping the genuinely judgement-heavy exceptions with a person.
| Private ritual | Externalised rule | |
|---|---|---|
| Where the knowledge lives | One person’s memory | A documented rule, run by the system |
| Runs when that person is out | Not reliably | Every Monday, regardless |
| Consistency | Depends on who covers | Same criteria, every time |
| Onboarding a replacement | Months of shadowing | Read the rule, handle the exceptions |
| What’s left for a human | Everything, all the time | Only the genuine judgement calls |
The point is not to remove the person from the process — it is to stop the process from depending entirely on them being present. The exceptions that stay human become more interesting, not less, once the routine pattern-matching is handled elsewhere.
Do it alongside the person who runs the ritual today, not around them — they are the source of the rule, not an obstacle to it.
Built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL, no core modification — the rule is update-safe from day one, so it avoids the upgrade tax while it quietly covers every Monday.
It is related but distinct. Coverage risk is about who runs the check when someone is absent. This is about what happens even when a stand-in is present — the check runs, but the judgement inside it does not transfer.
Most of it, yes — the parts based on supplier history, category and confirmation lag map cleanly onto data IFS Cloud already holds. What is left over is usually a small set of genuine exceptions, which is exactly what should stay with a person.
Done well, the opposite. They become the source the rule is built from, and they keep the interesting exceptions instead of the repetitive scanning — and the team stops depending on them never taking a holiday.
Yes. The rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, nothing 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 Monday check only really works because one person shows up, the fix is smaller than it feels. On a 30-minute call I’ll help you capture what they actually know and turn it into a rule — fixed price, dry-run before anything changes.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A purchase order sits in Released for eleven days. Nobody notices. The delivery date passes without anyone flagging it, and on day eleven the part still has not arrived. Production stops for four hours while a line waits on a component that costs a few hundred euros. The part itself is cheap. The line stoppage is not: four hours of idle labour, a missed shipment, a customer who now has a later delivery date than the one they were promised. The ratio between what the part cost and what the miss cost is not a freak outcome — it is close to routine, and it is exactly why exception management deserves more attention than it usually gets. This article covers why the ratio holds, what drives it, how to see the gap before it becomes a stoppage, and how to close it without turning every buyer into a full-time exception hunter.
Nothing about the eleven days was hidden. The order state was correct. The delivery date was correct. The information needed to catch the problem on day two, not day eleven, was sitting in IFS Cloud the entire time. What was missing was not data — it was someone looking at that specific field, on that specific order, before it mattered.
That is the trap with low-value exceptions. A buyer scanning a screen full of open orders naturally weights attention by value: the €80,000 order gets a second look, the €200 line does not. But the cost of the miss has nothing to do with the value of the part. It has to do with what that part unlocks downstream — a line, a shift, a shipment — and that downstream cost is invisible from the order screen.
The cost of a missed check is almost never the material. It shows up downstream, in four places that never get billed back to the exception that caused them:
The most expensive exception in your supply chain is the one you had the data to prevent and still missed.
IFS Cloud already has everything this needs: order state, confirmation status, promised delivery date, all attached to the order the moment it is raised. An order that stays in Released past a sensible age, with no confirmation and a delivery date approaching, is a pattern you can filter for today — the same underlying signal behind an unconfirmed purchase order, just viewed through the lens of downstream risk rather than supplier behaviour.
The gap is not visibility. It is that visibility, on its own, requires someone to look at the right filter on the right day. A €200 line does not earn that attention on a busy Tuesday, and that is precisely why it needs a rule that checks for it regardless of value, rather than a person who has to remember to.
The difference is not effort — a good buyer already works hard. The difference is what a rule catches that human attention, however diligent, structurally cannot.
| Manual | Systematic | |
|---|---|---|
| Weighted by | Order value, instinctively | Downstream risk, by rule |
| Small orders | Easy to skip | Checked the same as any other |
| Consistency | Varies by buyer, by day | The same rule, every time |
| Detection point | Whenever someone notices | The day the threshold is crossed |
| Worst case | Day eleven, at the line | Day two, at a desk |
A systematic check does not replace the buyer’s judgement — it removes the part of the job that depends on remembering to look at something that did not look urgent. That is exactly the gap between the €200 order and the €40,000 stoppage.
Start narrow, let the data show you where the ratio bites hardest, and expand from evidence rather than a guess.
Built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL, no core modification — the check itself is update-safe, so it avoids the upgrade tax entirely while it keeps watching.
It is close to routine. Whenever a missing part can stop a line, the cost of the miss is set by what the line produces per hour, not by what the part cost — and that gap is usually large.
Because attention that is weighted by order value will always under-check low-value lines — it is a natural, reasonable instinct that happens to be exactly wrong for this specific risk.
It shares the same underlying signal — order state and date — but the framing here is downstream cost, not supplier behaviour. The two checks complement each other rather than duplicate.
Yes. The check is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, nothing 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 a €200 order has ever cost you a line stoppage, the fix is smaller than the incident. On a 30-minute call I’ll map a systematic check to your order states and thresholds — fixed price, dry-run before anything sends.
Independent IFS Cloud practice · Automation & Governance
Key takeaways
Writing the query got nearly free this year. Point a model at your IFS Cloud projections and it drafts a working OData call in minutes — work that used to take a developer half a day. That shift is real and it is useful. But it quietly moves the hard part of ERP automation somewhere else, and a lot of teams have not noticed the move yet. The code stopped being the scarce, valuable thing. What did not get any cheaper is standing behind what that code does once it runs unattended against live purchase orders, live suppliers and live customers, at an hour nobody is watching. This article is about that gap — between generating automation and being accountable for it — and why it matters more, not less, the easier automation gets to produce.
For most of the history of ERP customisation, the scarcity was technical: someone had to know the schema, know PL/SQL, know how IFS Cloud projections and Custom Events actually fit together. That scarcity acted as an accidental filter. If you could write the automation, you had usually also spent enough time in the system to have a feel for what could go wrong when it ran against real data.
A model removes the technical filter without adding the judgment that used to come bundled with it. Someone who has never opened IFS Cloud can now get a plausible-looking PL/SQL block or OData call in minutes. The code may well be correct. What is missing is the part that was never really about writing code: knowing what this specific query will do the first time it runs over five years of history, on a Monday morning, against suppliers who will actually receive the emails it sends.
Nothing, right up until the automation does something it should not have — and then the bill arrives all at once.
A model does not take the blame. It has no name to put under the output.
It rarely shows up as a dramatic outage. It shows up as a Custom Event or a scheduled task nobody can quite explain in a change review — one whose logic is sound but whose author cannot say, from memory, what happens on its first production run against five years of order history, or who reviewed the recipient list before it went live.
The tell is usually a one-line answer to a two-part question. Anyone can usually explain what a piece of generated automation is supposed to do. Far fewer can explain, without checking, who approved it running against production, what its blast radius is if the assumption behind it turns out to be wrong, and who gets paged if it misfires.
The code itself can be identical. What separates the two columns is everything wrapped around it.
| AI-drafted script | Accountable automation | |
|---|---|---|
| Author on record | Whoever prompted it, informally | A named owner, documented |
| First-run behaviour | Untested against full history | Dry-run against real data before go-live |
| Blast radius | Unknown until it runs | Scoped and rate-limited in advance |
| Who gets paged | Whoever notices first | A defined owner with context |
| Update-safety | Not considered | Built inside the Extensibility Framework |
None of this argues against using AI to draft the query — it is a legitimate accelerant for the part of the work that was never the risky part. It argues for treating the draft as a starting point that still needs an owner, not a finished deliverable because it ran without an error.
The goal is not to slow down the drafting. It is to make sure ownership catches up to it before anything touches production.
The same discipline that keeps Custom Events and a Clean Core maintainable applies whether a person or a model drafted the first version — AI changes who writes the first draft, not who is answerable for the result.
No — using a model to draft a query or a first pass at logic is a legitimate time-saver. The point is that drafting and owning are two different jobs, and a generated draft still needs a named owner, a dry-run, and a review before it touches production.
An unscoped first run — code that was validated against a small test case behaving very differently the first time it processes the full history of a live table, with no rate limit or dry-run to catch it before it reaches real suppliers or customers.
It is not fundamentally different — it is a reminder that AI-generated code deserves the same review any custom ERP code gets, at a moment when its polished, instant appearance tempts teams to skip that step.
Yes, provided the delivered rule — regardless of how the first draft was produced — is standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no core modification for the next release 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.
Whatever drafted the first version, a 30-minute call can help you scope the blast radius, the dry-run and the ownership before anything AI-assisted touches live purchase orders, suppliers or customers.
Independent IFS Cloud practice · Clean Core & Integration
Key takeaways
You can learn a great deal about a supply chain by reading IFS Cloud and never writing a single row back to it. That is the whole idea behind a read-only OData integration: a dedicated account, a handful of standard projections, and a monitoring layer that watches order states, delivery dates and stock levels the same way any IFS Cloud client already does. Nothing installed in the database. No custom objects planted in the core. Nothing to uninstall if the project ends. Most teams do not reach for read-only by design, though — they reach for it after a writeback integration has already cost them a weekend during an upgrade. The moment a monitoring tool starts changing data, even in small, well-intentioned ways, it stops being something you watch and becomes something you have to test, patch and defend at every release. This article covers why that write path creeps in, what it actually costs, and how to build the alternative properly.
Nobody sets out to build a fragile integration. It starts small: a monitoring tool flags a stale purchase order, and someone asks whether it can also mark the alert as acknowledged so the list does not fill up with noise. That single write field feels harmless. It is one column, one status flag, one small mercy for whoever reviews the output.
The trouble is that IFS Cloud does not have a concept of a harmless write. Every write path touches a business object with its own validation, its own state machine and its own rules that change release over release. A field that accepted any value in one version can carry a new mandatory dependency in the next. What began as a convenience for the monitoring tool becomes a customisation the upgrade team has to find, understand and requalify — usually without knowing it exists, because nobody wrote it down as an integration.
The cost is not visible on the day you add the write. It shows up two or three upgrades later, spread across four places:
The cheapest integration to maintain is the one that never asked IFS Cloud to trust it with a write.
The mechanics are standard, not exotic. IFS Cloud already exposes the data a monitoring layer needs through its own OData projections — order state, confirmation status, delivery date, stock quantity — the same projections the standard client uses. You create a dedicated integration account, attach a permission set that grants read access to exactly the projections in scope, and nothing else. No custom entity. No new table. No PL/SQL package sitting in the database waiting to be discovered by the next upgrade.
From there the monitoring tool polls on a schedule, filters for the states that matter, and raises whatever alert or dashboard update the business actually needs — entirely outside IFS Cloud. The writing, if there is any, happens in an email system, a Teams channel or a ticketing tool, never back into the ERP. IFS Cloud stays exactly as clean as it was before you started watching it.
Put side by side, the two approaches do not just differ in risk profile. They differ in how much of your time they quietly consume, upgrade after upgrade.
| Writeback integration | Read-only monitoring | |
|---|---|---|
| Upgrade exposure | Every write path retested each release | Nothing to retest — the projection is standard |
| Permissions needed | Write access to core business objects | Read-only, scoped to a handful of projections |
| What breaks on R1/R2 | Custom write logic against changed rules | Nothing — you consume the same data IFS ships |
| Audit surface | Every write is a change someone must trace | None — the tool leaves no trace in the system |
| Worst-case failure | Silent data corruption or a blocked release | A stale read, never a broken transaction |
None of this means writeback integrations are always wrong. Some processes genuinely need to change a state in IFS Cloud. But a monitoring and alerting layer is not one of them, and treating it as read-only from day one removes an entire category of upgrade risk before it can accumulate.
Building it read-only from the start is the easy part. Rolling it out without creating a second problem — an integration account with more access than it needs — takes a little more discipline.
Because the account only ever reads, there is nothing here for the IFS Extensibility Framework to protect you from — no core modification, no custom object, no write path for the next release to break. It stays update-safe by construction, not by discipline you have to remember to apply.
No. It uses the standard OData projections IFS Cloud already exposes, accessed through a dedicated integration account with a read-only permission set. There is nothing to build inside IFS Cloud itself.
Whatever the permission set grants and nothing more. Most monitoring layers only need order state, confirmation status, delivery dates and stock levels — a small, well-defined slice of the data IFS Cloud already holds.
Yes. The read triggers the alert; the action — an email, a Teams message, a ticket — happens outside IFS Cloud. Nothing is written back into the ERP, so the action never becomes a customisation to maintain.
Yes, directly. A read-only integration installs nothing in the database, modifies no core object and leaves no trace for an upgrade to break. It is one of the simplest ways to add monitoring without touching your Clean Core position.
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 monitoring layer already writes back into IFS Cloud, a read-only rebuild is usually smaller than it sounds. On a 30-minute call I’ll map what your alerts actually need to read, and what can come out of the write path entirely — fixed price, dry-run before anything changes.
Independent IFS Cloud practice · Data Integrity
Key takeaways
A purchase order sits unconfirmed for five days. The buyer chases it, the supplier confirms by phone, and the buyer moves on to the next fire. In IFS, nothing changes: the order stays in Released state, because a phone call is not a system update. The goods ship. The goods arrive. The receipt posts against the order. Three months later, someone runs the standing report on unconfirmed purchase orders, and this one is still on the list. Someone spends half a day chasing a shipment that already happened — pulls up the order, calls the supplier, and is told, reasonably, “we confirmed that months ago.” Both sides are right, and neither side’s data agrees with the other. This is not a purchasing failure. It is a reconciliation failure — a gap between what happened in the real world and what IFS was told happened — and it is far more common, and far more corrosive, than any single missed order.
Confirmation happens wherever it is fastest, and the phone is faster than the system. A buyer chasing a supplier wants an answer, not a data-entry task, so the call closes the operational question and stops there. Updating IFS afterwards is a second step with no visible reward — the order already feels handled, so it drops to the bottom of the list and, more often than anyone admits, never gets done at all.
The gap widens because nothing forces it shut. IFS has no way to know a phone call happened unless someone tells it, and there is no prompt, no reminder, no consequence for leaving the status untouched. The order simply sits, technically wrong, looking correct to everyone except the one report that eventually flags it — usually long after the context that would have explained it is gone.
The half day spent chasing a shipment that already arrived is real money, but it is the smallest part of the bill. The larger cost builds quietly over months, as a pattern rather than a single incident:
An exception that is not really an exception is worse than a missed one — it trains people to stop reading the next alert, including the one that matters.
The evidence that a status is stale is usually already sitting in IFS, just not joined together. A purchase order flagged as unconfirmed that also has a receipt posted against it, a goods issue recorded downstream, or an invoice already matched, is not an open question — it is a data mismatch wearing an exception’s clothes. The report only has to compare the two facts to know the difference.
Building that cross-check turns a noisy list into a short, credible one: orders that are genuinely unconfirmed and show no downstream activity go to the top as real risk. Orders that are unconfirmed on paper but already moving get quietly closed out or flagged for a status correction instead of a phone call. The report stops crying wolf, and the people reading it start trusting it again.
Left alone, closing the gap between a verbal confirmation and the system record depends entirely on someone remembering to go back and fix it. A systematic rule checks the two facts against each other every time, without waiting for a report to be run or a person to notice.
| Manual | Systematic | |
|---|---|---|
| Detects the mismatch | Only if someone happens to notice | Every time the two data points disagree |
| Runs | When the report is remembered | Continuously, on schedule |
| Owner | Whoever answers the phone | The rule, by definition |
| Audit trail | None | Logged reconciliation event |
| Fails when | Busy, new starter, unaware | Never sleeps |
The point is not to remove the phone call — a verbal confirmation is often the fastest, most reasonable way to resolve a stuck order. The point is to stop treating the system update as optional. Once the two facts are checked automatically, the phone call and the record agree within minutes instead of quarters.
Start narrow, prove it on real orders, and only then widen the scope.
Because the whole thing is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — it is update-safe. There is no core modification for the next release to break, so you avoid the upgrade tax entirely.
It is a record flagged by a report or rule as a problem — such as an unconfirmed purchase order — when the underlying situation was already resolved outside the system, typically by a phone call or email that never made it back into IFS as a status update.
Instructions get followed on the calm days and dropped on the busy ones, which is exactly when the gap opens. A reconciliation rule works regardless of how busy the buyer is, because it checks the evidence rather than relying on someone remembering an extra step.
Not if the signal is strict. The rule only closes the gap when there is clear downstream evidence — a posted receipt or a matched invoice — not on a guess. Anything short of that evidence is flagged for a person, not silently changed.
Yes. The reconciliation 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 exception reports are quietly losing credibility, a dry-run reconciliation will show you how many of the “open” items are already closed in reality. On a 30-minute call I’ll map the signal to your data — fixed price, dry-run before anything changes.
Independent IFS Cloud practice · Supply Chain
Key takeaways
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.
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.
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.
Three different states, the same failure mode: the record is technically correct and operationally wrong.
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.
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.
Treat this as three related automations built the same way, not one big project. Start with the state that has the least existing coverage.
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.
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.
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.
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.
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.
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.
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.
Calculate your return on investment