The business impact of implementing IFS Cloud ERP

Key takeaways

• Silent failure is not a platform bug. It is custom code that still compiles and still executes correctly against a data shape or trigger sequence that no longer matches what the release actually produces.
• Four concrete patterns account for most cases: renamed enum/status values, resequenced Custom Event trigger points, a wrapper that swallows a new parameter, and a broad exception handler that was already hiding errors before the upgrade.
• A worked example: a Custom Event gating over-budget purchase orders on a status string comparison silently stops firing the moment the release renames the underlying state value, with zero errors raised anywhere.
• The diagnostic sequence starts from outcome volume, not the code: compare how often the custom logic's side effect actually occurred before and after the release, before reading a single line of PL/SQL.
• Detection has to be built proactively - outcome logging and a scheduled canary test - because nobody notices a rule that went quiet on its own; that is the entire nature of the failure mode.

An error is loud because something the platform expects did not happen: a mandatory field was null, a constraint was violated, a procedure call did not resolve. Silent failure is different in kind, not just in visibility. It happens when the platform changes something the custom logic depended on, but not in a way that produces an exception: a status value gets relabeled, a trigger point’s position in the transaction sequence shifts, a procedure gains an optional parameter that a hand-built wrapper never learns to pass. The custom code keeps compiling and keeps running. It simply stops matching anything, or starts running at a point where the data it needs is not populated yet, and every code path it takes from there is technically valid and semantically wrong.

This is why it clusters around R1/R2 releases specifically rather than happening at random. A release is exactly the event that changes enum labels, reorders standard business logic, and adds parameters to existing procedures, all while keeping the outer interface backward-compatible enough that nothing refuses to compile. Extensions built strictly inside the Extensibility Framework, against published Custom Event trigger points and Custom Fields, are far less exposed to this because the framework’s contract is explicitly versioned. Extensions that reach past that boundary into internal package logic or hard-coded status strings inherit every internal change the release makes, with no compatibility guarantee attached to any of it.

The fourth pattern deserves its own emphasis, because it is not really an upgrade problem at all, it is a pre-existing landmine the upgrade steps on. A handler written to catch one known, harmless exception and continue is functionally identical to a handler that catches every possible exception and continues, from the platform’s point of view. The moment the release introduces any new failure mode into that code path, whether related to the original edge case or not, it disappears into the same catch block with the same silent continuation.

Illustrative scenario, not a claim about a specific real trigger point or status value [VERIFY against your own customisation]. A Custom Event fires on purchase order line approval, checks whether the line’s value exceeds a budget threshold, and if a status field on the order reads a particular value, blocks the approval and routes it to a manager instead:

Nobody notices for months, because the failure produces exactly the same visible outcome as a correctly functioning system with no over-budget lines that quarter: nothing shows up in the manager’s queue. The gap is only found when someone reconciles actual spend against the budget threshold independently of the control that was supposed to be enforcing it, which is precisely the kind of check that should not have to be the detection mechanism in the first place.

Every one of the four patterns above is detectable, in principle, by reading the diff between release versions. What actually makes it invisible in practice is a specific pre-existing habit: custom logic that produces no output, no log entry and no counter increment on either the success or the no-action path. If the budget-gate event in the example above had written one row to a log table every time it evaluated, regardless of outcome, someone would have noticed the “blocked” count drop to zero the week after go-live. Because it wrote nothing on the no-action path, and the no-action path is indistinguishable from correct behaviour when there is genuinely nothing to block, there was no signal to notice at all.

The trap compounds when combined with the broad exception handler pattern: code that swallows errors and logs nothing on any path is, by construction, a black box that only a human explicitly reconciling outcomes against expectation will ever catch. That reconciliation should not be the primary control. It should be the last line of defence behind logging that was designed in from the start.

When a client says “this used to work and I think it stopped,” this is the sequence, deliberately starting from outcome data rather than code, because reading the custom logic first wastes time on code that may be entirely correct against a world that no longer exists:

1. Compare outcome volume before and after the release - how often did the custom logic’s visible side effect (a block, a routed approval, a flagged record) occur per week, before versus after. A sudden drop to zero, or a suspicious flatline, is the first real signal.
2. Search the custom code for broad exception handlers - any WHEN OTHERS or equivalent catch-all, and temporarily narrow it or add logging inside it during diagnosis, since it may already be hiding the actual failure.
3. Diff the Custom Event’s trigger point definition and firing order against the previous release’s standard logic around the same point, checking specifically whether anything the custom logic reads is now populated later in the sequence than it used to be.
4. Check every hard-coded literal the custom logic compares against - status strings, enum values, code identifiers - against the current release’s actual values for that field, not the values documented when the customisation was originally built.
5. Re-run a known test transaction with explicit logging added at each branch, not just at entry and exit, so you can see exactly which comparison evaluates differently than expected rather than only confirming that the end-to-end outcome is wrong.
6. Check any wrapped standard procedure calls for parameters added since the customisation was built, comparing the wrapper’s call signature against the current procedure’s full signature, not just confirming it still compiles.

The diagnostic sequence above finds a failure after someone has already noticed something feels wrong. The better position is designing custom logic so a silent failure cannot stay silent for long:

1. Log outcome on every path, not only the action path - a row written on “evaluated, no action taken” is what makes a volume drop visible instead of indistinguishable from genuinely quiet weeks.
2. Replace broad exception handlers with narrow, named ones, and log whatever they catch - a handler that only ever catches the one condition it was written for should say so explicitly in the log, so a new error class arriving through the same block is visible as a new event, not silence.
3. Add a scheduled canary test - a Custom Event or Workflow that runs a known scenario against a test record on a fixed schedule and checks that the expected side effect actually occurred, alerting if it did not. This catches the exact failure mode above without waiting for real transaction volume to expose it.
4. Re-test every custom extension against each release’s upgrade sandbox before go-live, specifically re-running the canary scenarios rather than only checking the code still compiles - compiling cleanly and behaving correctly are two different questions, and the gap between them is exactly what this whole failure mode lives in.
5. Keep the customisation footprint inside the Extensibility Framework’s published contracts wherever possible, because that is the boundary IFS actually version-manages; every step taken past it into internal logic is a step outside anyone’s compatibility guarantee.

Clients running this kind of structured, canary-backed regression approach across their customisation footprint report up to 60% less regression testing effort per release, because the testing is targeted at outcomes known to matter rather than a full manual click-through of every custom screen and rule after each upgrade.

Dariusz Myśliwiec - 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.

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 cycle count in IFS Cloud does not compare a physical count to “the current on-hand balance.” It compares a physical count, entered at a specific time, to whatever the system balance was for that part, at that inventory location, at the moment the count line was captured. That distinction matters because the on-hand balance is not static between the moment a counter writes a quantity on a handheld and the moment that count result is confirmed and posted. Every receipt, pick, issue, and internal move that touches the same location in that window changes the balance the system is holding, and the variance calculation has to decide, implicitly or explicitly, whether those changes belong to the counted balance or not.

The count itself typically runs through three stages: a count order or count point is generated for a location or a part, a count result is entered against it, and a variance is calculated as counted quantity minus expected quantity at the time of comparison. A variance inside tolerance is usually auto-approved as a routine adjustment; one outside tolerance routes to review and posts, once approved, at standard or average cost depending on the part’s costing method. The adjustment transaction itself is unremarkable; the part that deserves scrutiny is what “expected quantity at the time of comparison” actually included, and whether it included transactions still in flight.

The simplest variance tolerance configuration is a single flat percentage, such as five percent of counted quantity, applied uniformly across every part. That setting is defensible for exactly one slice of the inventory and wrong for every other slice, because tolerance needs to track two independent variables that a flat percentage ignores: unit value and transaction velocity.

• High-value, low-velocity parts. A five percent tolerance on a part costing several thousand currency units per unit can mask a real, financially material loss inside a percentage band nobody reviews, because the count rarely moves and each unit is expensive enough that even a small percentage represents a large absolute value.
• Low-value, high-velocity parts. The same five percent tolerance on a fast-moving fastener or consumable with hundreds of transactions a week will flag routine noise constantly, because normal picking, rounding on unit-of-measure conversions, and legitimate scrap all produce swings well inside what should be an acceptable range for a part that costs almost nothing per unit.
• ABC-classified tolerance. A working configuration ties tolerance to the part’s ABC or value classification and, ideally, to its transaction count over the review period, tightening the absolute-value tolerance for A-class parts even as the percentage tolerance loosens for C-class ones, rather than treating every part as equally likely to be equally wrong by the same proportion.

The practical failure mode of a flat threshold is not that it generates too many exceptions or too few in aggregate. It is that it generates the wrong exceptions: it buries the loss that matters financially inside a percentage that looks acceptable, and it drowns the review team in noise from parts whose variance was never worth anyone’s time to investigate.

A true variance means the physical stock genuinely differs from what the system believes is there: a real discrepancy caused by unrecorded scrap, theft, a picking error that issued the wrong part or quantity, or a receipt that was put away against the wrong location. A timing variance means the physical count and the system balance disagree only because a transaction that affects one of them had not yet posted, or had posted but not yet been reflected in the balance the count was compared against, at the instant the count was captured. Both produce an identical-looking variance line: a quantity, a value, a part, a location. The distinction only becomes visible when the count result is joined against the transaction log for the same part and location, filtered to the window around the count.

The practical rule of thumb worth internalising: a variance explained by a transaction dated within a short window either side of the count capture time is a timing variance and should be excluded from the “needs investigation” population entirely, not merely deprioritised. A variance with no transactional explanation in that window is a genuine candidate for physical investigation, and it is the only category worth sending a supervisor to walk the aisle for.

The naive reconciliation query compares counted quantity to on-hand quantity at the moment the report runs and flags anything outside a flat tolerance. A working version classifies each variance before it ever reaches a human, illustrated here as generic, PL/SQL-flavoured pseudocode using aliases rather than an assertion about a specific release’s exact schema:

The transaction-window join is the piece worth defending if anyone proposes simplifying this rule. Without it, every count taken in an active location generates variance noise proportional to how busy that location is, which correlates with count scheduling, not with actual inventory accuracy.

A “hot count” is a count taken against a location that remains transactable, receiving and issuing normally, while the count is in progress. It manufactures variance directly, because ordinary receiving and picking activity during the count window changes the balance the count is compared against, and it is a scheduling decision rather than a system misconfiguration, which is why it survives round after round of tolerance tuning without ever being fixed. Freezing the location until the count is confirmed eliminates the problem structurally; loosening the tolerance to absorb the noise does not, it just hides real variance inside a wider band.

A second recurring misconfiguration is a unit-of-measure conversion factor that is wrong or missing between the stocking unit and the counting unit. A part counted in individual pieces but stocked and issued in a case quantity will show a variance that looks like shrinkage but is actually an arithmetic mismatch, and it will reproduce identically at every future count of that part until the conversion factor itself is corrected, not the count.

A third trap sits with lot- and serial-tracked parts. Quantity can be zero at the part level while individual lots are wrong: one lot short, another of the same part over by the same amount, because a picker took stock from the wrong lot without recording it. A rule that only checks part-level quantity will miss this; it needs lot or serial granularity to catch a misallocation that nets to zero but is a real traceability failure.

1. Capture the exact timestamp on every count line, not just the date. Without a precise capture time, the timing-window join in section 4 cannot be built; a date-only field forces a full-day window that swallows too much transaction noise.
2. Pull the raw variance population before applying any tolerance. Look at every counted line against its snapshot balance first, unfiltered, and confirm the capture timestamp is actually recorded reliably.
3. Join against the transaction log inside a defined window. Start conservatively, a window of a few hours either side of capture, and widen it only if evidence shows genuinely delayed postings are still slipping through as false true-variances.
4. Reclassify tolerance by ABC class and transaction velocity. Replace the flat threshold with the per-class rule in section 2 before drawing any conclusions about which parts are “accurate.”
5. Check for structural repeaters. Run the same-direction, consecutive-cycle pattern from section 3 across the last several cycles; a part that shows up repeatedly is a UoM or BOM issue, not a counting problem, and fixing the count process will not resolve it.
6. Address hot counts as a process fix, not a tolerance fix. If a meaningful share of variance correlates with locations that stayed transactable during the count, freeze those locations for future cycles before tuning anything else.
7. Wire the surviving true-variance population to a Custom Event. Once timing noise and structural repeaters are filtered out, what remains is small enough to route directly to a supervisor, built inside the Extensibility Framework against the standard adjustment and count result entities.

Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.

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 confirmation is a moment: at that point the order said one thing and the customer was told it. After that the order is a live record that many hands can touch. Planning reschedules a line to match supply. A rep adjusts a quantity after a call. A part is substituted. Each edit is a reasonable thing to do, and IFS Cloud is right to allow it. None of these edits carries an obligation to go back to the customer, because the system does not treat the edit as breaking a promise. It just treats it as an update.

So the order and the promise drift apart. The record is current and correct. The customer’s understanding is current and correct as of the confirmation. Both are internally consistent, and neither knows the other has moved. Nothing sits between them asking whether this particular change is one the customer needs to hear about.

The silent change is not a broken process. It is a normal edit that happened to alter a promise, with no step that separates the edits worth a phone call from the ones that do not matter.

Amending a confirmed order is routine. The value is in separating the harmless edits from the ones that changed what the customer is expecting.

The first row is the quiet one. The date moved for a good internal reason, the order is accurate, and the customer is still planning around the date you confirmed. A rep looking at the order sees a valid delivery date and no reason to act. Compare the confirmed date to the current one, and the broken promise is right there to be fixed with a call.

The confirmed values and the current line values are both available through standard OData projections, so they can be read without touching a record. Detection compares what was confirmed to what the order says now and looks for two things:

1. Key terms that changed after confirmation - where the date, quantity or item on a confirmed line no longer matches what was promised, so the orders that moved under their confirmation surface as a short list.
2. Whether the customer was told - flagging the changed orders so the account owner can decide which need a call, rather than assuming an edit and a communication are the same event.

Because it is a read-only monitoring pattern, it runs beside sales and writes nothing back to IFS. It adds no object inside the client system, and a standard R1 or R2 release does not touch it, because it only reads standard projections. It hands the rep a short list of confirmed orders that changed, and the call on which customer needs to hear about it stays with the person who owns the account.

• Start with your key accounts - a silently changed promise costs the most where the relationship matters most, so watch those first.
• Dry-run first - log which changed orders would have been flagged across a full period before a single alert reaches a rep.
• Two lenses - one for dates that slipped after confirmation, one for quantities or items that changed.
• Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.

See the SCM Automation Pack Book a 30-minute fit call

Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.

Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.

When a promise date is calculated, it reflects a picture of the world at that instant: what is on hand, what is on order, what capacity is free, and how long each step takes. Give the same order to the system a week later and the picture has changed. A supplier moved a date. A shared component was consumed by another order. A work centre filled up. None of that is unusual. It is what a live supply chain does.

The promise, though, was captured at a single moment and does not automatically re-plan itself as the world moves. It sits on the order as the number the customer was told. High fidelity means the promise and the plan stay close enough that the date is still real. Low fidelity means the promise is a fossil: accurate the day it was made, wrong ever since, and nobody looked.

These two questions get confused because both end in a worried planner. They are not the same check, and they fail in different ways.

An order can pass coverage and still miss its promise. The parts are coming. They are just coming after the date you quoted. That is the gap this article is about, and it is the one that turns into a late delivery without anyone having made an obvious mistake.

Promised dates on sales lines and the planned supply behind them are readable through standard OData projections, without touching a record. Detection is a matter of comparing the two on a daily cycle, so the drift is caught while there is still room to act:

1. Promises now later than their supply - lines where the planned arrival of what the order needs has moved past the promised delivery date, so the date is no longer achievable on current supply.
2. Promises that drifted since they were made - a date that was fine at entry but whose underlying supply has slipped points at a specific change worth chasing, rather than a vague worry about the whole order book.
3. Promises resting on supply that itself is at risk - a date built on an order or component that is already flagged elsewhere inherits that risk, so it is worth surfacing before it becomes a surprise.

This is a read-only pattern. It runs beside IFS, writes nothing back, and does not re-quote the customer or move the promise for you. It surfaces the orders whose date and plan have come apart and lets a planner decide whether to expedite, re-plan, or call the customer early, which is a far better conversation than an apology after the fact.

• Start with your key accounts - watch the promises where a missed date costs the most in trust first.
• Dry-run before anyone acts - log which promises would have been flagged for a full window before a planner is asked to chase them.
• Flag the drift, not just the state - a promise that slipped since yesterday points at a recent change and is easier to trace than one drifting for weeks.
• Read-only by design - standard OData reads only, nothing written back to IFS and no new object installed in the client system.

See the SCM Automation Pack Book a 30-minute fit call

Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.

Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.