---
title: "Blog"
description: "Understand CRIMS in IFS Cloud. We detail how Configurations, Reports, Interfaces, Modifications, and Security affect your ERP lifecycle and update speed."
---

# Blog

## Expiring Customer Price Agreements in IFS Cloud

Independent IFS Cloud practice · Sales

 
## The price that expires while orders keep asking for it

 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**

 
- A sales price list or customer agreement carries a valid-to date. Once it passes, new lines stop pricing from it, and the change happens on its own.
- Nothing warns you the date is coming. The agreement works perfectly until it expires, so there is no symptom until an order is already mispriced.
- This is not a [line with no price](https://www.ifs-erp.com/blog/sales-order-missing-price-ifs-cloud), where nothing prices at all. Here a price applies, just not the one anyone agreed.
- It is also not an [off-agreement price](https://www.ifs-erp.com/blog/sales-order-off-agreement-price-ifs-cloud) on a live agreement. This is the agreement itself running out of validity.
- Validity dates on price lists and agreements are readable through standard OData, so a read-only monitor can list every one that expires soon, before the orders it prices go wrong.

  ## 1.A validity date is a switch nobody watches

 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](https://www.ifs-erp.com/blog/sales-order-below-cost-margin-ifs-cloud) if the fallback price is lower than the deal you meant to honour.

  ## 2.How the expiry catches you out

 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.

  ## 3.Detecting the expiry before it prices an order

 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:

 
1. **Agreements and lists expiring within a chosen window** - anything whose valid-to date falls in the next few weeks, so a renewal can happen before the switch flips.
2. **Expired agreements with recent order activity** - a lapsed agreement on an account that is still ordering is the one most likely to be quietly mispricing right now.
3. **Customers who lost their only agreement** - accounts that were priced from an agreement and now have none in force, so their lines fall to base or list price unnoticed.

 Because this is a [read-only monitoring pattern](https://www.ifs-erp.com/blog/read-only-odata-monitoring-ifs-cloud), 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.

  ## 4.Rolling it out without noise

 - **Look ahead, not behind** - a warning weeks before the valid-to date is worth more than a report of orders already mispriced, so lead with what is about to expire.
- **Dry-run the calendar** - see every agreement expiring this quarter before any of them do, so renewals are planned, not scrambled.
- **Rank by active accounts** - an expiring agreement on a customer who orders weekly matters more than one on a dormant account, so sort by recent activity.
- **Read-only by design** - standard OData reads only, nothing extended or repriced back in IFS and no new object installed in the client system.

 [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack) [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)

  ## 5.Frequently asked questions

 If the order still gets a price, what is the problem? 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.

   How is this different from an order priced off the agreement? 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.

   Should the monitor extend or renew the agreement automatically? 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.

   Can it tell which expiries actually matter? 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.

  ## 6.About the author

 **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.

  ## See which agreements expire next

 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.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/customer-price-agreement-expiry-ifs-cloud.md)

## Process Drift After Go-Live in IFS Cloud

Independent IFS Cloud practice · Supply Chain

 
## What your ERP consultant did not tell you: the process will drift

 **Key takeaways**

 
- Go-live delivers a documented, trained, mapped process. But the system will drift from it, quietly, starting the week the consultant leaves.
- Drift is not malicious: a mandatory field goes optional because someone complained, a check gets skipped because it slowed things down, a weekly report becomes monthly.
- **Process drift in IFS Cloud** means the system stays correct while the behaviour around it slowly changes. The gap between designed process and evolved process is where exceptions live.
- Closing the gap needs a periodic drift review, not a bigger manual, backed by the same exception-routing mechanism used across every process on this site.

 Your IFS implementation went live. The consultant handed over the documentation. The key users were trained. The processes were mapped, signed off, and filed. What nobody told you at the time is that none of it stays still. A field that was mandatory becomes optional because someone complained. A check that was part of the workflow gets skipped because it slowed things down. A report that was reviewed weekly gets reviewed monthly because the person who ran it changed roles. None of this is malicious. It is how organisations work. Two years after go-live, your IFS instance is not running the process you designed. It is running the process your team evolved, one small local decision at a time. The question is not whether your implementation was good. It was. The question is whether anyone is still watching the gap between the two.

  ## 1.Why does every implementation drift?

 Drift has no single cause and no single villain. It is a hundred small local decisions, each individually reasonable at the moment it was made. A planner finds a mandatory field slows down a Friday rush and asks IT to relax it “for now”. A supervisor covering for a sick colleague skips a review step because nobody explained why it mattered. A manager who inherited a weekly report has no idea it used to catch something specific, so cutting its frequency in half feels harmless. Each decision, taken alone, looks like a minor efficiency gain.

 What none of these people see is the sum. The documentation from go-live still describes the original design; nobody updates it as the small decisions accumulate, because updating documentation is nobody’s job either. Two years later the gap between the written process and the practised one is wide enough to hide real exceptions inside it. Nobody signed off on that gap. It simply arrived.

  ## 2.What does process drift actually cost?

 The cost is not a single failure. It is the slow widening of the space where a real problem can hide behind a habit that looks normal because everyone got used to it.

 
- **Mandatory becomes optional.** A field relaxed to save five minutes once now lets bad data through every day, with nobody remembering why it mattered.
- **A check quietly skipped.** The review step designed to catch a specific class of error stops running. That class of error stops being caught, and nobody hears about it.
- **Cadence stretched thin.** A weekly report that becomes monthly means a problem that used to surface in days now sits for weeks before anyone sees it.
- **Role changes erase context.** The person who understood why a step existed moves on, and their replacement inherits the task without the reason behind it.

 The system stays correct. The behaviour around it drifts. Nobody notices, because nothing that drifted was ever labelled as important in the first place.

  ## 3.How do you see drift in IFS Cloud?

 Drift leaves a trail, because the original design and today’s behaviour are both visible in IFS Cloud. You just have to compare them instead of only reading one. Mandatory-field settings, approval workflow definitions and role permissions describe what was designed. Actual transaction data describes what is practised: the percentage of orders with an optional field left blank, the percentage of approvals that skipped a step that still exists on paper, the interval between runs of a report that used to be weekly.

 Run that comparison once and it is interesting. Run it as a scheduled review and it becomes a system of record for the gap itself, which is what the exercise described in the [upgrade readiness checklist](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist) already assumes you can produce before touching a release. The same evidence underpins a [segregation-of-duties review](https://www.ifs-erp.com/blog/rbac-segregation-of-duties-ifs-cloud), because role drift is one of the most common forms this pattern takes.

  ## 4.Occasional audit versus continuous drift monitoring

 Most organisations discover drift the hard way: an audit, an incident, a new hire asking why the process on paper does not match what they were shown. A continuous comparison catches the same gap while it is still small and cheap to close.

 
|   | Occasional audit | Continuous monitoring |
| --- | --- | --- |
| Runs when | Once every few years, if at all | Continuously, against live data |
| Coverage | Whatever the auditor thought to check | Every mandatory field, check and cadence |
| Owner | An external reviewer, briefly | Process owner, by rule |
| Audit trail | A report nobody re-reads | A trend, tracked over time |
| Fails when | The years between audits | Never sleeps |

 The value is not in catching one drifted field. It is in seeing the trend early enough that correcting it is a conversation, not a project.

  ## 5.How do you close the gap safely?

 You are not rebuilding the implementation. You are re-establishing the habit of looking at the gap.

 
1. **Pull the original design.** Recover the go-live documentation for mandatory fields, approval steps and report cadence. It is the baseline everything else is compared against.
2. **Run the comparison once.** Measure today’s actual data against that baseline. Expect surprises; drift is rarely where anyone expects.
3. **Rank by exposure, not by age.** A recently drifted approval step on a high-value process outranks a decade-old cosmetic change to a low-risk field.
4. **Fix the highest-exposure gaps first.** Re-tighten, re-train, or formally accept the change. Whichever you choose, make it a decision, not a default.
5. **Schedule the next comparison.** Drift is continuous, so the review has to be too; put a date on the calendar before you close this one out.

 The comparison itself is built inside the IFS Extensibility Framework, using standard Custom Events, Workflows and PL/SQL, so tracking it does not require touching the core configuration you are trying to protect.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What is process drift in IFS Cloud? It is the gradual gap that opens between the process designed at go-live and the process your team actually practises months or years later: mandatory fields relaxed, checks skipped, reporting cadence stretched, all through small, individually reasonable decisions.

   Does drift mean the original implementation was wrong? No. Drift happens to good implementations as much as mediocre ones, because it is a property of how organisations behave over time, not a defect in the original design. The question worth asking is not whether it was good, but whether anyone is still watching the gap.

   How often should we check for drift? A first comparison against the original go-live baseline is worth doing regardless of age. After that, a scheduled review (commonly ahead of an upgrade or a segregation-of-duties audit) keeps the gap from growing unnoticed between checks.

   Is this update-safe? Yes. The comparison and any resulting alerts are built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework. Nothing touches the core, so nothing here is at risk from the next R1/R2 release.

  ## 7.About the author

 **Dariusz Myśliwiec** has spent 25+ years in ERP and supply chain, 17+ of them on IFS (Apps 7.5-10 and IFS Cloud). He is an IFS Certified Associate Consultant and PRINCE2® 7 certified. His practice is based in Krakow and works remotely across Europe and beyond. You talk to the consultant who builds it, not a sales layer.

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

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

  ## Find out how far your process has drifted

 Most teams have never compared today’s data against the process they designed at go-live. A short baseline comparison will show you exactly where the gap is widest. On a 30-minute call I’ll walk through what that comparison looks like for your instance. Fixed price, no obligation.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/process-drift-after-go-live-ifs-cloud.md)

## Purchase Order Exception States You Cannot Ignore

Independent IFS Cloud practice · Supply Chain

 
## Three order states that should never sit unquestioned. One of them, nobody owns.

 **Key takeaways**

 
- Released without confirmation, arrived without receipt, and partly received for more than a week look identical on a summary report. The order exists, the line is there, nothing is red.
- None of the three is a system error. IFS Cloud recorded each state correctly; the failure is that nobody was asked to look.
- The first two already have dedicated fixes on this site. The third, a partial receipt stuck mid-transaction, is the one most practices have never assigned an owner.
- The same mechanism closes all three: a Custom Event that asks one named person one specific question after a set number of days.

 Released without confirmation. Arrived without receipt. Partly received for more than a week. Pull up a summary report and none of these look like a problem. The purchase order exists. The line is there. The status field is a reasonable colour. But each of these three states shares the same property: it is a decision nobody has made yet, and every day it sits unmade, the eventual cost of making it goes up. Released without confirmation means you are scheduling production around a supplier promise you have not actually received. Arrived without receipt means goods are sitting on your dock while the system insists they do not exist yet. Partly received for a week means somebody started closing out a delivery, got pulled onto something louder, and never came back to finish it. Two of these three already have a dedicated fix on this site: unconfirmed orders and goods received without an invoice. This article treats all three as one pattern, and gives the third, the stuck partial receipt, the attention it has not had yet.

  ## 1.Why do these states pile up unquestioned?

 None of the three states is a system error. IFS Cloud recorded exactly what happened: an order was released, a receipt was partially posted, a delivery arrived. The record is correct. What is missing is a second step nobody assigned to anyone. Somebody was supposed to come back and check whether the state was still expected, and nobody did. Confirmation is treated as the supplier’s job. Receipt posting is treated as finished the moment the first click happens. Ownership stops exactly at the point where the interesting question begins.

 The three states also share a trigger for how they start: an interruption. A buyer moves on to the next order before confirmation clears the inbox. A warehouse operator gets called away mid-receipt with a partial quantity already keyed in. A goods-in team scans a delivery against a PO that nobody has flagged as arrived. None of these interruptions is a mistake by itself. The mistake is a workflow with no mechanism to reopen the question later. Once the interruption happens, the state looks stable. It can sit exactly where it was left for weeks.

  ## 2.What does an unquestioned state actually cost?

 The three states convert into cost differently, but the shape is the same: a small unmade decision compounds quietly until it becomes expensive to fix, then surfaces as a line item that never mentions its own cause.

 
- **Production planned on a promise.** A release awaiting confirmation is treated as reliable in the plan; if it slips, the plan slips with it, discovered only when the line stops.
- **Inventory the system cannot see.** Goods on the dock without a posted receipt do not exist for planning, so the system happily reorders stock that is already sitting fifty metres away.
- **A remainder stuck mid-transaction.** A partial receipt left open for a week blocks the invoice match and confuses anyone checking coverage, and nobody remembers why it is still open.
- **A cost with no name on it.** None of this ever appears on a P&L as “unconfirmed PO” or “stuck partial receipt”. It shows up as expediting, as a duplicate order, as a finance query nobody can answer quickly.

 Three different states, the same failure mode: the record is technically correct and operationally wrong.

  ## 3.How do you see them in IFS Cloud?

 All three states are visible with a filter you can build today, because IFS Cloud already tracks the fields that matter: order status, confirmation date, receipt date, and received quantity against ordered quantity. Released orders past a threshold with no confirmation, and goods receipts posted without a matching invoice past a threshold, are both covered start to finish in the dedicated articles on [unconfirmed purchase orders](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs) and [goods received without an invoice](https://www.ifs-erp.com/blog/goods-received-not-invoiced-ifs).

 The partial receipt case deserves its own explanation, because it hides differently. A purchase order line with received quantity greater than zero and less than ordered quantity, where the last receipt posted more than, say, five working days ago, is your working definition of stuck. It will not appear on an exceptions view built around “open” versus “closed”, because a partially received line is neither. It is technically still open, technically has activity against it, and technically nobody’s job to close. Filtering purchase order lines on that exact combination (received quantity between zero and ordered quantity, last receipt date older than the threshold) is the query most practices have simply never written.

  ## 4.Manual re-check versus systematic routing

 Whichever of the three states you tackle first, the comparison is the same. A manual re-check depends on someone remembering to reopen a record that already looks finished. A systematic rule watches the field combination continuously and routes the exception to a named owner without anyone asking.

 
|   | Manual re-check | Systematic routing |
| --- | --- | --- |
| Runs when | Someone happens to reopen the order | Continuously, on a schedule |
| Coverage | Whichever state someone remembers | All three states, every order, every site |
| Owner | Unclear across all three | Named per state, by rule |
| Audit trail | None | Logged flag or alert per order |
| Fails when | Busy weeks, handovers, headcount changes | Never sleeps |

 The comparison holds because the underlying pattern is identical in every case: a record that is technically active but has had no human attention past a reasonable age. Once you have built the rule for one state, extending it to the next two is configuration, not a new project.

  ## 5.How do you roll this out safely?

 Treat this as three related automations built the same way, not one big project. Start with the state that has the least existing coverage.

 
1. **Pick a starting state.** If unconfirmed orders and GRNI already have escalations running, start with partial receipts. It is the one most practices have never assigned to anyone.
2. **Define “stuck”.** Agree the day count and the exact field combination (received quantity, order quantity, last receipt date) that marks a line as needing a decision.
3. **Run in dry-run.** Log what would fire for two weeks before a single alert reaches anyone. The list itself is usually the first surprise.
4. **Assign a named owner.** A flag with no recipient is just another report; route it to the person who can actually close the line.
5. **Extend to the other two states.** Once one automation is trusted, the same Custom Event pattern applies to the other two. Reuse the mechanism, not just the idea.

 This is built inside the IFS Extensibility Framework, using standard Custom Events, Workflows and PL/SQL. None of it touches the core, so it survives the next upgrade instead of becoming part of the *upgrade tax*.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What do these three order states have in common? Each one is recorded correctly by IFS Cloud, and each one still needs a human decision that nobody has been asked to make. None trips an error; all three simply sit, looking normal, until the cost of the eventual decision has grown.

   Why treat a partly received order as an exception if the PO is technically still open? Because “still open” is exactly the state a real exceptions view misses. It is neither closed nor obviously wrong, so it never surfaces on a report built around pass or fail, and it can sit for weeks with nobody noticing.

   Do I need three separate automations to fix this? You need three separate rules, but one mechanism. Each state gets its own Custom Event and threshold; all three reuse the same trigger-and-action pattern, so building the second and third is far faster than the first.

   Is this update-safe? Yes. Every rule described here is a standard Custom Event, Workflow or PL/SQL routine inside the IFS Extensibility Framework. Nothing modifies the core, so nothing here is at risk from the next R1/R2 release.

  ## 7.About the author

 **Dariusz Myśliwiec** has spent 25+ years in ERP and supply chain, 17+ of them on IFS (Apps 7.5-10 and IFS Cloud). He is an IFS Certified Associate Consultant and PRINCE2® 7 certified. His practice is based in Krakow and works remotely across Europe and beyond. You talk to the consultant who builds it, not a sales layer.

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

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

  ## Stop letting the quiet states go unquestioned

 If you suspect these three states are costing you and cannot yet prove it, a two-week dry-run across all three will show you the real numbers. On a 30-minute call I’ll map thresholds and owners to your process: fixed price, dry-run before anything sends.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/order-states-that-need-attention-ifs-cloud.md)

## When IFS Trusts You Too Much — Override Guardrails

Independent IFS Cloud practice · Supply Chain

 
## When IFS trusts you too much: the hidden cost of overrides without guardrails

 **Key takeaways**

 
- IFS will let you receive against an unconfirmed PO, ship without checking supplier delivery, or close an order with open lines - that is flexibility, not a defect.
- Each individual override is reasonable in isolation; combined, they can produce a system state that is internally consistent and operationally wrong.
- This is distinct from RBAC and segregation of duties - that governs *who* can act; this is about the guardrails on the action itself, regardless of who performs it.
- A lightweight validation rule - warn, log or require a reason on the riskiest transactions - keeps the flexibility while removing the silent downstream cost.

 IFS will let you receive goods against a purchase order that was never confirmed. It will let you ship to a customer without checking whether the supplier actually delivered. It will let you close an order that still has open lines. None of this is a flaw - it is flexibility, and IFS assumes the user knows what they are doing. Most of the time, they do. The problem is the edge case: a new warehouse operator receives against the wrong order, a buyer closes a PO to tidy up their dashboard, a planner overrides a lead time because the default looked wrong. Each action is reasonable on its own. Together, they create a system state that is internally consistent and operationally wrong, and it surfaces weeks later, in a different department, as someone else’s problem. Flexibility without guardrails is not freedom. It is deferred cost.

  ## 1.Why does IFS allow this in the first place?

 IFS is built for organisations where the standard path is followed most of the time and the exception path is needed occasionally - a receipt has to be corrected, a stuck order has to be closed to keep reporting clean, a lead time genuinely needs overriding because the master data is wrong. Blocking every one of those actions outright would make the system unusable on the day it is actually needed most, so the platform leaves the door open and trusts the user standing in front of it.

 The risk is not the door being open. It is that nothing records why it was opened, or checks whether the same door has been opened an unusual number of times this month, by the same person, on the same supplier. A single override is a judgement call. A pattern of overrides is a signal that something upstream is broken - and without a guardrail, nothing is watching for the pattern.

  ## 2.What does an unguarded override actually cost?

 The cost rarely lands where the override happened. It travels downstream, then surfaces as someone else’s exception:

 
- **Silent state drift.** A closed order with open lines looks finished to reporting while goods are still owed - nobody chases them because nothing says they are outstanding.
- **Delayed discovery.** The gap surfaces weeks later, when the missing goods are needed, by which point the original context and the person who made the override are both gone.
- **Cross-department blame.** The team that inherits the exception was not the team that created it, so the investigation starts from zero instead of from the cause.
- **Repeat exposure.** Without visibility into how often an override is used, the same edge case keeps recurring, quietly, indefinitely.

 Flexibility without guardrails is not freedom. It is deferred cost, and someone else always ends up paying it.

  ## 3.How do you see it happening in IFS Cloud?

 Every override leaves a trace in IFS whether anyone looks at it or not: a receipt posted against an order with no confirmation, an order closed while lines remain open, a lead time changed from its default value. The data to spot the pattern is already there; it simply is not aggregated anywhere a person would think to look.

 Surfacing it is a matter of counting, not inventing: how many receipts this month landed against unconfirmed orders, how many orders were closed with open lines, by whom, and how that compares to the same period last quarter. A rising count on any one of those is a far better early warning than waiting for the downstream department to notice goods that never showed up.

  ## 4.No guardrail versus a systematic one

 The choice is not between flexibility and control - it is between an override that leaves no trace and one that is allowed, but seen.

 
|   | No guardrail | Systematic |
| --- | --- | --- |
| Prevention | None - the action always succeeds silently | Warn, log, or require a reason on the riskiest cases |
| Visibility | None until the exception surfaces elsewhere | Logged at the moment it happens |
| Pattern detection | Nobody is counting | Volume and repeat-offender trends visible |
| Owner | Whoever inherits the downstream mess | The team closest to the override, by rule |
| Fails when | Always, quietly | Never sleeps |

 Nothing here blocks the legitimate override - the operator can still receive against the unconfirmed PO, the buyer can still close the order. The guardrail adds a reason field, a log entry, or a warning that makes the action visible instead of invisible, so the person doing it thinks for one extra second, and everyone downstream can see it happened.

  ## 5.How do you roll it out safely?

 Guardrails are only useful if they inform rather than obstruct, so start light and add friction only where the data justifies it.

 
1. **Rank the risky actions.** List the overrides most likely to create downstream cost - receiving unconfirmed, closing with open lines, overriding lead times - and pick the top one or two.
2. **Run in observe-only.** Log every occurrence for a few weeks without changing the user experience at all, to see the real volume.
3. **Add a soft check.** Introduce a warning or a required reason, not a hard block, and watch whether it changes behaviour.
4. **Pilot on one team.** Confirm the guardrail catches genuine risk without slowing down legitimate work before widening it.
5. **Review after a month.** Check what was caught, what was ignored, and whether the threshold needs tuning.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Does adding a guardrail block users from doing their job? Not if it is designed as a warning or a logged reason rather than a hard block. The goal is visibility on the riskiest overrides, not preventing legitimate exceptions from being handled the same way they always have been.

   Isn’t this the same as RBAC or segregation of duties? No. RBAC controls who is permitted to perform an action. This is about the action itself - making a risky transaction visible and traceable regardless of which authorised user performs it. The two controls are complementary, not overlapping.

   Which transactions are worth guarding first? Start with overrides that combine high frequency with high downstream cost - receiving against unconfirmed orders and closing orders with open lines are common starting points, but the right list depends on where your own exceptions actually originate.

   Is this update-safe? Yes. The guardrail 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.

  ## 7.About the author

 **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.

  ## Make the risky overrides visible

 If you suspect a handful of reasonable-looking overrides are quietly creating exceptions somewhere downstream, an observe-only week will show you the real volume. On a 30-minute call I’ll map the highest-risk transactions to a lightweight guardrail - fixed price, dry-run before anything changes.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/erp-override-risk-guardrails-ifs-cloud.md)

## The Cost of Looking - Manual Monitoring in IFS Cloud

Independent IFS Cloud practice · Supply Chain

 
## The cost of looking: what manual order monitoring really costs in IFS Cloud

 **Key takeaways**

 
- A buyer spending two hours a day checking order states burns roughly **480 hours a year** - a quarter of a full headcount - on work IFS could finish in seconds.
- The real cost is not the exceptions that get missed; it is the ones caught manually, because every save masks a process that should not need a person watching it.
- It survives because nobody has translated “checking” into hours × people × days, so it never shows up as a line on any budget.
- Converting the routine checks into Custom Event triggers frees the buyer’s time for the decisions a system genuinely cannot make.

 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.

  ## 1.Why does manual monitoring survive so long?

 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.

  ## 2.What does manual monitoring actually cost?

 The bill is not one number, it is several, and none of them appear next to “monitoring” on any report:

 
- **Direct hours.** Two hours a day, every working day, is time that never gets billed to a project or a supplier — it simply is not available for anything else.
- **Opportunity cost.** That time could go to negotiation, supplier development or root-cause work — the parts of the role a system genuinely cannot do.
- **Inconsistent coverage.** A person scanning a screen catches what they have time and attention for that day, not what the business actually needs caught.
- **Invisible headcount.** Across a team of buyers, the same two hours multiplies into a role’s worth of capacity that nobody budgeted for and nobody can reassign.

 The most expensive monitoring is the kind that works. It works well enough that nobody ever asks what it costs to keep running.

  ## 3.How do you quantify it in IFS Cloud?

 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.

  ## 4.Manual scanning versus automated monitoring

 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.

  ## 5.How do you roll it out safely?

 Start with the check that costs the most hours, not the one that feels most urgent.

 
1. **Time the checks.** Ask each buyer what they scan for daily and how long it takes; rank the list by hours, not by drama.
2. **Pick the top check.** Turn the single highest-cost manual scan into a Custom Event and run it in dry-run against real data.
3. **Compare the catch.** Match what the rule flags against what the buyer was catching by hand for a real week.
4. **Go live for one buyer.** Let them stop scanning that one screen and confirm nothing that mattered was missed.
5. **Repeat down the list.** Move to the next highest-cost check once the first is trusted, tracking hours freed as you go.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 How do we estimate the real cost of manual monitoring? 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.

   Will automating this replace the buyer’s role? 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.

   Which checks are worth automating first? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Stop paying for looking

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/cost-of-manual-monitoring-ifs-cloud.md)

## The Exception That Was Not an Exception — IFS Cloud

Independent IFS Cloud practice · Data Integrity

 
## The exception that was not an exception: why stale status data erodes trust in IFS Cloud

 **Key takeaways**

 
- A **false exception in IFS Cloud** is a system state that never caught up with reality — a purchase order confirmed by phone, still sitting in Released state months later.
- The half day spent investigating it is not the real cost; the real cost is people quietly learning not to trust what the system says.
- It happens because closing the loop back into IFS after a verbal confirmation is a chore nobody owns — the phone call feels like the fix.
- A reconciliation rule that compares order state against downstream events — a receipt, an invoice match — catches the mismatch before a report ever raises a false alarm.

 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.

  ## 1.Why does status data fall this far behind reality?

 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.

  ## 2.What does a false exception actually cost?

 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:

 
- **Wasted investigation time.** Every false positive is a buyer or planner stopping real work to re-verify something that was already settled.
- **Repeated false alarms.** A status that never gets corrected keeps re-appearing on the same report, so the same non-problem gets investigated more than once.
- **Eroding trust.** Enough false alarms and people stop believing the report at all — including on the days it is right.
- **Shadow records.** People start keeping their own tracking outside IFS — inboxes, spreadsheets, sticky notes — because that is what they have learned to trust instead.

 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.

  ## 3.How do you tell a real exception from a false one?

 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.

  ## 4.Manual reconciliation versus automatic sync

 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.

  ## 5.How do you roll it out safely?

 Start narrow, prove it on real orders, and only then widen the scope.

 
1. **Agree the signal.** Decide which downstream events count as evidence of confirmation — a receipt, a goods issue, an invoice match — for your business.
2. **Run in dry-run.** Compare order state against those events for a test period and log the mismatches without changing anything yet.
3. **Decide the action.** Choose whether a confirmed mismatch auto-corrects the status or simply flags it for a person to confirm.
4. **Pilot on one buying group.** Watch a full cycle before extending the rule to every site and category.
5. **Review after a month.** Check how many false exceptions it removed, and tune the signal list as new patterns show up.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What is a false exception in IFS Cloud? 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.

   Why not just tell people to update the status after every call? 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.

   Does auto-correcting the status risk hiding a real problem? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Stop training people to ignore the report

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/false-exception-data-trust-ifs-cloud.md)

## The Handover That Never Happened (IFS Cloud)

Independent IFS Cloud practice · Supply Chain

 
## The handover that never happened - what leaves with a departing buyer, and how to keep it

 **Key takeaways**

 
- A **formal handover** transfers the supplier list and the login. It rarely transfers the unwritten rules a buyer built over years.
- The cost is a four-week gap where a competent replacement still catches exceptions on day seven instead of day one.
- Nobody wrote the rules down because nobody had to, while the person who knew them was still in the building.
- Turning the tacit rules into system rules — via Custom Events — means the knowledge survives the departure that created the gap.

 A buyer leaves. There are two weeks of handover: the replacement sits beside her, takes notes, learns the suppliers. On paper, the transition looks thorough. What does not get handed over in those two weeks is the part that made her good at the job: which supplier needs a phone call and not an email, which order number sequence means a rush job, which delivery date is real and which is a placeholder the supplier always beats by three days. None of that lives in IFS. None of it lives in any document. It lives in her head, and it leaves the building with her on the last day. The replacement is competent and learns the formal system within a month. For the four weeks before that, exceptions that would have been caught on day one are caught on day seven, or not at all. This article covers what actually leaves when someone departs, what the gap costs, how to see it forming in IFS Cloud, and how to capture the unwritten rules before the next departure, not after.

  ## 1.Why does a formal handover miss the rules that matter?

 A handover plan, however thorough, transfers what is easy to name: accounts, passwords, open orders, supplier contacts. It struggles with what the departing buyer cannot easily name herself, because she has never had to. Eight years of pattern recognition compresses into instinct — she does not consciously decide that a particular supplier’s confirmation email means nothing and a phone call means everything. She just knows, and knowing that well is hard to teach in two weeks of shadowing.

 The organisation rarely notices the gap while the expert is still there, for the same reason it never got written down: the system works. It is only once she is gone that the absence of documentation becomes visible, and by then the two-week handover window has closed and the person who could have filled in the details is unreachable.

  ## 2.What does the missing handover actually cost?

 The cost of an incomplete handover does not show up as a single event. It shows up as a slow degradation in how quickly exceptions get caught, spread across the weeks it takes the replacement to rebuild the instinct that used to be automatic:

 
- **Lost judgement calls.** The replacement follows the documented process correctly and still misses the exception that only experience would have flagged.
- **Wrong channel, wrong urgency.** A supplier who needed a call gets an email instead, and a routine order that needed no attention gets chased unnecessarily.
- **The four-week gap.** Not a training problem — a gap between the old buyer’s intuition and the new buyer’s training, closing slowly, one mistake at a time.
- **Repeat incidents.** The same exception type the old buyer caught reflexively resurfaces, because the rule that caught it was never written down anywhere but in her head.

 Every departure is a knowledge-loss event. The only question is how much of what walked out the door was ever written down in the first place.

  ## 3.How do you see the gap in IFS Cloud?

 The gap is measurable, even though the knowledge itself was never in the system. Compare how quickly exceptions were caught and resolved in the weeks before a departure against the weeks after — the same exception types, the same order volumes, a different name attached to the resolution. The slowdown in catch time is the size of the handover that did not happen.

 Most teams never run this comparison, because by the time the gap is obvious it feels too late to be useful. It is not. The same comparison, done after the fact, tells you exactly which categories of exception depended most heavily on one person’s judgement — and which rules are worth capturing before the next departure, not after.

  ## 4.Manual handover versus rules captured in the system

 The fix is not a longer handover. It is moving the rules a buyer has never had to write down out of her head and into the system, using the same [approach that addresses concentration risk in a single expert](https://www.ifs-erp.com/blog/buyer-knowledge-concentration-risk-ifs) before anyone leaves.

 
|   | Manual handover | Captured as system rules |
| --- | --- | --- |
| What transfers | Supplier list and login | Supplier list, login, and the rules behind the calls |
| Where it lives | The departing buyer’s memory, for two weeks | IFS, as a Custom Event or rule |
| Survives departure | No | Yes |
| Ramp time for replacement | About four weeks to rebuild the instinct | Days — the rule already fires |
| Fails when | The handover window closes | Never — the rule does not resign |

 None of this replaces a good handover conversation. It means the conversation is backed by rules that keep working after it ends.

  ## 5.How do you roll it out safely?

 Do this while your best people are still in the building, not after the notice period starts.

 
1. **Interview before departure notice, not during it.** Ask the exception-handling questions now, with any long-tenured buyer, not only the one who happens to be leaving next month.
2. **Name the unwritten rules.** Which suppliers need a call, which order patterns mean urgency, which dates are real — write down the ten that matter most for each buyer.
3. **Turn the clear ones into Custom Events.** A rule that always applies — call this supplier, flag this pattern — becomes a system alert instead of private knowledge.
4. **Pilot on one buyer’s rules.** Encode one person’s judgement first, confirm the alerts match what she would actually have done, then widen.
5. **Repeat before every departure.** Make the interview a standard step in any planned exit, not a scramble in the final two weeks.

 Built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, none of this touches the core — update-safe, and ready long before the next resignation letter arrives.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What exactly gets lost when an experienced buyer leaves? Not the supplier list or the login — those transfer easily. What is lost is the judgement built from years of pattern recognition: which supplier needs a call instead of an email, which dates are padded, which order types are actually urgent. None of that is written down anywhere.

   Can a longer handover period fix this? It helps a little, but not as much as it seems. Most of what makes an experienced buyer effective is instinct she has never had to articulate, so a longer shadowing period mostly buys more anecdotes, not a complete transfer of judgement.

   How do you capture something someone doesn’t know they know? By asking specific, scenario-based questions rather than open ones — which supplier’s confirmation you actually trust, which order sequence means a rush, which delivery date you privately discount. The specific version of the question usually surfaces the rule the general version misses.

   Is this update-safe? Yes. The rules are built as standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no core modification for the next release to break.

  ## 7.About the author

 **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.

  ## Capture it before she leaves

 If a key departure is on the horizon, or you are still recovering from one, a short interview can turn years of instinct into rules that outlast any single resignation. On a 30-minute call I’ll map the approach to your team — fixed price, no obligation.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/knowledge-loss-employee-departure-ifs-cloud.md)

## The Metric That Lies: On-Time Delivery in IFS

Independent IFS Cloud practice · Supply Chain

 
## The on-time delivery metric that lies and the outliers it is hiding

 **Key takeaways**

 
- **An aggregate on-time delivery metric** can read 94 percent and still hide the three orders that mattered most that month.
- Averages weight every order equally — a late case of packaging counts the same as a late shipment that stops a production line.
- The outliers are cheap to find once you weight by consequence — value, criticality, customer tier — instead of just counting lines.
- A Custom Event that flags late critical orders separately turns the KPI from an answer into a question worth asking every month.

 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.

  ## 1.Why does the average hide the orders that matter?

 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.

  ## 2.What does the hidden six percent actually cost?

 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:

 
- **Production stoppages.** A single late critical component can idle a line for days, at a cost the monthly average will never register.
- **Customer loss.** One late order to the wrong customer at the wrong moment does more damage to the relationship than fifty on-time deliveries repair.
- **Hidden pattern.** The same handful of suppliers or part categories often account for the worst outliers month after month, invisible while buried in the average.
- **False confidence.** A green dashboard tells the business everything is fine, which is precisely when the next large order is allowed to slip unnoticed.

 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.

  ## 3.How do you find the outliers in IFS Cloud?

 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.

  ## 4.Aggregate KPI versus outlier-weighted monitoring

 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](https://www.ifs-erp.com/blog/automate-scm-processes-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.

  ## 5.How do you roll it out safely?

 Building the second view is a modest project, not a re-platforming exercise.

 
1. **Agree what counts as critical.** Set the value threshold, the customer tier, or the part flag that defines an order worth watching separately.
2. **Run in dry-run.** Log which late orders would have been flagged over the past few months and check the list against what actually went wrong.
3. **Tune the threshold.** Widen or narrow the criteria until the flagged list matches the orders that genuinely deserved attention, not everything or nothing.
4. **Pilot on one category.** Apply the rule to a single product line or customer segment first, and confirm it catches what the team already knew mattered.
5. **Review alongside the monthly KPI.** Bring both numbers to the same review — the average for the trend, the flagged list for the outliers that need a decision.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Why can 94 percent on-time delivery still be a problem? 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.

   How do you decide which orders are “critical” enough to weight? 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.

   Does this replace the on-time delivery KPI we already report? 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.

   Is this update-safe? Yes. It uses standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no modification to core on-time delivery reporting.

  ## 7.About the author

 **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.

  ## Look past the average

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/metric-that-lies-on-time-delivery-ifs-cloud.md)

## The Quiet Cost of "We Will Check Tomorrow" (IFS)

Independent IFS Cloud practice · Supply Chain

 
# The quiet cost of “we will check tomorrow” — and the fix that does not rely on discipline

 **Key takeaways**

 
- **Deferred exception checks** feel harmless one at a time — pushed to tomorrow because something louder needs attention today.
- The cost is invisible because it is distributed: a day here, a day there, across fifty orders and twelve months.
- This is not a discipline problem — the urgent always beats the important when the important is only a date in a system.
- Escalation logic that raises the important to urgent — visible, timed, owned — closes the gap without asking anyone to be more disciplined.

 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.

  ## 1.Why does the check keep moving to tomorrow?

 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.

  ## 2.What does a deferred check actually cost?

 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:

 
- **Accumulated slippage.** A day deferred here and a day deferred there add up to weeks of unmanaged lead time nobody planned for.
- **Exceptions caught late.** The check that would have caught a real problem on day one now catches it on day four, after the window to act cheaply has closed.
- **Downstream compounding.** A late catch on one order pushes into scheduling and transport booking, so one deferred check produces several delayed decisions.
- **Service level erosion.** No single delay looks catastrophic, but the pattern is exactly what turns a supply chain that absorbs disruption into one that amplifies it.

 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.

  ## 3.How do you see it in IFS Cloud?

 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.

  ## 4.Manual recall versus automated escalation

 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](https://www.ifs-erp.com/blog/ifs-custom-events-explained): 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.

  ## 5.How do you roll it out safely?

 Roll this out the same way you would any exception rule: prove it before anyone depends on it.

 
1. **Agree the threshold.** Decide how many days an exception can sit before it needs an escalation, and let it differ by order type — a late confirmation on a critical part deserves a shorter fuse than a routine reorder.
2. **Run in dry-run.** Log what would have fired for two weeks without sending anything. The list usually reveals how many days are already being lost before anyone acts.
3. **Tune recipients and cadence.** Decide who is alerted first — the buyer, then a supervisor after a further delay — and cap how often the same order can escalate.
4. **Pilot on one team.** Turn it on for a single buyer or category, watch a full cycle, then widen it once the behaviour is proven.
5. **Review after a month.** Check which thresholds fired too often, which never fired, and adjust — the rule should get quieter over time, not louder.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Is deferring a check really a discipline problem? 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.

   How is this different from just training buyers to check more often? 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.

   Won’t an alert for every late check just add more noise? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Stop losing days to tomorrow

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/cost-of-checking-tomorrow-ifs-cloud.md)

## Buyer Knowledge Risk in IFS Cloud Procurement

Independent IFS Cloud practice · Procurement

 
# Why your best buyer is also your biggest risk

 **Key takeaways**

 
- A senior buyer who knows every supplier by instinct is not just an asset — the eight years of pattern recognition behind that instinct usually exists nowhere except in her head.
- The better she is, the less anyone feels the need to write down what she knows — which makes the risk grow in exact proportion to her skill, not despite it.
- A replacement inherits a supplier list and a login in IFS Cloud. They do not inherit which supplier’s silence means trouble and which just means a contact is on holiday.
- The fix is not documentation nobody will read later — it is turning her judgment into rules IFS Cloud applies automatically, so the function survives the person.

 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.

  ## 1.Why does expertise concentrate in one person?

 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.

  ## 2.What does the concentration actually cost?

 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.

 
- **A blind handover.** A replacement, or a colleague covering for two weeks, gets a supplier list and open orders in IFS Cloud — not the mental model of which suppliers need a phone call before they miss a date.
- **Rediscovered problems.** Issues she was quietly managing by instinct resurface as visible incidents, because the person covering does not know they were ever a risk.
- **Negotiating leverage.** An organisation that cannot function without one person has none to spare in a conversation about her workload, her role, or her notice period.
- **A slow, expensive re-learning curve.** Whoever eventually replaces her rebuilds the same pattern recognition from scratch, at the same cost in missed deliveries it took her to build it the first time.

 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.

  ## 3.How do you see this happening inside IFS Cloud?

 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.

  ## 4.Tacit judgment versus a documented system rule

 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.

  ## 5.How do you capture it without disrupting her?

 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.

 
1. **Interview the pattern, not the person.** Sit with her over her top twenty suppliers and ask what she watches for on each one — not what the SOP says.
2. **Translate the answers into rules.** “This supplier goes quiet before a problem” becomes a behaviour-change check; “this one always confirms by Thursday” becomes a threshold.
3. **Run in dry-run against her own history.** Compare what the rules would have flagged against what she actually caught — gaps on either side are worth another conversation with her, not a silent fix.
4. **Give her the alerts first.** The rollout should make her faster before it makes anyone else able to cover for her — that is what earns her buy-in.
5. **Extend coverage gradually.** Once the rules hold up under her own scrutiny, they are ready to protect the function when she is not there to catch what they miss.

 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](https://www.ifs-erp.com/blog/supplier-behaviour-change-signal-ifs-cloud) or an [unconfirmed-PO escalation](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs). Clear ownership of who can see and change each rule follows the same logic as [segregation of duties in IFS Cloud](https://www.ifs-erp.com/blog/rbac-segregation-of-duties-ifs-cloud).

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Isn’t this just documentation? We already have SOPs. 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.

   How is this different from the risk of an employee leaving? 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.

   Will she see this as a threat to her role? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Build her a backup before you need one

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/buyer-knowledge-concentration-risk-ifs.md)

## Exception Routing vs Reporting in IFS Cloud

Independent IFS Cloud practice · Supply Chain

 
## The difference between a report and a decision and why IFS Cloud should route, not report

 **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 only ever delivers the first.
- Volume is not value: forty pages, eighty line items, a dashboard with six charts — the recipient scans it, sees nothing on fire, and moves on.
- A report that requires interpretation is a task you have handed to someone who did not ask for it. A decision that arrives pre-qualified is a gift.
- **Exception routing in IFS Cloud** puts the right three lines in front of the right person at the right time, and never asks them to hunt.

 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.

  ## 1.Why does reporting default to volume?

 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.

  ## 2.What does interpretation actually cost?

 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.

 
- **Hidden hunting time.** Every minute spent scanning eighty rows for the three that matter is a minute not spent acting on the three that matter.
- **Diffused ownership.** A report sent to a distribution list is a decision nobody personally owns; everyone assumes someone else already checked it.
- **Delay by design.** A weekly or monthly report means the three-line decision waits for the report’s schedule, not for the moment it actually became urgent.
- **Fatigue that hides the signal.** A recipient who scans forty pages every week and finds nothing eventually stops scanning carefully — exactly when a real exception finally appears.

 A report that requires interpretation is a task you have given to someone who did not ask for it.

  ## 3.How do you tell the difference in IFS Cloud?

 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](https://www.ifs-erp.com/blog/quick-reports-custom-fields-custom-events), and the trigger-and-action pattern behind routing specifically is the backbone of the [SCM automations for IFS Cloud](https://www.ifs-erp.com/blog/automate-scm-processes-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.

  ## 4.Reporting versus routing

 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.

  ## 5.How do you turn a report into routing safely?

 Start from a report you already trust, not from a blank page.

 
1. **Pick one existing report.** Choose the one that is opened most often and interpreted the same way each time — that repetition is exactly what routing should absorb.
2. **Name the three-line question.** Write down, in one sentence, what the reader is actually looking for when they scan it. That sentence becomes the filter.
3. **Run the filter in dry-run.** Log what it would have sent for two or three cycles and compare it to what a human actually flagged from the full report.
4. **Route to one named person.** Replace the distribution list with the specific role who owns the action, so the alert cannot be assumed to be someone else’s job.
5. **Keep the report as the record.** Let routing carry the urgency and the report stay as the audit trail and the place to check the wider picture.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What is the difference between exception reporting and exception routing? 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.

   Should we stop building reports altogether? 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.

   How do we decide what counts as the “three lines that matter”? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Turn your busiest report into a routed decision

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/exception-routing-vs-reporting-ifs-cloud.md)

## Silent Custom Code Failure After an IFS Cloud Upgrade

Independent IFS Cloud practice · Upgrades & Extensibility

 
## The upgrade that broke your custom check and never told you

 **Key takeaways**

 
- A custom PL/SQL alert can run successfully through an IFS Cloud upgrade, keep returning results, and still be broken. The failure mode is zero rows, not an error.
- Zero rows is indistinguishable from a quiet month, so the gap goes unnoticed for exactly as long as nobody has a reason to ask why nothing has fired lately.
- The real cost of customisation is rarely the build or the test. It is a silent failure two or three upgrades later, discovered only by the incident it should have prevented.
- A heartbeat check, confirming each rule still returns a plausible baseline rather than just that it runs without error, closes the gap and keeps the rule update-safe.

 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.

  ## 1.Why does a working check fail silently?

 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.

  ## 2.What does the silent failure actually cost?

 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.

 
- **A false sense of coverage.** Every day the check runs and reports nothing, the organisation believes a risk is being watched that has, in fact, gone unwatched since the upgrade.
- **Discovery by incident.** The gap is usually found the way any silent control fails: when the exact problem it existed to catch happens anyway, and someone asks why the alert never fired.
- **Compounding exposure.** The longer a check has been silently broken, the more upgrades and data changes have piled up underneath it, so restoring it correctly gets harder the later it is found.
- **Erosion of trust in automation.** Once one silent gap is found, every other custom rule on the estate is reasonably suspected of the same thing, and confidence is expensive to rebuild one manual re-check at a time.

 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.

  ## 3.How do you catch this before the incident does?

 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](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist) honest: verifying a control still behaves the way it always has, not just that it still exists in the codebase.

  ## 4.“Runs without error” versus “verified live”

 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.

  ## 5.How do you add a heartbeat without adding noise?

 The heartbeat should be quieter than the rule it is watching, not louder.

 
1. **Inventory every custom check that fires on a schedule.** A silent gap only matters for rules nobody would otherwise notice have stopped.
2. **Record a rolling baseline per rule.** A trailing window of typical hit counts is enough to define what “plausible” looks like for that specific check.
3. **Run in dry-run for a month.** Let the heartbeat log what it would flag before anyone receives an alert about an alert.
4. **Escalate a heartbeat failure separately from a business alert.** “This rule went quiet” is an IT/maintenance signal, not a purchasing one. Keep the two audiences apart.
5. **Re-baseline after every upgrade.** A legitimate change in volume after a release should not be mistaken for a broken dependency, and vice versa.

 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](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-tax). That is the same discipline that keeps [Custom Events](https://www.ifs-erp.com/blog/ifs-custom-events-explained) maintainable release after release.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Doesn’t our upgrade regression testing already cover this? 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.

   How would we even know which of our custom rules are at risk? 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.

   Won’t a heartbeat just create another alert nobody reads? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Find out which of your rules already went quiet

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/silent-custom-code-failure-ifs-cloud-upgrade.md)

## Why “We’ll Catch It at Month-End” Costs More

Independent IFS Cloud practice · Supply Chain

 
## Why “we’ll catch it at month-end” is too late and what to do instead

 **Key takeaways**

 
- The cost of an exception is not fixed — it compounds every day between when the record changes state and when a human learns it changed.
- A monthly review catches everything eventually, but by month-end the small problem from day one has usually become several bigger ones.
- This is not about working harder or reviewing more often. It is about shrinking the gap between the state change and the alert.
- A same-day Custom Event on the two or three exception types that hurt most removes the need to catch anything at month-end at all.

 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.

  ## 1.Why does “we’ll catch it at month-end” persist?

 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.

  ## 2.What does detection latency actually cost?

 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.

 
- **Shrinking recovery window.** The supplier or the buyer has less time to fix the problem the longer it sits unnoticed — a same-day nudge and a three-week silence are not the same conversation.
- **Rising production risk.** A late delivery that was harmless in week one can become the thing that stops a line by week four, once slack in the schedule runs out.
- **Firefighting hours.** A one-hour check on day one becomes two days of expediting, escalation calls and rework once the exception has multiplied into several related ones.
- **Eroding customer patience.** A customer told about a delay early tolerates it far better than one who finds out only when their own delivery is already late.

 A day-one fix costs an email. A month-end fix costs two days, a stopped line, and a harder conversation with the customer.

  ## 3.How do you shrink the gap in IFS Cloud?

 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](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud).

  ## 4.Periodic review versus real-time exception detection

 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](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs).

  ## 5.How do you roll this out safely?

 Shrinking detection latency is not a big-bang project. It is picking the highest -cost exceptions first and proving the model before it spreads.

 
1. **Rank your exceptions by cost curve.** Ask which two or three exception types get measurably worse the longer they sit — those are the ones worth same-day detection first.
2. **Define the trigger condition precisely.** Agree exactly what state change counts, so the alert fires on the same event the month-end report would have flagged, just earlier.
3. **Run a dry-run digest.** Log what would have fired for two to three weeks and compare it against what actually surfaced at the last month-end — the overlap validates the rule.
4. **Tune for noise before going live.** Adjust thresholds and recipients so each alert earns attention rather than getting filtered out on reflex.
5. **Expand coverage gradually.** Add the next exception type only once the first is trusted and acted on, not ignored.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Doesn’t same-day detection just create alert fatigue? 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.

   Does this replace the month-end report? 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.

   How do we choose which exceptions to automate first? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Stop paying the month-end price

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/month-end-catch-too-late-ifs-cloud.md)

## The Shadow Spreadsheet Running Your Factory - Fix It

Independent IFS Cloud practice · Manufacturing

 
## The spreadsheet that runs the factory: shadow-IT risk in IFS Cloud  and how to close it

 **Key takeaways**

 
- Almost every plant has a **desktop spreadsheet** that bridges the gap between what IFS was configured to do at go-live and how the operation actually runs three years later.
- It is dangerous not because it is a spreadsheet, but because it has no backup, no access control, no audit trail and exactly one person who understands it.
- It survives because it works — right up until the author is away, the laptop dies, or someone sorts one column without selecting the rest.
- The fix is not banning spreadsheets. It is moving the specific logic they carry into a structure IFS Cloud can back up, secure and log — and staying update-safe while doing it.

 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.

  ## 1.Why does the shadow spreadsheet exist?

 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.

  ## 2.What does the shadow spreadsheet actually risk?

 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.

 
- **Bus-factor risk.** One person understands the formulas, the macros and the exceptions baked in over the years. When they leave, the knowledge leaves with them.
- **No backup.** A file that lives on one desktop is one hardware failure away from disappearing, taking years of undocumented logic with it.
- **Silent drift from the system of record.** The spreadsheet and IFS quietly disagree, and decisions get made on whichever number was open on screen.
- **No access control or audit trail.** Anyone with the file can edit any cell, and nothing records who changed what or when.

 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.

  ## 3.How do you find where this is happening?

 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](https://www.ifs-erp.com/blog/quick-reports-custom-fields-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.

  ## 4.Desktop spreadsheet versus systematic extension

 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](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm).

  ## 5.How do you migrate it safely?

 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.

 
1. **Inventory what it actually tracks.** Sit with the owner and list every column that drives a real decision, separately from the ones that are just notes.
2. **Map each column to a tool.** Decide, column by column, whether it belongs as a Custom Field, a Quick Report, or a Custom Event trigger.
3. **Build against the owner, not around them.** They know the exceptions nobody wrote down; involve them and you keep that knowledge instead of losing it a second time.
4. **Run the two in parallel.** Let the spreadsheet and the new structure operate side by side for a cycle before anyone deletes the old file.
5. **Retire it once it agrees.** Cut over only after a full cycle shows the two sources matching, and keep a read-only copy of the old file for reference.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What if the spreadsheet owner resists handing it over? 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.

   How long does migrating one spreadsheet take? 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.

   Does this mean banning spreadsheets entirely? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Find out what your floor is really running on

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/shadow-spreadsheet-risk-manufacturing-ifs.md)

## Supplier Behaviour Change in IFS Cloud - Early Signal

Independent IFS Cloud practice · Supply Chain

 
## Supplier behaviour change in IFS Cloud: the early warning nobody is listening for

 **Key takeaways**

 
- A **supplier behaviour change** — a reliable supplier suddenly confirming late, or not at all — is one of the earliest signals a supply chain can give you, and IFS Cloud does not flag it by default.
- A static “unconfirmed after X days” rule catches a stuck order. It does not catch a supplier whose *pattern* just changed — and pattern is what predicts trouble before the order itself is late.
- By the time the change is obvious to a human, several orders are already affected and the supplier’s problem is no longer news to anyone but you.
- A baseline-and-deviation check, built the same way as an unconfirmed-PO escalation, turns a buyer’s memory into a system rule — and stays update-safe.

 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.

  ## 1.Why do supplier behaviour changes go unnoticed?

 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.

  ## 2.What does a missed behaviour change actually cost?

 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.

 
- **Lost lead time.** Every day between the first anomalous order and the moment someone acts is a day the supplier does not have to recover, and you do not have to find an alternative.
- **Reactive expediting.** Discovering a supplier’s trouble through a missed delivery means paying premium freight to fix a problem a pattern-based signal would have flagged weeks earlier.
- **Defensive buffer stock.** Without early warning, the instinct is to raise safety stock across the board — tying up working capital to compensate for information you should have had for free.
- **Lost negotiating position.** A conversation that starts with “we noticed your confirmations have slowed — is everything all right?” is a very different conversation from one that starts with “why is our line down?”

 The supplier almost always knows before you do. The only question is how many orders pass before you find out too.

  ## 3.How do you detect it in IFS Cloud?

 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](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs).

  ## 4.Static threshold versus behavioural baseline

 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.

  ## 5.How do you roll it out safely?

 Behavioural detection is more sensitive than a flat threshold, so it earns a more careful rollout.

 
1. **Choose the baseline window.** Ninety days of confirmed orders is a reasonable default; shorten it for suppliers with sparse order volume.
2. **Run in dry-run.** Let the comparison log what it would flag for a month before anyone receives an alert, and check the list against what buyers already suspected.
3. **Set the deviation threshold.** Decide how far outside a supplier’s own baseline counts as meaningful — start conservative and tighten once you trust the signal.
4. **Pilot on your top suppliers by spend.** These are the relationships where an early warning is worth the most and where buyers can validate the signal fastest.
5. **Review quarterly.** Baselines shift as relationships mature; a threshold that made sense at go-live may be too loose — or too tight — a year later.

 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](https://www.ifs-erp.com/blog/supplier-price-changes-ifs-cloud).

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 How is this different from an unconfirmed-PO escalation? 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.

   How much order history do I need before the baseline is reliable? 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.

   Will this create false alarms for suppliers who are naturally inconsistent? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Stop finding out from the production line

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/supplier-behaviour-change-signal-ifs-cloud.md)

## The Monday Morning Ritual Nobody Else Can Run

Independent IFS Cloud practice · Supply Chain

 
## The Monday morning ritual nobody else can run

 **Key takeaways**

 
- Every Monday, someone opens IFS and runs through purchase orders checking who confirmed and who stayed silent — forty minutes, three years running.
- The routine looks simple. The judgement inside it — which silence means trouble and which means the contact is on holiday — is not written down anywhere.
- A process that depends on one person showing up at 7:30 is not a process. It is a bet, and bets get called on the worst possible Tuesday.
- The fix is not documenting a script — it is externalising the pattern the person already knows into a rule the system can run.

 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.

  ## 1.Why does the judgement stay in one person’s head?

 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.

  ## 2.What does an undocumented ritual actually cost?

 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 stand-in starts from zero.** Whoever covers has the same screen and none of the three years of pattern recognition — every silent order looks equally suspicious, or equally fine.
- **False positives and false negatives.** A cover chases a supplier who was never a risk, and misses one that quietly always is — both waste time, one of them costs money.
- **The check simply does not happen.** Under pressure, an unfamiliar forty-minute task is the first thing a stand-in defers — and a deferred check is functionally a skipped one.
- **Nobody notices it slipped.** Because the routine has no record beyond “did it run,” a skipped Monday leaves no trace until an order that should have been chased turns up late.

 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.

  ## 3.How do you see the tacit knowledge in IFS Cloud?

 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.

  ## 4.The private ritual versus an externalised rule

 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.

  ## 5.How do you roll it out safely?

 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.

 
1. **Narrate a real Monday.** Capture the actual reasoning behind three or four real decisions, in the person’s own words, before writing any rule.
2. **Draft the rule and run it in dry-run.** Log what it would have flagged over recent weeks and compare it against what the person actually did.
3. **Review the mismatches together.** Every disagreement either sharpens the rule or reveals a genuine judgement call worth keeping manual.
4. **Pilot for a month with the person still checking.** Let the rule run alongside the ritual before either one is trusted alone.
5. **Hand over coverage, not the whole job.** The rule takes the routine load; the person keeps the exceptions and the two-week holiday stops being a risk.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Isn’t this the same as the single-point-of-failure problem? 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.

   Can you really capture years of pattern recognition in a rule? 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.

   Will the person who runs the check today feel replaced? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Get the ritual out of one person’s head

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/manual-purchase-order-check-routine-ifs.md)

## The Cost of a Missed Check - IFS Cloud

Independent IFS Cloud practice · Supply Chain

 
## The cost of a missed check: a €200 part, a €40,000 stoppage

 **Key takeaways**

 
- A purchase order that sits unconfirmed for eleven days can stop a production line for four hours — a €200 part behind a €40,000 loss.
- That ratio is not unusual: the cost of a missed check is rarely the material itself — it is the machine that went quiet and the delivery that slipped.
- The order state and the date were both correct the whole time — this is an attention problem, not a data problem.
- The fix is not more scrutiny per order — it is a systematic check that never skips one, however small it looks.

 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.

  ## 1.Why does a small exception turn into a big loss?

 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.

  ## 2.What does the ratio actually look like?

 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:

 
- **Idle production.** A line waiting on one missing part burns labour and overhead hours that were already committed, regardless of the part’s value.
- **Recovery cost.** Catching up means expedited freight and rush fees on the missing part — and often on the parts around it, to resequence the line.
- **Slipped delivery.** Four hours of downtime rarely stays four hours by the time it reaches the customer’s dock — it compounds with whatever else was already queued behind it.
- **Trust cost.** A missed delivery date is a conversation with a customer that a €200 part should never have caused — and it is the conversation that gets remembered.

 The most expensive exception in your supply chain is the one you had the data to prevent and still missed.

  ## 3.How do you catch it in IFS Cloud on day two, not day eleven?

 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.

  ## 4.Manual scanning versus systematic exception checking

 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.

  ## 5.How do you roll it out safely?

 Start narrow, let the data show you where the ratio bites hardest, and expand from evidence rather than a guess.

 
1. **Agree the trigger.** Define the order state and age that count as a missed check for your operation — not by value, by risk to what it feeds.
2. **Run in dry-run.** Log what would have fired over the last few months and compare it against known stoppages — the pattern usually confirms itself quickly.
3. **Tune the recipients.** Route the alert to whoever can actually act on it that day, not just the buyer of record.
4. **Pilot on one line or one site.** Prove the reduction in missed exceptions before widening coverage.
5. **Review the ratio after a month.** Check what fired, what it prevented, and adjust the threshold on real evidence.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Is the €200-versus-€40,000 ratio a one-off, or does it hold generally? 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.

   Why not just have buyers check low-value orders more carefully? 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.

   Does this overlap with unconfirmed purchase order monitoring? 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.

   Is this update-safe? 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.

  ## 7.About the author

 **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.

  ## Close the gap before it reaches the line

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/cost-of-missed-exceptions-ifs-cloud.md)

## AI Accountability for ERP Automation in IFS Cloud

Independent IFS Cloud practice · Automation & Governance

 
## The thing AI did not make cheaper in your ERP

 **Key takeaways**

 
- A model can draft an OData query against your IFS Cloud projections in minutes — writing automation code has gotten close to free.
- Being accountable for what that code does to a live ERP at six in the morning, unattended, did not get cheaper at all — the model has no name to put under the output.
- A working script and an owned, reviewed, safely-scoped automation are not the same deliverable, even when the code is identical.
- Before connecting anything AI-assisted to IFS Cloud, ask one question: when this goes wrong at 6am, whose name is on it?

 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.

  ## 1.Why did this gap open now?

 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.

  ## 2.What does the missing accountability actually cost?

 Nothing, right up until the automation does something it should not have — and then the bill arrives all at once.

 
- **An external mistake.** A first run that was never scoped or rate-limited can email hundreds of suppliers or customers a message they should never have received, with your company's name on it.
- **Unbounded blast radius.** Code that looks correct against a test case can behave very differently the first time it runs against the full history of a live table — and nobody scoped what the full run would actually do.
- **Nobody to call at 6am.** When a generated script fires unexpectedly overnight, the org needs a name that can explain it, stop it and fix it — not a chat transcript.
- **Confidence outpacing scrutiny.** Code that arrives instantly and looks polished gets less scepticism than code that took a developer a day to write, precisely when it deserves more.

 A model does not take the blame. It has no name to put under the output.

  ## 3.Where does this show up in an IFS Cloud estate?

 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.

  ## 4.AI-drafted code versus accountable automation

 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.

  ## 5.How do you use AI-assisted drafting without losing accountability?

 The goal is not to slow down the drafting. It is to make sure ownership catches up to it before anything touches production.

 
1. **Name an owner before the first run.** Whoever prompts or accepts a generated script signs their name to it — not the tool that helped write it.
2. **Dry-run against real history first.** The first execution against five years of orders happens in a mode that logs what it would have done, not one that actually sends anything.
3. **Scope the blast radius explicitly.** Cap volume, restrict recipients, and rate-limit anything that emails or writes externally until the behaviour is proven.
4. **Review before go-live, every time.** A second person checks the logic and the dry-run output — AI-assisted origin does not earn a shortcut, it earns the same review any custom code gets.
5. **Keep it inside the Extensibility Framework.** Whatever generated the first draft, the delivered rule is standard Custom Events, Workflows and PL/SQL — update-safe, no core modification, reviewable by a human who can be paged.

 The same discipline that keeps [Custom Events](https://www.ifs-erp.com/blog/ifs-custom-events-explained) and a [Clean Core](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Are you saying not to use AI to write IFS Cloud automation? 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.

   What is the single biggest risk of AI-assisted automation on a live ERP? 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.

   How is this different from any other code review process? 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.

   Is automation built this way update-safe? 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.

  ## 7.About the author

 **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.

  ## Ask the 6am question before it asks itself

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/ai-accountability-erp-automation-ifs.md)

## Read-Only OData Monitoring for IFS Cloud

Independent IFS Cloud practice · Clean Core & Integration

 
## Reading without writing: the safest way to monitor IFS Cloud

 **Key takeaways**

 
- A **read-only OData integration** watches order states, delivery dates and stock levels through IFS Cloud’s own projections — no custom objects planted in the core.
- Every write path you add to a monitoring tool is something you must test, patch and defend at the next R1 or R2 upgrade; a read-only account never asks that of you.
- A read-only integration cannot corrupt data and cannot violate a business rule, because it never touches the write side of IFS Cloud.
- Nothing installed, nothing to uninstall, nothing that breaks quietly on the next release - the monitoring layer stays entirely inside Clean Core.

 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.

  ## 1.Why do monitoring tools end up writing to IFS Cloud?

 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.

  ## 2.What does a write path actually cost you?

 The cost is not visible on the day you add the write. It shows up two or three upgrades later, spread across four places:

 
- **Regression testing.** Every write path is a customisation surface QA has to rediscover and reverify at every R1 and R2, whether anyone remembers building it or not.
- **Upgrade fragility.** A write that worked cleanly against last year’s business logic can violate a rule the next release tightens, and it usually fails at the worst possible moment — mid-upgrade, in production.
- **Elevated permissions.** A monitoring account with write access is a bigger target and a bigger blast radius if the credentials leak or the tool misbehaves.
- **Ongoing maintenance.** Every writeback needs its own error handling, its own retries, and someone who owns what happens when it fails silently at three in the morning.

 The cheapest integration to maintain is the one that never asked IFS Cloud to trust it with a write.

  ## 3.How do you build it read-only in IFS Cloud?

 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.

  ## 4.Writeback integration versus read-only monitoring

 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.

  ## 5.How do you roll it out safely?

 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.

 
1. **Scope the projections.** List exactly which entities — order state, confirmation, delivery date, stock level — the monitoring layer needs, and nothing more.
2. **Create a dedicated read-only account.** A named integration user with a permission set that grants read access only, never write privileges, even where write access looks convenient.
3. **Test against a non-production environment first.** Point the read-only layer at a test or UAT tenant before it ever touches live data.
4. **Cap the polling frequency.** Poll on a schedule that respects IFS Cloud’s own performance envelope, not on every possible trigger.
5. **Review the account after every upgrade.** A five-minute permission check per R1 or R2 cycle is the entire ongoing maintenance cost.

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Does a read-only OData integration need any custom development in IFS Cloud? 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.

   What can a read-only integration actually see? 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.

   Can a read-only integration still send alerts and take action? 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.

   Is this approach compatible with Clean Core? 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.

  ## 7.About the author

 **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.

  ## Monitor without the upgrade tax

 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.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/read-only-odata-monitoring-ifs-cloud.md)

## Your ERP Already Knows: Closing the Attention Gap

Independent IFS Cloud practice · Supply Chain

 
# Your ERP already knows - closing the distance between a record and a person

 **Key takeaways**

 
- Stock under minimum, a receipt past due, an order stuck in a state it should have left days ago - IFS Cloud is holding all of it right now, correct and current, sitting in a projection.
- The failure is rarely the system. It is the distance between a record changing and a human noticing it changed.
- Reporting tells you what happened last month. By then the decision window has closed and you are managing a consequence instead of a choice.
- What a supply chain actually needs is smaller: the short list of things that need a decision today, in front of the person who can make it, before the delivery date turns choice into cleanup.

 Ask most operations leaders what is wrong with their reporting and they will describe wanting more of it — another dashboard, another KPI, a deeper cut of the same numbers. That is usually the wrong instinct, because the data behind the decisions that actually matter is not missing. Stock under minimum, a purchase order sitting unconfirmed, a receipt that never matched an invoice, an order stuck in a state it should have left days ago — IFS Cloud is holding every one of those facts right now, correct and current, the moment they become true. The exception is not hidden. It is sitting in a projection, waiting. What is actually missing is the last mile: the short distance between that record changing state and a specific person finding out it changed, in time to still have a choice. This article is the overview of that idea — where the gap comes from, what it costs, and the shape of the fix, with pointers to the deeper articles on specific exceptions.

  ## 1.Why does the gap between data and attention exist at all?

 ERPs are built to record state accurately, not to decide who should care that the state changed. That division of labour made sense when the alternative was manual pull-based reporting — someone runs a query, someone reads a printout. It stops making sense the moment the exception is time-sensitive, because a system that only answers when asked is structurally always one step behind the person who did not think to ask yet.

 Reporting compounds the problem instead of solving it. A monthly or weekly report is, by design, a summary of what already happened, aggregated after the window to act on any single instance has usually already closed. It is genuinely useful for trend and pattern — is this getting better or worse over a quarter — and genuinely useless for the specific stuck order sitting in front of you today. Teams keep building more reports because reporting is what the tools make easy, not because it addresses the actual gap.

  ## 2.What does the attention gap actually cost?

 The cost shows up as a series of moments where a decision that was available got replaced by a cleanup that was not:

 
- **A closed decision window.** Stock trending toward a shortage is a choice on day one and an emergency purchase on day ten — the data was identical the whole time, only the options changed.
- **Consequence management instead of choice management.** Once the delivery date passes, the team is no longer deciding whether to act — they are absorbing the impact of not having acted sooner.
- **Duplicated watching.** In the absence of a system that surfaces the exception, multiple people end up independently checking the same reports, each assuming someone else has it covered.
- **Reactive culture.** Teams that only ever hear about problems after they land stop expecting to be told in advance, and stop asking for it, which quietly lowers the bar for what “on top of it” means.

 The data is not the problem. The last mile between the record and the person is.

  ## 3.How do you find where the gap sits in your own IFS Cloud?

 Walk your last three genuine surprises — the stock-out nobody saw coming, the order that quietly slipped, the invoice mismatch that surfaced at month-end — and ask one question of each: was the fact that this was going to happen sitting in IFS Cloud before it happened? In almost every case it was. Stock position, order state and age, confirmation status — the projections held the truth well before the surprise landed.

 That exercise reliably produces a short list of two or three exception types that keep costing you, and each one becomes a candidate for the same pattern: a Custom Event that watches the relevant state, checks it against a sensible threshold, and tells one named person before the window closes. Two of the most common starting points already have their own detailed treatment — [unconfirmed purchase orders](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs) and the broader set covered in [SCM automations for IFS Cloud](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud).

  ## 4.Waiting for a report versus surfacing the exception

 Reporting and exception surfacing are not competing solutions to the same problem — they answer different questions. Reporting answers “how are we doing.” Surfaced exceptions answer “what needs a decision from me today,” and only one of those questions has a closing window.

 
|   | Reporting | Surfaced exceptions |
| --- | --- | --- |
| Answers | How are we doing overall | What needs a decision now |
| Timing | After the fact, on a cadence | As the state changes |
| Who has to look | Someone who remembers to pull it | The specific owner, automatically |
| Best for | Trend, pattern, board packs | The stuck order in front of you today |
| Decision window | Usually already closed | Still open |

 Neither replaces the other. A supply chain needs both — the trend view to know if things are improving, and the surfaced exception to act while there is still a choice to make.

  ## 5.How do you start closing the gap without a big-bang project?

 This is not a platform decision or a transformation programme. It is a small, repeatable pattern you apply to one exception type at a time.

 
1. **Pick the exception costing you the most.** Use the “last three surprises” exercise above to find it rather than guessing.
2. **Define the threshold.** Agree exactly what state and age should trigger a notice, in terms specific enough to encode.
3. **Run it in dry-run.** Log what would have fired over a real period and check it against what actually happened.
4. **Route it to one owner.** A surfaced exception with no clear recipient is just a new report nobody reads — name the person.
5. **Prove it, then take the next exception on the list.** Once the first pattern is trusted, the second and third are faster, because the mechanics repeat.

 Every one of these rules is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — so the last mile you close today stays closed after every future upgrade, with no core modification at risk.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What is the data-attention gap in a supply chain system? It is the distance between the moment a record in IFS Cloud changes to a state that needs attention and the moment a specific person actually notices it changed. The data is correct and available the entire time; the gap is purely about whether and when a human sees it.

   Isn’t better reporting the answer to this? Reporting answers a different question — how things are trending — and it is genuinely valuable for that. It rarely closes the attention gap because it is built on a cadence, and most exceptions have a decision window shorter than the reporting cycle.

   Which exception type should we close the gap on first? Whichever one produced your most recent genuine surprise. Walking back through the last three surprises and checking whether the data existed beforehand almost always points directly at the highest-value starting point, rather than requiring a guess.

   Is this a big IT project? No. Each exception type is closed with a single Custom Event scoped to one threshold and one recipient, proven in dry-run before it goes live. It is deliberately small and repeatable rather than a platform change, so it can start with the single highest-cost exception and expand from there.

  ## 7.About the author

 **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.

  ## Close the last mile between your data and your team

 Your ERP is not short on data — it is short on a mechanism that gets the right fact to the right person while there is still a decision to make. A 30-minute call is enough to name your highest-cost exception and sketch the fix — fixed price, dry-run before anything goes live.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/data-attention-gap-ifs-cloud.md)

## Why 'It's in the System' Isn't the Same as 'It's Confirmed'

Independent IFS Cloud practice · Supply Chain

 
## Why “it’s in the system” isn’t the same as “it’s confirmed”

 **Key takeaways**

 
- An order sitting in Released with no supplier confirmation is a promise you have not actually received — but on screen it looks exactly as settled as one that was.
- The pattern repeats across document types: unconfirmed purchase orders, sales orders without real coverage, receipts nobody reconciled against an invoice.
- The gap was never the data. The information sat in a projection the whole time, waiting for someone to ask. The gap was attention.
- The cost is not the late part or the missed shipment — it is the run of days you spent believing something was on its way when it never left.

 “It’s in the system” is one of the more dangerous sentences in a supply chain, because it is almost always true and almost never the point. The order is in the system. The line is there, the date is there, the part number is there. What the sentence quietly skips is whether anyone on the other end — a supplier, a warehouse, an accounts team — has actually acted on it. A record existing and a record being confirmed are two different facts, and IFS Cloud, like most ERPs, will happily show you the first without ever forcing the second. This article is a companion piece to a deep look at one specific version of this problem, unconfirmed purchase orders. Here the goal is broader: to name the pattern itself, show it recurring across a few document types, and make the case that “assumed” and “confirmed” deserve to be treated as structurally different states, not shades of the same one.

  ## 1.Why do records get read as confirmed when they are only assumed?

 A screen does not distinguish intent from acknowledgement. A purchase order in Released state looks identical whether the supplier accepted it an hour ago or never saw it at all. A sales order with a promised date looks identical whether the material behind it is actually allocated or whether the coverage check silently failed. A goods receipt sitting in the system looks identical whether it was ever reconciled against the matching invoice or is quietly waiting for someone to notice it was not. In every case the record exists, so the human eye reads “exists” as “settled,” and moves on to the next line.

 This is not a data quality problem. The fields are correct; the state is accurately recorded. It is an attention problem wearing a data problem’s clothes — the record correctly shows an unconfirmed state, and the failure is that nobody built a mechanism to notice that specific state and treat it differently from a confirmed one. Left alone, the two categories blur together on every screen and every report until the day the difference becomes very visible, very fast.

  ## 2.What does the assumed-versus-confirmed gap actually cost?

 The visible cost is always downstream — a late part, a missed shipment, a surprise invoice mismatch. The real cost sits earlier, in the days that passed while everyone believed the record was further along than it was:

 
- **Lost lead time.** Every day spent believing an unconfirmed order is moving is a day of real lead time you cannot get back once the truth surfaces.
- **False coverage.** A sales order that looks covered but is not means a promise made to a customer on the strength of a record, not a fact.
- **Reconciliation debt.** Receipts nobody matched to an invoice pile up quietly, then surface all at once at month-end as a scramble instead of a routine.
- **Misplaced confidence.** Reports built on top of assumed-confirmed records inherit the false certainty, so decisions made from them are only as good as an assumption nobody flagged.

 The cost is not the late part. It is the run of days you spent believing something was on its way when it never left.

  ## 3.How do you tell assumed from confirmed inside IFS Cloud?

 The information was never missing. Every one of these examples — purchase order confirmation, sales order coverage, receipt-to-invoice matching — lives in an IFS Cloud projection today, correct and current, the moment the state changes or fails to. What is missing is a standing question asked of that data: which of these records are sitting in a state that looks final but structurally is not?

 The practical test is the same across document types. Pick the state that should be temporary — released-but-unconfirmed, promised-but-uncovered, received-but-unmatched — and ask how long a record is allowed to sit there before someone should be told. If the honest answer is “indefinitely, because nobody is watching that specific state,” you have found a record category that is assumed rather than confirmed, and a candidate for the same detection pattern the unconfirmed-PO article covers in detail.

  ## 4.Trusting the screen versus verifying the state

 Trusting the screen means reading “exists in the system” as “confirmed,” and finding out otherwise only when a downstream deadline forces the question. Verifying the state means a rule stands between the record and the assumption, checking specifically for the unconfirmed case and surfacing it before it becomes a deadline problem.

 
|   | Trusting the screen | Verifying the state |
| --- | --- | --- |
| When the gap surfaces | At the deadline | Days or weeks earlier |
| What triggers a look | A downstream failure | A defined threshold on age or state |
| Who notices first | Whoever is affected by the failure | Whoever owns the record |
| Applies across document types | Inconsistently, ad hoc | Same pattern, every type |
| Cost of the gap | Paid in full, late | Paid small, early, or avoided |

 The mechanics of building that verification — the threshold, the dry-run, the escalation — are the same regardless of which document type you start with. For purchase order confirmation specifically, the full breakdown, including the exact table structure and rollout steps, is covered in [unconfirmed purchase orders in IFS](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs).

  ## 5.How do you roll this out across more than one document type?

 Treat this as a pattern to apply, not a single fix to deploy once. The same five steps work whether the record in question is a purchase order, a sales order, or a goods receipt.

 
1. **Name the assumed state.** For each document type, define precisely what “looks settled but is not confirmed” means — released-but-unacknowledged, promised-but-uncovered, received-but-unmatched.
2. **Pick one document type first.** Do not roll out the pattern everywhere at once. Start with the one costing the most, usually purchase order confirmation.
3. **Run detection in dry-run.** Log what would have been flagged over a real period before anything is sent to anyone.
4. **Escalate to the record owner, not everyone.** The buyer for POs, the planner for coverage, the AP clerk for receipts — keep ownership specific.
5. **Extend to the next document type.** Once the first is proven and trusted, apply the same pattern to the next candidate on the list.

 Every instance of this pattern is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — so extending it to a new document type is additive, not a rebuild, and stays update-safe as it grows.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What is the difference between an assumed record and a confirmed one? An assumed record exists in the system and looks settled — the fields are filled in and the state seems final — but no external party or downstream check has actually acknowledged it. A confirmed record has that acknowledgement recorded against it explicitly, so its state can be trusted rather than inferred.

   Is this the same issue as unconfirmed purchase orders? Unconfirmed purchase orders are the clearest single example of this pattern, and get their own full breakdown elsewhere on this site. This article is the broader version — the same gap shows up in sales order coverage, receipt-to-invoice matching and other document types, not only purchasing.

   Which document type should we tackle first? Start with whichever assumed-state gap is costing the most today, which for most distribution and manufacturing businesses is unconfirmed purchase orders. Prove the pattern there, then extend it to sales order coverage or receipt matching once the mechanics and trust are established.

   Does this require a data cleanup project first? No. The data is already correct — it accurately shows the unconfirmed state. What is missing is a rule that notices that specific state and tells someone, so this is a detection and escalation exercise, not a data quality project.

  ## 7.About the author

 **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.

  ## Stop reading “in the system” as “confirmed”

 If you suspect one or more document types in your operation carry this gap, a 30-minute call is enough to name the candidates and map which one to prove first — fixed price, dry-run before anything sends.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/assumed-vs-confirmed-records-ifs-cloud.md)

## The Fastest Way to Get an Alert Ignored

Independent IFS Cloud practice · Supply Chain

 
## The fastest way to get an alert ignored - and the restraint that fixes it

 **Key takeaways**

 
- Exception reporting fails for a reason that has nothing to do with the data. It fails because it treats a person like a queue — send every line every day and within a week the report has its own folder nobody opens.
- Good exception handling is an exercise in restraint: one message per person per day, only what changed since yesterday, only what actually needs a decision.
- Volume feels like diligence. It is the opposite — every alert that did not need sending makes the next one easier to ignore.
- An alert nobody reads is worse than no alert at all. It quietly trains the room to look away, and it takes the important one down with it.

 Somewhere in most planning teams there is a rule that fires on every line, every day, whether anything changed or not. It started as a good idea: nobody wanted to miss an exception, so the system was set to flag everything that might matter. Six months later that report has its own folder, and the folder has an unread count in the thousands. The one email in there that actually needed a same-day decision looked exactly like the two hundred that did not, so it waited with them, and by the time anyone opened it the delivery date had already passed. The team is not careless. The alert simply stopped reading as information the day it started arriving whether or not anything had happened. This article covers why exception volume spirals in the first place, what the fatigue actually costs, how to see it happening in IFS Cloud, and how to redesign the alert so the one message that matters is the only one that arrives.

  ## 1.Why does exception volume spiral in the first place?

 Nobody sets out to build a report nobody reads. It starts from a defensible instinct: better to over-notify than to miss something. So the first version of the rule casts a wide net — every open order, every line below target, every supplier with a date in the past — and it ships because wide coverage looks like thoroughness on a demo. What it actually does is hand the recipient a sorting job disguised as an alert. Every line demands the same five seconds of attention to work out whether it is the one that matters, and most of them are not.

 The volume rarely gets revisited once it is live, because turning an alert down looks like reducing visibility, and nobody wants to be the person who quietly removed a safety net. So the report keeps firing at full volume long after everyone has learned to skim past it, and the one rule meant to catch the important exception is buried inside the noise it created for itself.

  ## 2.What does alert fatigue actually cost?

 The cost is not the noise itself. It is what the noise trains people to do to every message that arrives after it, including the ones that matter:

 
- **Trained blindness.** After enough irrelevant alerts, the brain stops distinguishing them from the important ones — every message gets the same half-second glance.
- **Delayed decisions.** The one line that needed action today sits unread in a folder built for lines that needed nothing, and it surfaces only once the deadline has already passed.
- **Wasted triage time.** Someone still has to open the report occasionally and manually work out which of two hundred lines is real, which is the exact job automation was supposed to remove.
- **Eroded trust in every future alert.** Once a report earns a reputation for noise, people stop trusting the next system that tries to notify them of anything.

 An alert nobody reads is not neutral. It is worse than no alert, because it trains the room to look away — and it takes the important one down with it.

  ## 3.How do you see this happening in IFS Cloud?

 Fatigue rarely announces itself with a complaint. It shows up as a folder rule quietly created to route the alert straight past the inbox, as a recipient who stopped replying to the distribution list months ago, or as a Custom Event log showing the same message firing daily against the same handful of orders with no change in outcome. Any of those is a working definition of an alert that has stopped functioning as an alert.

 The fix starts with counting, not redesigning. For each recurring notification, ask how many messages it sent last month, how many of those represented a genuine change since the prior message, and how many required a decision from the recipient. If the second and third numbers are far below the first, the rule is firing on presence rather than change, and that gap is exactly what a Custom Event condition should be checking for instead.

  ## 4.Send-everything alerting versus disciplined exception design

 The difference is not sophistication. It is discipline applied to a small set of rules: fire on change, not on presence; cap it at one message per person per day; and route only the lines that need a human decision. The same [Custom Event mechanics](https://www.ifs-erp.com/blog/ifs-custom-events-explained) that power every rule in the [SCM automation catalogue](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud) support both patterns — the difference is entirely in how the condition and the frequency cap are written.

 
|   | Send everything | Disciplined design |
| --- | --- | --- |
| Trigger | Presence of a condition | Change in a condition |
| Frequency | Every run, regardless of prior sends | Capped — once per person per day |
| Content | Every line that matches | Only lines needing a decision |
| Recipient reaction | Skim, ignore, folder rule | Read, act |
| Trust over time | Declines | Holds |

 A rule that fires less often is not a weaker rule. It is the same detection logic with an extra condition — has this changed since I last told you — that turns a queue of lines into a short, trustworthy list.

  ## 5.How do you roll out disciplined alerting safely?

 Redesigning a live alert without a plan just creates a different kind of chaos. Tighten it in stages, and let the recipients confirm each step before the next.

 
1. **Audit the current volume.** Pull a month of send history and count how many messages represented a real change versus a repeat of yesterday’s state.
2. **Define “change” explicitly.** Agree the condition that separates a genuine exception from a line that simply still exists — a status flip, a date slip, a threshold crossed.
3. **Run the new condition in dry-run.** Log what the tightened rule would have sent last month and compare it against what actually needed action.
4. **Cap the frequency.** One message per person per day, consolidating multiple exceptions into a single digest rather than separate emails.
5. **Pilot with one team, then review.** Ask directly whether they are reading it now, and adjust the threshold before rolling it out further.

 Because the redesigned rule is still built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — it is update-safe. Tightening the condition changes what fires, not the core, so the next release does not undo the work.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call) [See SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What is alert fatigue in a supply chain context? It is the state where a recipient has received so many low-value notifications that they stop reading all of them carefully, including the rare one that actually needs same-day action. The exception itself may still be correctly detected — the failure is entirely in whether anyone notices.

   Isn’t it safer to over-notify than to miss something? It feels safer, but it produces the opposite outcome. Once a report earns a reputation for noise, people stop trusting it entirely, which means the genuinely important exception is now less likely to get read than it would be inside a shorter, trusted list.

   How many alerts per day is too many? There is no universal number, but one consolidated message per person per day is a reliable working target. If a rule needs to send more than that to cover genuine changes, the underlying condition is usually too broad and worth tightening first.

   Will tightening an existing alert risk missing something important? Not if you run the tightened condition in dry-run first and compare it against a month of history before switching it on. That comparison is exactly what confirms the new rule still catches everything that mattered, just without the lines that did not.

  ## 7.About the author

 **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.

  ## Make your alerts worth opening again

 If your team has a report with its own unread folder, the fix is rarely more alerting — it is less, aimed better. A 30-minute call is enough to look at one live rule and sketch what a disciplined version would send instead — fixed price, dry-run before anything changes.

 [Book a 30-min call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/alert-fatigue-exception-design-ifs-cloud.md)

## IFS Cloud RBAC & Segregation of Duties: Get It Right

Independent IFS Cloud practice · Security

 
## RBAC and Segregation of Duties in IFS Cloud SCM: getting permissions right

 Get IFS Cloud RBAC and Segregation of Duties wrong and the finding lands in your audit report: the same person who creates a supplier can also approve its invoices. This guide explains how Permission Sets work, where the real conflicts live in Purchasing, Inventory and Invoicing, and how to design a model that passes an audit - without a custom object quietly opening a back door.

 ## Key takeaways

 **Key takeaways**

 
- IFS Cloud access is built from Permission Sets granted to users - RBAC done well means roles map to job functions, not to individuals.
- Segregation of Duties (SoD) means no single person controls a whole transaction - create versus approve, order versus receipt, master data versus payment.
- The highest-risk SCM conflicts are supplier creation with invoice approval, and PO creation with goods receipt.
- Custom objects can bypass the standard security model - an unsecured projection or event is an invisible SoD hole.
- Design roles around a documented SoD conflict matrix, then audit against it on every change and every release.

  ## 1.How does RBAC work in IFS Cloud?

 IFS Cloud does not grant access to people directly. It grants it to **Permission Sets** - named bundles of rights over projections, entities and actions - and then assigns those Permission Sets to users. That is role-based access control (RBAC): the permission attaches to the role, the role attaches to the person.

 Done well, a Permission Set maps to a *job function*: “Buyer”, “Goods Receipt Clerk”, “AP Approver”. A user gets the sets their job needs and nothing more. Done badly, sets balloon into “Purchasing” catch-alls that grant every action in the module, and the line between who can order and who can pay disappears.

 Two principles keep RBAC honest: **least privilege** - grant only what the function requires - and **role, not person** - never patch a one-off permission onto an individual, because it is invisible at the next audit. Everything that follows depends on getting this foundation clean.

  ## 2.What does Segregation of Duties mean in SCM?

 Segregation of Duties is the control that stops one person owning a whole transaction end to end. If the same user can create a supplier *and* approve that supplier’s invoices, they can invent a payee and pay them. If the same user can raise a purchase order *and* confirm its goods receipt, they can fabricate a delivery that never arrived.

 In IFS Cloud SCM the classic separations are:

 
- **Master data** vs **payment** - who creates a supplier is not who approves its invoices.
- **Order** vs **receipt** - who raises the PO is not who confirms the goods in.
- **Requisition** vs **approval** - who asks is not who authorises.
- **Inventory** vs **reconciliation** - who adjusts stock is not who counts it.

 SoD is not about distrust. It is a structural control that removes the opportunity, so a single mistake or a single bad actor cannot complete a fraudulent cycle alone.

  ## 3.Which SoD conflicts show up in audits?

 These are the combinations an auditor tests first. If one user holds both sides, it is a finding - whether or not anyone has abused it.

 
| Duty A | Duty B (conflicting) | Risk if combined | Severity |
| --- | --- | --- | --- |
| Create / edit supplier | Approve supplier invoice | Fictitious supplier paid by its own creator | High |
| Create purchase order | Register goods receipt | Phantom receipt against a self-raised order | High |
| Raise requisition | Approve requisition | Unauthorised spend self-approved | High |
| Approve invoice | Release payment | Full payment cycle controlled by one person | High |
| Adjust inventory | Perform stock count | Shrinkage hidden behind self-verified counts | Medium |
| Maintain price list | Approve purchase order | Inflated price set and approved unchecked | Medium |

 Build this into a documented **conflict matrix** before you design a single Permission Set. The matrix is the specification your roles must satisfy - and the checklist every audit will run against you.

  ## 4.How do custom objects bypass the security model?

 Here is the trap that turns a clean RBAC design into an audit failure. Your standard Permission Sets can be perfect, and a single custom object can still route around them. A custom projection that exposes purchase-order actions without inheriting the standard security, a Custom Event that writes an invoice status under a service account, an integration that runs with more rights than any human role - each is an invisible hole in the SoD model.

 This is why security and Clean Core are the same conversation. Every extension must be built inside the IFS Extensibility Framework and secured with the same Permission Sets as standard functionality - never with a bypass and never with a shared privileged account. If a custom object can do something a role cannot, your conflict matrix no longer means anything.

 Audit your custom objects against the same matrix as standard duties. The [Clean Core approach to IFS Cloud SCM](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) exists partly for this reason: update-safe extensions are also security-safe extensions, because they respect the standard model instead of working around it.

  ## 5.Get your permissions audited before someone else does

 A security review that maps your Permission Sets to a documented SoD matrix - standard and custom objects included - turns a future audit finding into a change you made on your own terms. I design and audit IFS Cloud RBAC and Segregation of Duties as an update-safe service, inside the standard model.

 [Book a 30-minute security call](https://www.ifs-erp.com/book-a-call) [See the security service](https://www.ifs-erp.com/offer)

  ## 6.A practical way to design and audit permissions

 Whether you are building fresh or cleaning up a live system, the same sequence works.

 
1. **Document the conflict matrix** - agree with finance and audit which duty pairs must never coincide.
2. **Define roles by job function** - one Permission Set per function, sized to least privilege, mapped to the matrix.
3. **Map users to roles** - assign only the sets a job needs; remove one-off individual grants.
4. **Test for conflicts** - check every user against the matrix; a single person holding both sides of any pair is a flag.
5. **Secure custom objects** - confirm every extension inherits standard Permission Sets and no bypass account exists.
6. **Re-audit on change** - every new role, joiner or release re-runs the matrix. Tie it into your upgrade routine.

 Fold the security re-check into your upgrade preparation so it is never skipped - the [IFS Cloud upgrade readiness checklist](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist) is the natural place for it. New projections and changed actions in a release can shift what a Permission Set actually grants.

  ## 7.Frequently asked questions

 What is the difference between RBAC and Segregation of Duties in IFS Cloud? RBAC is the mechanism: access is granted to Permission Sets (roles) which are assigned to users. Segregation of Duties is a policy you enforce through that mechanism: no single role or user may hold two conflicting duties, such as creating a supplier and approving its invoices. RBAC is how you grant; SoD is the rule about what you must never grant together.

   What are the most common SoD conflicts in IFS Cloud Purchasing? The highest-risk pairs are supplier creation combined with invoice approval, and purchase-order creation combined with goods receipt. Both let one person complete a payment cycle unchecked. Requisition raise with requisition approval, and invoice approval with payment release, are close behind. These are the first combinations an auditor tests.

   Can a custom object break my IFS Cloud security model? Yes. A custom projection, event or integration that does not inherit standard Permission Sets, or that runs under a shared privileged account, can perform actions your roles forbid. That is an invisible SoD hole. Build every extension inside the Extensibility Framework, secure it with the same Permission Sets as standard functionality, and audit it against your conflict matrix.

   How often should I audit IFS Cloud permissions? Re-run your SoD conflict matrix on every meaningful change: a new role, a joiner or mover, a new custom object, and every IFS Cloud release. Releases can add projections or change actions, which shifts what an existing Permission Set actually grants. Folding the check into upgrade preparation keeps it from being skipped.

  ## 8.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally. Independent practice - you talk to the consultant who does the security work, 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.

  ## Pass the audit on your own terms

 Tell me how your IFS Cloud roles are set up today. On a 30-minute call I’ll show you where the SoD conflicts sit - standard and custom - and how to close them inside the standard security model.

 [Book a 30-minute security call](https://www.ifs-erp.com/en/contact)


[Read more...](https://www.ifs-erp.com/blog/rbac-segregation-of-duties-ifs-cloud.md)

## IFS Cloud Upgrade Readiness 10-Point Checklist

Independent IFS Cloud practice · Upgrade readiness

 
## IFS Cloud upgrade readiness: a 10-point checklist before your next release

  **Key takeaways**

 
- An **IFS Cloud upgrade readiness checklist** turns a twice-yearly scramble into a controlled, predictable event.
- The work is front-loaded: inventory and classify every extension before the release lands, not after it breaks.
- The riskiest points are custom logic outside the framework, reports on volatile views, and integration contracts.
- Readiness is not only technical: a rollback plan, executive sign-off and a realistic timeline are part of it too.
- Work all ten points and the upgrade becomes a re-validation, not a rebuild.

  IFS Cloud moves forward on a fixed cadence, and each R1/R2 release can change the ground your customisations stand on. Teams that treat the upgrade as an event to be managed sail through it. Teams that treat it as something that happens *to* them pay the upgrade tax: broken flows, emergency hotfixes, a go-live that slips a fortnight. The difference is preparation. This checklist is the ten points to clear before you schedule the next release, so nothing on the far side surprises you.

  ## 1.Why do you need a readiness checklist?

 Because the expensive part of an IFS Cloud upgrade is not the upgrade itself. It is discovering, in the new version, what you should have found beforehand. The [IFS Cloud upgrade tax](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-tax) is paid almost entirely in things that were knowable in advance: an extension nobody realised reached into modified core, a report built on a view that changed, an integration wired to an interface IFS never promised to keep.

 A checklist converts that risk into a to-do list. Each point below is something you can inspect, decide on and sign off *before* the release is booked, while you still have time and before the deadline forces rushed decisions.

  ## 2.The 10-point IFS Cloud upgrade readiness checklist

 1. **Inventory every extension.** Build one list of all customisations, reports, integrations, custom events, workflows and modifications, including the orphans nobody owns. You cannot assess what you cannot see.
2. **Classify each one by risk.** Rate every item Safe, Refactor, Rewrite or Retire, based on whether it lives inside the Extensibility Framework or reaches outside it. This single step tells you where the upgrade tax will land.
3. **Check your custom events and workflows.** Confirm each event still binds to a supported entity and that its logic uses standard interfaces. Events that reach into internal packages are the ones that fail quietly after a release.
4. **Review Quick Reports on volatile views.** Reports built on database views that IFS may restructure are a classic silent break. Flag any Quick Report or SQL report reading from non-guaranteed views and plan to re-point or re-test them.
5. **Assess RBAC and Segregation of Duties exposure.** A new release can add, rename or reshape permission sets and projections. Confirm your role model and SoD rules still hold, so the upgrade does not quietly widen access.
6. **Verify integration and OData contracts.** List every inbound and outbound interface and confirm each uses a supported OData/REST projection, not an internal API. Check field mappings against the target version before, not after.
7. **Confirm test-environment parity.** Your test environment must mirror production: same configuration, same data shape, same integrations connected. A dry run against a stale copy proves nothing.
8. **Write a rollback plan.** Decide, in advance and in writing, how you revert if the upgrade fails validation: backup points, cut-over window and the exact trigger that says “stop and roll back”.
9. **Get executive sign-off.** One named owner accepts the plan, the risk classification and the go/no-go criteria. Readiness without accountability is a wish, not a plan.
10. **Lock a realistic timeline.** Sequence inventory, remediation, dry run, re-test and go-live with slack built in. A timeline that assumes nothing breaks is the one most likely to slip.

 Work these ten points in order and the pattern is clear: the first two find the risk, the middle six remove it, the last two make sure someone owns the outcome.

  ## 3.Where do teams get caught out?

 The same three points catch most teams, every release. Knowing them in advance is half the battle.

 
| Blind spot | Why it bites | Checklist point |
| --- | --- | --- |
| Reports on volatile views | A restructured view returns wrong data or errors. Nobody notices until a decision already depends on it | Point 4 |
| Silent RBAC drift | New or reshaped permission sets widen access, breaking Segregation of Duties without any error | Point 5 |
| Integration contracts | An interface wired to an internal API stops exchanging messages; the queue backs up unseen | Point 6 |

 RBAC drift is the quietest of the three: it throws no error, and access simply widens. If your SoD model matters for audit or compliance, treat the upgrade as a moment to re-prove it. The mechanics are covered in [RBAC and Segregation of Duties in IFS Cloud](https://www.ifs-erp.com/blog/rbac-segregation-of-duties-ifs-cloud).

  ## 4.How do you make readiness permanent?

 A checklist you run once is useful. A checklist you never need to run is better. The durable fix is to stop generating upgrade risk in the first place: keep every extension inside the supported framework so there is nothing on the far side of the line to break.

 
- Build automation with Custom Events and Workflows, never modified core
- Read reports from supported, stable projections rather than volatile views
- Wire integrations to versioned OData/REST, not internal APIs
- Enforce access through RBAC and SoD, reviewed each release

 That is the Clean Core discipline. It is the same one behind [Clean Core IFS Cloud supply chain automation](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm). Apply it to everything you build and the checklist shrinks to a re-validation, release after release.

 [SCM Exception Scan for IFS Cloud](https://www.ifs-erp.com/en/applications/scm-exception-scan) [Book a 30-minute call](https://ifs-erp.consulting/contact)

  ## 5.Frequently asked questions

 When should I start the IFS Cloud upgrade readiness checklist? Before the release is booked, not after. The first two points, inventory and risk classification, take real calendar time, and everything else depends on them. Starting early means remediation and a proper dry run happen without deadline pressure, which is where rushed upgrades go wrong.

   Which checklist point catches the most teams out? Reports on volatile views and silent RBAC drift. Both fail without throwing an obvious error: a report returns wrong data, or access quietly widens and breaks Segregation of Duties. Because there is no error to chase, they are often discovered only after a decision or an audit depends on them.

   Do I really need a rollback plan if the upgrade usually works? Yes. A rollback plan is cheap insurance you write once and hope never to use. It defines your backup points, cut-over window and the exact trigger to stop and revert. Without it, a failed validation turns into an unplanned outage while people improvise under pressure.

   Can I run this checklist myself, or do I need help? You can run it yourself if you have a clear view of every extension and how it is built. If that inventory is fuzzy, or if nobody owns the older customisations, the Update-Safe Audit does points one and two for you in 10 business days, classifying each extension Safe / Refactor / Rewrite / Retire with a fixed-price roadmap.

  ## 6.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, 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.

  ## Walk into your next release ready

 The first two points of this checklist matter most, and they are the ones teams skip. The Update-Safe Audit does them for you in 10 business days: every extension classified, a fixed-price roadmap, and the fee credited against the fix.

 [Start the Update-Safe Audit](https://www.ifs-erp.com/update-safe-audit)


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist.md)

## IFS Quick Reports vs Custom Fields vs Custom Events

Independent IFS Cloud practice · Extensibility

 
## IFS Quick Reports vs Custom Fields vs Custom Events: when to use what in IFS Cloud

 **IFS Quick Reports, Custom Fields and Custom Events** are the three workhorses of the IFS Cloud Extensibility Framework. Reach for the wrong one and you get a report that times out, a field nobody trusts, or an automation that fires when it should not. Reach for the right one and you extend IFS without touching the core.

 **Key takeaways**

 
- **Quick Reports** read data out — fast SQL-based lists and extracts, but no logic and no data capture.
- **Custom Fields** store new data on existing records — when standard IFS has no place to put your attribute.
- **Custom Events** do something when data changes — alerts, workflows and automation triggered by inserts or updates.
- All three are update-safe when used inside the Extensibility Framework; a full modification is the last resort, not the first.
- The common mistakes are Quick Reports on volatile views and over-using modifications where a Custom Field or Event would do.

 Most IFS Cloud requests come dressed as “can we just add a report / a field / a little automation?” The tool you pick decides whether that request stays update-safe or turns into an upgrade tax. Here is a clear way to choose.

  ## 1.What is each tool, in one line?

 - **Quick Report** — a saved SQL query surfaced in the client, for reading and extracting data. It answers “show me a list of…”.
- **Custom Field** — a new attribute added to an existing entity, stored and shown by IFS. It answers “where do we record…?”.
- **Custom Event** — a trigger that watches for an insert or update and fires an action or workflow. It answers “when X happens, do Y”. See [Custom Events explained](https://www.ifs-erp.com/blog/ifs-custom-events-explained).

 They are complementary, not competing. A mature solution often uses all three: a Custom Field to capture data, a Custom Event to react to it, and a Quick Report to read it back out. The skill is knowing which job belongs to which tool.

  ## 2.What is each good and bad at?

 | Tool | Good at | Bad at / avoid |
| --- | --- | --- |
| Quick Reports | Fast lists, extracts, ad-hoc data pulls; quick to build; no deployment | No logic or automation; no data capture; heavy queries on volatile views hurt performance |
| Custom Fields | Storing a new attribute on a standard record; visible, searchable, reportable | Not for behaviour or calculations; sprawl if ungoverned; can bloat pages and APIs |
| Custom Events | Alerts, approvals, workflow and automation on data changes; reacts in real time | Not for reporting; poorly scoped events fire too often; need dry-run and frequency caps |

  ## 3.Decision matrix: which tool for which need?

 Match the need on the left to the recommended tool on the right.

 
| Your need | Recommended tool | Why |
| --- | --- | --- |
| See a list of open POs past due | **Quick Report** | Read-only extract; no logic needed |
| Record a custom “inspection status” on a part | **Custom Field** | New attribute on a standard record |
| Alert a buyer when a supplier price jumps | **Custom Event** | Act when data changes, in real time |
| Email a planner nightly with low-stock parts | **Quick Report** (scheduled) | Recurring read-out, no per-record trigger |
| Flag & hold an order that breaks a rule | **Custom Event** | Condition + action on the transaction |
| Capture data *and* react to it | **Field + Event** | Store the attribute, then trigger on it |
| Complex server-side logic across entities | **Modification** (last resort) | Only when the framework genuinely cannot; keep it Clean Core |

 Rule of thumb: reading → Quick Report; storing → Custom Field; reacting → Custom Event. A modification is what you reach for only when none of those three can do the job.

  ## 4.Update-safety, performance and governance

 All three tools live inside the Extensibility Framework, so all three are **update-safe** by design — they survive each R1/R2 release instead of breaking. That is the whole [Clean Core](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) argument: extend IFS without editing it. But update-safe is not the same as consequence-free.

 
- **Performance** — Quick Reports run live SQL; a heavy query on a busy or volatile view can slow the client for everyone. Scope, filter and, where possible, target stable views.
- **Field sprawl** — ungoverned Custom Fields multiply, bloat pages and APIs, and leave nobody sure which field is authoritative. Name, document and own them.
- **Event storms** — a broadly scoped Custom Event can fire far more often than intended. Use conditions, a dry-run week and a frequency cap.
- **Governance** — who can create these, who reviews them, and where they are documented matters as much as the build. Ungoverned extensibility becomes its own kind of technical debt.

  ## 5.Common mistakes to avoid

 1. **Quick Reports on volatile views** — building heavy extracts on high-churn or derived views. They are slow, they can lock, and the numbers move under you. Prefer stable, well-filtered sources.
2. **Using a report where you needed an event** — a nightly report cannot stop a bad transaction; by the time it runs, the price already posted. If timing matters, use a Custom Event.
3. **Over-using modifications** — jumping to server-side code when a Custom Field or Event would do. Every unnecessary modification is a future upgrade tax.
4. **Custom Field sprawl** — adding fields with no naming standard, owner or documentation until nobody trusts the data.
5. **Un-capped events in production** — going live without a dry-run week or frequency cap, then drowning users in alerts on the first bulk load.

 Get these choices right and extensibility stays a strength. Get them wrong and you rebuild the same upgrade tax the framework exists to prevent. For the wider pattern of doing this well, see [how to automate SCM processes in IFS Cloud](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud).

 [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack) [See the full offer](https://www.ifs-erp.com/offer)

  ## 6.Frequently asked questions

 What is the difference between a Quick Report and a Custom Event in IFS Cloud? A Quick Report reads data out — it is a saved SQL query for lists and extracts, with no logic. A Custom Event reacts to data changing — it watches for an insert or update and fires an alert, workflow or action. Reporting is passive and on-demand; events are active and real-time.

   When should I use a Custom Field instead of a modification? Use a Custom Field whenever you only need to store a new attribute on a standard record — it is update-safe and needs no core change. Reserve a modification for genuine server-side logic the Extensibility Framework cannot express. Reaching for a modification first is the most common way to create an upgrade tax.

   Are Quick Reports, Custom Fields and Custom Events update-safe? Yes. All three are part of the IFS Cloud Extensibility Framework and are designed to survive each R1/R2 release without breaking. That is the Clean Core principle: extend IFS rather than edit it. Governance still matters — performance, field sprawl and event scope are your responsibility, not the framework’s.

   Why are Quick Reports on volatile views a problem? Quick Reports run live SQL against the database. On a high-churn or heavily derived view, a large query can be slow, can contend with transactional work, and can return numbers that shift while it runs. Target stable, well-filtered sources, and if you need to act on a change rather than list it, use a Custom Event instead.

  ## 7.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally as an independent practice — 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.

  ## Not sure which tool your requirement needs?

 Bring me the request — a report, a field, a bit of automation — and on a 30-minute fit call I’ll tell you which update-safe tool fits and what it costs to build. No modification unless it is genuinely the only way.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/quick-reports-custom-fields-custom-events.md)

## IFS Cloud Data Migration: FndMig & DMM Field Guide

Independent IFS Cloud practice · Data Migration

 
## IFS Cloud data migration with FndMig and DMM: a practical field guide

 Migration is the phase that quietly sinks IFS Cloud projects. It is the least documented, the hardest to rehearse and the first thing blamed when go-live slips. This guide covers what FndMig and the Data Migration Manager (DMM) are each for, a load sequence that respects supply-chain dependencies, and the validation that keeps bad data out of production.

 ## Key takeaways

 **Key takeaways**

 
- Migration is the riskiest, least-documented phase of any IFS Cloud project — budget for it like an implementation, not a data dump.
- FndMig is the low-level foundation loader; DMM is the governed, mapped, auditable layer on top — use them for different jobs.
- Load order follows referential dependencies: suppliers and customers before parts, parts before part–supplier, masters before open transactions.
- Validate before and after every load — referential integrity, duplicates, completeness — and reconcile counts and balances back to the source.
- Rehearse the full cutover at least twice, with a tested rollback, before the real one.

  ## 1.Why is data migration the riskiest phase?

 Configuration is visible. Reports are visible. Migration is not — until the day a buyer opens a purchase order that points at a supplier who does not exist, or finance runs a trial balance that is off by the value of every open invoice you failed to load. By then the project is in production and the fix is a firefight.

 Three things make migration uniquely dangerous. First, it is **poorly documented**: IFS ships the tooling, but the mapping from your legacy model to the IFS data model is yours to work out, object by object. Second, it is **deeply interdependent**: an IFS Cloud *part* cannot stand alone — it needs inventory part data, part–supplier links, units of measure and cost sets, all in the right order. Third, it is **tested last**, when there is least time to react.

 Treat migration as its own workstream with its own plan, not an afterthought bolted to the end of the build. If you are still scoping the wider project, read the [IFS Cloud upgrade readiness checklist](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist) first — migration readiness is a large part of overall readiness.

  ## 2.FndMig vs Data Migration Manager: what is each for?

 IFS gives you two mechanisms, and the mistake is treating them as rivals. They sit at different levels.

 
| Aspect | FndMig (Foundation migration) | Data Migration Manager (DMM) |
| --- | --- | --- |
| What it is | Low-level, foundation-layer load engine that writes through the standard API layer. | A governed migration workbench — jobs, templates, mappings and validation on top. |
| Best for | Bulk foundation and reference data, technically-owned loads, scripted repeatability. | Business-owned object loads with mapping, transformation and an audit trail. |
| Validation | Relies on the underlying API business logic to reject bad rows. | Adds staging, pre-load checks and per-row status you can triage. |
| Auditability | As good as your scripts and logs. | Built-in run history, error reporting and re-run of failed rows. |
| Who runs it | Technical consultant / DBA. | Migration lead with business data owners. |

 Rule of thumb: because both routes write through standard IFS APIs, your data is validated by the same business logic that guards manual entry. That is the point — you are not bypassing IFS, you are feeding it at scale. Nothing here touches core, which keeps the whole project inside [Clean Core](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) discipline.

  ## 3.What is a safe SCM object load sequence?

 Order is not a preference — it is dictated by referential integrity. Every object below depends on the ones above it. Load out of order and the API will reject the row, or worse, accept an orphan.

 
1. **Suppliers** — the supply-chain anchor. Address, payment and tax data must be complete before anything references them.
2. **Customers** — loaded alongside suppliers; both are masters that open transactions will point at.
3. **Parts** — part master, then inventory part per site. Units of measure and part types must already exist.
4. **Part–supplier** — the link that makes a part purchasable. Needs both the part and the supplier already loaded.
5. **Price lists** — supplier price data and sales price lists, so transactions price correctly.
6. **Open purchase orders** — only genuinely open lines. Confirm quantities and expected receipts against the source.
7. **Open sales orders** — same discipline; do not migrate fully-delivered or cancelled lines.
8. **Inventory balances** — on-hand quantities by location, lot and serial, valued against the cost set.
9. **Open invoices** — supplier and customer open items, reconciled to the ledger control totals.

 Freeze each layer before starting the next. Loading open POs before the part–supplier link exists is the single most common cause of a stalled cutover.

  ## 4.How do you validate before and after each load?

 Validation is not one gate at the end. It is a gate before every load and a gate after it. Three questions run through all of them.

 
- **Referential integrity** — does every foreign key resolve? No PO line without a part, no part–supplier without a supplier, no invoice without a customer.
- **Duplicates** — are supplier, customer and part identifiers unique after de-duplication? Merge in the source, not in IFS.
- **Completeness** — do row counts and control totals reconcile back to the legacy extract? Inventory value and open-invoice balances must match the ledger.

 Pre-load validation runs against the staging data and stops bad rows before they hit the API. Post-load validation proves what actually landed: count-in versus count-out, sampled record inspection, and a business sign-off from the data owner — the buyer confirms the POs, finance confirms the balances. Automate the reconciliation queries once and re-run them on every rehearsal.

  ## 5.Get the migration run by someone who has done it

 A migration that reconciles on the first go-live is worth more than any amount of clever configuration. I plan the object model, build the FndMig and DMM loads, write the reconciliation, and rehearse the cutover with your team until it is boring — which is exactly how it should feel on the day.

 [Book a 30-minute migration call](https://www.ifs-erp.com/book-a-call) [See the data migration service](https://www.ifs-erp.com/offer)

  ## 6.Rehearsal, rollback and the common failure modes

 Rehearse the full cutover end to end at least twice against a production-like copy. Time every load, record the total window, and confirm the sequence and the reconciliation on real volumes — not a sample. The rehearsal is where you discover that inventory takes four hours, not forty minutes.

 Have a **tested rollback**. That normally means a restore point or snapshot taken immediately before the load window, plus a documented decision rule: what has to reconcile by when, or you restore and try again at the next window. A rollback you have never tested is a hope, not a plan.

 The failure modes repeat across projects:

 
- Loading transactions before masters — orphaned rows.
- Migrating closed or cancelled orders as if open.
- Duplicate suppliers or parts merged too late.
- Inventory value that will not tie to the ledger.
- No reconciliation, so nobody can prove completeness.
- A cutover window guessed, never rehearsed.

  ## 7.Frequently asked questions

 Should I use FndMig or DMM for IFS Cloud data migration? Use both, for different jobs. FndMig is the low-level foundation loader for bulk reference data and scripted, technically-owned loads. The Data Migration Manager adds staging, mapping, per-row validation and an audit trail, which suits business-owned objects like open orders and invoices. Both write through standard IFS APIs, so both are validated by the same business logic.

   What is the correct load order for IFS Cloud SCM data? Follow referential dependencies: suppliers and customers first, then parts, then the part–supplier link, then price lists. Only after the masters are in place do you load open purchase orders, open sales orders, inventory balances and open invoices. Freeze each layer before starting the next.

   How do I know a migration is complete and correct? Reconcile counts and control totals back to the source extract, not just to the loader log. Row counts must match, inventory value and open-invoice balances must tie to the ledger, and a business data owner must sign off on a sample. Run the same reconciliation queries on every rehearsal so the final run is proven, not hoped.

   How many migration rehearsals do I need? At least two full end-to-end rehearsals against a production-like copy, on real volumes. The rehearsals establish the true cutover window, confirm the sequence and reconciliation, and prove the rollback. If a rehearsal fails to reconcile, fix it and rehearse again before committing to a go-live date.

  ## 8.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally. Independent practice — you talk to the consultant who runs the migration, 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.

  ## Make cutover the boring part

 Tell me what you are migrating from and when go-live is. On a 30-minute call I’ll map the object sequence, the validation gates and the rollback — so the day itself holds no surprises.

 [Book a 30-minute migration call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/ifs-data-migration-fndmig-dmm.md)

## Catch Supplier Price Changes in IFS Cloud Before They Post

Independent IFS Cloud practice · Supply Chain

 
# Supplier price creep in IFS Cloud: catch a supplier price change before it posts

 A **supplier price change in IFS Cloud** rarely arrives as a warning. It arrives quietly — a new purchase part price, an edited supplier-for-part record, a renewed blanket agreement — and it flows straight onto the next purchase order at the higher number. This is how margin leaks one line at a time.

  **Key takeaways**

 
- Price increases enter IFS Cloud through purchase part costs, supplier-for-part prices and blanket agreements — usually without anyone approving the delta.
- By the time a buyer notices, the higher price is already on live POs and eroding margin on every order.
- IFS Cloud stores enough history to detect a change above a percentage or absolute threshold — you just have to watch for it.
- A Custom Event can compare old versus new price and alert or hold *before* the change reaches new purchase orders.
- Roll it out update-safe: threshold, dry-run, approval step, frequency cap — no core modification.

  ## 1.How does a supplier price increase slip through IFS Cloud?

 There is no single “price” in IFS Cloud — there are several, and a supplier increase can land on any of them. Each one feeds the next purchase order without a mandatory checkpoint on the amount:

 
- **Purchase part cost** — the standard or estimated cost on the part record; edited during a routine cost update, it silently repriced everything that reads it.
- **Supplier-for-part price** — the supplier-specific price and price breaks; a buyer accepts a new list from the vendor and keys it in, delta unchecked.
- **Blanket / agreement prices** — a renewed blanket purchase agreement carries new pricing that then defaults onto every release against it.
- **PO line entry** — the default price populates the line, the buyer confirms, and nobody compares it with what was paid last time.

 The common thread: IFS Cloud accepts a 12 % increase the same way it accepts a 0.5 % one. Standard IFS does not, out of the box, stop and ask “is this jump intentional?” That is where automation earns its keep. If you have already tackled [unconfirmed purchase orders](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs), this is the same class of gap — a control that depends on a human remembering.

  ## 2.Why small price creep is a big margin problem

 Individually, a few percent looks harmless. Multiplied across order lines, quantities and a full year, it is one of the quietest ways a business loses gross margin. A supplier who nudges prices up 3–5 % at renewal, on a part you buy in volume, moves real money — and because the increase is spread over many small transactions, it never triggers the scrutiny a single large invoice would.

 The danger is not the one big increase you notice. It is the steady creep you do not — because no single line ever looks wrong enough to question.

 Price creep also corrupts everything downstream: cost variances, planned purchase values and next year’s budget baseline all inherit the higher number as if it were normal. Catching the change at the source is far cheaper than unwinding it later.

  ## 3.How do you detect a supplier price change above a threshold in IFS Cloud?

 The good news: IFS Cloud already holds the data you need. The supplier-for-part and agreement records carry the current price; the change itself is an update to a known value. Detection is simply comparing the new price against the previous one and testing the delta against a rule you define. In practice you decide three things:

 
| Decision | What you set | Example |
| --- | --- | --- |
| Threshold type | Percentage delta, absolute delta, or both | > 5 % *or* > €50 per unit |
| Scope | Which price records and which suppliers/parts to watch | A-class parts & strategic suppliers first |
| Action | Alert only, require approval, or hold the change | Alert buyer + planner; hold above 15 % |

 You can approximate this with a report or Quick Report that lists recent price changes — useful, but reactive: it tells you after the fact, on whatever cadence someone runs it. To catch the change *before* it posts to new POs, you need an event that fires the moment the price record changes.

  ## 4.An update-safe Custom Event that flags the change before it posts

 A [Custom Event](https://www.ifs-erp.com/blog/ifs-custom-events-explained) is standard IFS Cloud functionality: it watches a table for an insert or update, checks a condition, and fires an action — all inside the Extensibility Framework, with no core modification. That makes it the right tool for price creep, because it reacts at the source the instant a supplier price is changed.

 
1. The event listens for an **update** to the supplier-for-part (or agreement) price.
2. It reads the **old value and the new value** and computes the delta.
3. If the delta breaches your **threshold**, it fires — otherwise it stays silent.
4. The action **alerts** the buyer and planner, and where policy requires, routes the change for **approval** or flags the record so the higher price does not quietly default onto new PO lines.

 Because the event triggers on the price change itself, the alert lands **before** the increase reaches the next purchase order — while it can still be questioned, not after it has posted to a dozen lines.

 This is one of the twelve scenarios in the **SCM Automation Pack**. It is part of a broader pattern — see [how to automate SCM processes in IFS Cloud](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud) — where the system, not a buyer’s memory, holds the control.

 [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack) [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)

  ## 5.Thresholds, approvals and a safe rollout

 An over-eager price alert is as useless as no alert — if it fires on every rounding change, people stop reading it. The rollout matters as much as the logic:

 
- **Start narrow** — high-value parts and strategic suppliers, a sensible threshold, then widen.
- **Dry-run first** — log what *would* have fired for a test week before anyone gets a single alert.
- **Frequency cap** — protect against alert storms during bulk price loads.
- **Approval tier** — alert for small deltas, require sign-off for large ones.
- **Tune thresholds** — review the false positives after week one and adjust.
- **Stay update-safe** — standard Custom Events only, so the next upgrade leaves it intact.

 Every scenario in the pack ships with dry-run mode and a frequency cap by default, and a mandatory test week before go-live — so the control earns trust before it earns the right to hold a purchase order.

  ## 6.Frequently asked questions

 Where do supplier price changes enter IFS Cloud? Mainly through the purchase part cost, the supplier-for-part price and its price breaks, and blanket or agreement prices. A renewed agreement or an edited supplier price then defaults onto the next purchase order line. None of these paths forces anyone to approve the size of the increase.

   Can IFS Cloud alert me before a price increase reaches a purchase order? Yes. A Custom Event can fire the moment a supplier price record is updated, compare the old and new values, and alert or hold when the delta breaches your threshold. Because it reacts at the source, the alert arrives before the higher price defaults onto new PO lines — while the change can still be questioned.

   What threshold should I use for a price-change alert? Use a percentage delta, an absolute per-unit delta, or both, and start conservatively on your high-value parts and strategic suppliers. Many teams alert above about 5 % and require approval above roughly 15 %, then tune after a dry-run week. The right numbers depend on your categories and volatility.

   Is a price-change Custom Event update-safe? Yes, when it is built strictly inside the IFS Extensibility Framework using standard Custom Events and Workflows — no core modification. That is the whole point of a Clean Core approach: the automation survives each R1/R2 release instead of breaking and becoming an upgrade tax.

  ## 7.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally as an independent practice — 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.

  ## Stop paying for price creep you never approved

 Tell me which parts and suppliers worry you most. On a 30-minute fit call I’ll show you how the price-change scenario in the SCM Automation Pack would flag them — with a fixed price and a dry-run week before anything holds a live order.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/supplier-price-changes-ifs-cloud.md)

## Unconfirmed Purchase Orders in IFS — The Silent Fix

Independent IFS Cloud practice · Supply Chain

 
# Unconfirmed purchase orders in IFS: the silent margin leak — and the automated fix

 **Key takeaways**

 
- An **unconfirmed purchase order in IFS** is an order the supplier may never have acknowledged — you discover it only when the goods do not arrive.
- The cost is a slow leak: late deliveries, expediting fees, stock-outs and eroded margin, none of it labelled on the P&L.
- They pile up because confirmation is a manual chase — skipped when buyers are busy, invisible until it hurts.
- A Custom Event escalation — supplier email plus buyer alert after X days, with dry-run and a frequency cap — closes the gap and stays update-safe.

 Every purchasing team has them: purchase orders raised, sent, and then sitting unacknowledged. On the screen they look like progress. In reality an **unconfirmed purchase order in IFS** is a promise nobody on the supplier side has agreed to. The order may be in a queue, misrouted, or simply unseen — and because the record shows the order exists, everyone assumes it is in motion. The truth surfaces at the worst moment: the line stops, the customer chases, and the buyer is now expediting at a premium to recover a week that was lost silently. This article covers why they accumulate, what they actually cost, how to detect them, and how to automate the fix without creating an alert storm.

  ## 1.Why do unconfirmed POs pile up?

 Order confirmation is treated as the supplier’s job, so no one on your side owns the follow-up. When a supplier does not acknowledge, the omission is invisible — there is no error, no red screen, just a field that stays empty. Buyers who are meant to check it are the same people fighting today’s fires, so the check is the first thing dropped on a busy morning.

 Volume makes it worse. A buyer managing hundreds of open lines cannot eyeball which handful never came back confirmed. Across sites and buyers the discipline varies, and there is no record of who checked what. The result is a slowly growing pool of orders that *look* live but may not be moving at all.

  ## 2.What does an unconfirmed PO actually cost?

 The damage is downstream, which is why it is easy to miss the cause. A confirmation gap converts, step by step, into hard money:

 
- **Late deliveries.** A day lost to a silent order is a day added to lead time you did not plan for.
- **Expediting.** Recovering the lost time means premium freight and rush fees — margin spent to fix a check that took seconds.
- **Stock-outs.** Goods that arrive late arrive after you needed them, stopping a line or a shipment.
- **Margin erosion.** The expedite fee, the idle line and the unhappy customer all land on the same order — and none of it is labelled “unconfirmed PO”.

 The leak is silent precisely because the cost never appears next to the cause. You see the freight bill; you do not see the missed confirmation that caused it.

  ## 3.How do you detect them in IFS?

 The data is already in IFS. A purchase order carries its state and its dates, so an unconfirmed order is simply one that has passed a sensible age without a confirmation recorded against it. You can surface that today by filtering open purchase orders on state and order age — anything released but unconfirmed beyond, say, three to five days is your working list.

 That manual query is a fine start and a poor system of record. It only helps on the days someone remembers to run it, it has no owner, and it leaves no audit trail of who was chased and when. Detection you have to remember to perform is detection that fails on the busy days — which are exactly the days it matters most.

  ## 4.Manual chase versus automated escalation

 The automated approach uses a standard **Custom Event**: it watches for orders that stay unconfirmed past a threshold and fires an action — an email to the supplier and an alert to the buyer — without anyone running a report. It is the same trigger-and-action pattern behind every scenario in the [SCM automations for IFS Cloud](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud), and the mechanics are covered in [Custom Events in IFS Cloud, explained](https://www.ifs-erp.com/blog/ifs-custom-events-explained).

 
|   | Manual chase | Automated escalation |
| --- | --- | --- |
| Runs when | Someone remembers | Continuously, on schedule |
| Coverage | Whatever the buyer had time for | Every order, every site |
| Owner | Unclear | Buyer, by rule |
| Audit trail | None | Logged action per order |
| Fails when | Busy, holidays, sick leave | Never sleeps |

 Two controls keep the automation safe. A **dry-run mode** logs every message that *would* be sent, so you validate the list before a single email reaches a supplier. A **frequency cap** ensures one stuck order escalates once, then respects a cool-down — never the same supplier ten times in a day. The same discipline protects related rules such as [supplier price-change alerts](https://www.ifs-erp.com/blog/supplier-price-changes-ifs-cloud).

  ## 5.How do you roll it out safely?

 Do it in order, and let the data set the thresholds rather than a guess.

 
1. **Agree the threshold.** Pick the day count and states that define “unconfirmed” for your suppliers — different categories may warrant different limits.
2. **Run in dry-run.** Let the event log its would-be actions for a test week. Read the list; it usually reveals the true scale for the first time.
3. **Tune recipients and cap.** Confirm who is emailed and who is alerted, and set the frequency cap so escalations inform rather than nag.
4. **Go live on a subset.** Enable for one buyer or site, watch a cycle, then widen once behaviour is proven.
5. **Review and adjust.** After a month, check what fired and what changed — thresholds are settings, not stone.

 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.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call) [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 What counts as an unconfirmed purchase order in IFS? It is a released order with no supplier confirmation recorded against it after a reasonable age — typically a few days. The order looks active on screen, but nobody on the supplier side has acknowledged it, so there is no guarantee it is being worked.

   How many days should trigger an escalation? There is no universal number. Three to five days suits many suppliers, but critical or long-lead categories may warrant tighter limits. The dry-run week shows your real distribution, so you set the threshold on evidence rather than a guess.

   Will suppliers be annoyed by automated emails? Not if it is capped. The frequency cap means each stuck order escalates once and then waits out a cool-down, so no supplier is chased repeatedly. Most suppliers welcome a clear, timely nudge over a frantic call once the goods are already late.

   Is this update-safe? Yes. The escalation 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.

  ## 7.About the author

 **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.

  ## Stop the silent leak

 If you suspect unconfirmed orders are costing you and cannot yet prove it, a dry-run week will show you the scale for the first time. On a 30-minute fit call I’ll map the escalation to your suppliers — fixed price, dry-run before anything sends.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs.md)

## 12 Supply-Chain Processes to Automate in IFS Cloud

Independent IFS Cloud practice · Supply Chain

 
# 12 supply-chain processes you can automate in IFS Cloud today

 **Key takeaways**

 
- Most supply-chain firefighting in IFS Cloud is a missed signal, not a missing feature — the data is already there, nobody is watching it.
- Twelve concrete scenarios across Purchasing, Requisitions, Inventory and Invoicing can each be automated with a standard **trigger → action** pattern.
- Built inside the IFS Extensibility Framework (Custom Events, Workflows, PL/SQL), automation stays update-safe — it does not break at the next release.
- Every scenario ships with a dry-run mode and a frequency cap, so you never trade manual gaps for an alert storm.

 If your buyers spend the first hour of every day running the same handful of screens — unconfirmed orders, overdue deliveries, invoices in hold — you are paying people to be a monitoring system. That is expensive, it is inconsistent, and it fails exactly when it matters: month-end, holidays, a buyer off sick. The good news is that when you **automate SCM in IFS Cloud**, you are not building anything exotic. You are asking the system to watch the data it already holds and to raise its hand the moment a number crosses a line you set. Below are twelve processes worth handing over first.

  ## 1.Why automate supply-chain checks at all?

 A manual check has three failure modes. It is skipped when people are busy, it is applied unevenly across buyers and sites, and it produces no record that anyone can audit later. The cost is rarely a single dramatic event — it is a steady leak: an expedite fee here, a stock-out there, a price rise nobody queried, an invoice that sat in hold past its discount window. None of it shows up as a line on the P&L called “things we forgot to check”.

 Automation removes the human from the *detection* step, not the decision. The system watches continuously and consistently, then routes a specific signal to the person who can act. In IFS Cloud that detection layer is a **Custom Event** — a standard mechanism that fires when a row changes or on a schedule. If you want the full mechanics of how that works, see [Custom Events in IFS Cloud, explained](https://www.ifs-erp.com/blog/ifs-custom-events-explained).

  ## 2.The pattern: trigger → action → value

 Every scenario below follows the same shape. A **trigger** is a condition in your data — an order still unconfirmed after five days, a stock balance below its safety level. An **action** is the response — an email to the supplier, an alert to the buyer, a task in the buyer’s inbox, a flag on the record. The **value** is the cost you stop paying. Get those three right and the automation almost writes itself.

 Two safety rails matter more than any single scenario: a **dry-run mode** that logs what *would* have fired before you send anything to a supplier, and a **frequency cap** so one stuck order cannot email a supplier every hour for a week.

  ## 3.The twelve processes, with trigger and value

 The scenarios split across four areas. None requires a core modification; all are read-and-notify or read-and-flag patterns built on standard events.

 
| # | Trigger → action | Business value |
| --- | --- | --- |
| 1 | **Unconfirmed PO escalation.** Order not confirmed after X days → email supplier, alert buyer. | Kills the silent gap between “ordered” and “the supplier actually saw it”. |
| 2 | **Supplier price change above threshold.** Incoming price differs from agreement by more than X% → hold and notify buyer. | Stops price creep entering costs unchallenged. |
| 3 | **Delivery date overdue.** Promised receipt date passed with no receipt → alert buyer with the open quantity. | Catches late deliveries before the line stops, not after. |
| 4 | **Stock below minimum.** On-hand drops under safety stock → notify planner, optionally raise a requisition draft. | Turns stock-outs into a proactive re-order signal. |
| 5 | **Invoice in hold.** Supplier invoice enters a hold state → route to the owner with the reason code. | Protects early-payment discounts and supplier relations. |
| 6 | **Requisition without approval.** Requisition sits unapproved past a limit → escalate to the approver’s manager. | Removes the bottleneck where purchasing quietly stalls. |
| 7 | **Receipt vs order quantity mismatch.** Received quantity differs from ordered beyond tolerance → flag for the buyer. | Surfaces short and over-deliveries before invoicing. |
| 8 | **GR/IR ageing.** Goods-received / invoice-received item open beyond X days → report to finance and the buyer. | Clears the reconciliation backlog that hides at period-end. |
| 9 | **Blocked / obsolete part on open orders.** A part is blocked or made obsolete while orders are open → alert the owner. | Prevents ordering against parts you can no longer use. |
| 10 | **SO line without coverage.** Sales-order line has no supply to meet it → notify planning with the shortfall. | Exposes promises you cannot yet keep. |
| 11 | **Supplier lead-time breach trend.** A supplier repeatedly beats or misses its stated lead time → trend report to procurement. | Feeds evidence into planning parameters and reviews. |
| 12 | **Credit-limit breach on new SO.** New sales order pushes a customer over its credit limit → hold and alert credit control. | Stops shipping into unrecoverable exposure. |

 These ship together as the **SCM Automation Pack**. The exact set, thresholds and recipients are agreed at scoping — your process, your limits.

  ## 4.Two worth a closer look

 **Unconfirmed purchase orders (1).** This is the one most buyers underrate. An order that is never acknowledged is an order the supplier may not be working — and you find out only when the goods do not arrive. An escalation that emails the supplier and pings the buyer after a set number of days closes that gap for almost no effort. It earns its place first for most clients; the full case is in [unconfirmed purchase orders in IFS](https://www.ifs-erp.com/blog/unconfirmed-purchase-orders-ifs).

 **Supplier price change above threshold (2).** Prices drift upward one order at a time, each rise small enough to pass unread. A rule that holds any incoming price more than a set percentage above the agreement, and routes it to the buyer, forces a decision instead of a default. The mechanics — where to read the agreed price, how to set tolerance — are covered in [supplier price changes in IFS Cloud](https://www.ifs-erp.com/blog/supplier-price-changes-ifs-cloud).

  ## 5.Will this survive the next upgrade?

 Yes — because none of it touches core code. Every scenario is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework. That is the whole point of the Clean Core approach: you get the automation without the *upgrade tax* — the customisations that break every R1/R2 release and turn each upgrade into a remediation project. When you stay inside the framework, the next release finds nothing of yours to break.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call) [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Frequently asked questions

 Do I need all twelve automations? No. Most clients start with two or three that map to their sharpest pain — usually unconfirmed POs, price changes and invoices in hold — and add more as trust builds. The pack is a menu agreed at scoping, not a fixed twelve you must take whole.

   Will automated emails flood my suppliers? No. Every scenario has a frequency cap, so a single stuck order cannot re-send day after day, and a dry-run mode that logs what would have gone out before anything reaches a supplier. You tune the thresholds during a mandatory test week before go-live.

   Does this work on IFS Cloud and older Apps versions? The pack targets current IFS Cloud, where Custom Events and Workflows are the native automation layer. The same trigger-and-action thinking applies to Apps 9 and 10, though the build details differ; that is worth a short scoping call.

   How long does it take to go live? The files import quickly; the guided go-live is a single assisted day to configure thresholds and recipients to your process, followed by a test week in dry-run before anything acts in production. You are live within days, not months.

  ## 7.About the author

 **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.

  ## Hand the watching to the system

 Tell me where your buyers lose time today. On a 30-minute fit call I’ll show you which of the twelve scenarios pays for itself first — with a fixed price and a dry-run week before anything goes live.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud.md)

## IFS Custom Events: Automate SCM Without Touching Core

Independent IFS Cloud practice · Supply Chain

 
## IFS Custom Events explained: automate your supply chain without touching the core

 **Key takeaways**

 
- **IFS Custom Events** let you react to something happening in IFS Cloud — a PO saved, a receipt posted — without changing core code.
- An event is a **trigger** plus one or more **actions**; PL/SQL is available for the cases plain configuration cannot cover.
- Unlike a core modification, a Custom Event is update-safe — it is carried forward by each release.
- The real risks are alert storms and performance; dry-run, frequency caps and a test week contain both.
- The SCM Automation Pack is twelve production-ready Custom Event automations you can buy and tune.

  Most supply-chain controls in IFS Cloud still run on someone remembering to look. A buyer checks for unconfirmed orders when they have time; a planner spots a stock-out after it has already happened. **IFS Custom Events** move that watching into the system itself — and they do it without a single change to the core, so nothing breaks at the next upgrade. This article explains what Custom Events are, how they differ from modifications, where PL/SQL fits, the risks worth respecting, and a worked example you can picture on your own data.

  ## 1.What are IFS Custom Events?

 A Custom Event is a standard IFS Cloud mechanism that watches for a defined change in the database and runs logic when it happens. You are not writing a background program; you are declaring, inside the application, “when *this* occurs, do *that*.” The “this” is a **trigger** — a row inserted, updated or deleted on a table you choose, optionally narrowed by a condition. The “that” is one or more **event actions**.

 Because Custom Events live in the Extensibility Framework rather than in modified standard code, they are the backbone of a Clean Core build. If that term is new, [Clean Core in IFS Cloud](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) explains why the distinction decides your upgrade cost.

  ## 2.How do Custom Events differ from modifications?

 Both can achieve the same automation. Only one survives an upgrade cleanly. The difference is where the logic sits:

 
| Aspect | Custom Event | Core modification |
| --- | --- | --- |
| Location | Extensibility layer, outside the core | Edited standard package or view |
| Upgrade behaviour | Carried forward and re-validated | Overwritten; must be re-applied |
| Built by | Consultant or trained key user, in the UI | Developer with core source access |
| Rollback | Disable the event — instant, contained | Re-patch and re-test the core |
| Update-safe? | Yes | No |

 A Custom Event you no longer want is switched off in seconds. A core modification you no longer want is a project. That reversibility is half the reason to prefer events.

  ## 3.Triggers, actions and where PL/SQL fits

 Every Custom Event has the same anatomy. Understand these three parts and you can read any automation in the pack:

 
- **Trigger** — the table and operation you watch (for example, a purchase order line updated), plus an optional condition so the event fires only when it matters.
- **Action** — what happens next: send an email or alert, start a Workflow, set a Custom Field, or call server logic.
- **PL/SQL** — used inside an action when a rule needs real logic: look up a tolerance, compare values, decide who to notify. It runs in the event, not in the core.

 Most scenarios need only a trigger, a condition and a notify action. PL/SQL is the exception you reach for when the decision is genuinely conditional — and even then it stays update-safe, because it is attached to the event rather than welded into a standard package. For the wider picture of chaining events with Workflows, see [how to automate SCM processes in IFS Cloud](https://www.ifs-erp.com/blog/automate-scm-processes-ifs-cloud).

  ## 4.What are the risks — and the safeguards?

 Custom Events are safe by mechanism, but not automatically safe by design. Two failure modes are worth respecting, and each has a matching control:

 
| Risk | What goes wrong | Safeguard |
| --- | --- | --- |
| Alert storm | A broad trigger fires hundreds of emails; people stop reading them | Tight conditions plus a **frequency cap** per scenario |
| Performance | Heavy logic on a high-volume table adds load to every transaction | Narrow triggers, lean PL/SQL, run against volume in test |
| Untested behaviour | An event does the wrong thing in production first | **Dry-run mode** and a mandatory **test week** |

 Dry-run is the key habit: the event evaluates and logs what it *would* do without sending or writing anything. You watch a week of real transactions flow through it, confirm the volume and the targets are right, then switch it live. Every scenario in the pack ships with dry-run and a frequency cap for exactly this reason.

  ## 5.Worked example: unconfirmed PO escalation

 A common gap: purchase orders sent to suppliers but never acknowledged. Nobody owns the follow-up, and the first sign of trouble is a late delivery. Here is the same control as a Custom Event, step by step:

 
1. **Trigger** — watch purchase order lines; fire when a line is still in an unconfirmed state.
2. **Condition** — only when the order date is older than your threshold (say, three working days) and the value is above a floor worth chasing.
3. **PL/SQL** — resolve the responsible buyer from the order, and skip any supplier flagged as exempt.
4. **Action** — email that buyer, and after a second threshold, escalate to the purchasing lead.
5. **Frequency cap** — at most one reminder per order per day, so a slow supplier never floods an inbox.
6. **Dry-run week** — log intended emails for a week, confirm the list and the counts, then go live.

 Nothing in that sequence touches the Purchasing core. It is a trigger, a condition, a little PL/SQL and a notify action — and it keeps working after every upgrade.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call) [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 6.Why are Custom Events update-safe?

 Because IFS treats the Extensibility Framework as a supported layer that upgrades must preserve. Your event is registered as an extension against standard tables and projections; when a new track arrives, that extension is carried forward and re-validated rather than overwritten. There is no modified core to re-patch, so the upgrade job for your automations shrinks to a short checklist — list them, confirm each still binds, dry-run each once, sign off. That is the whole point: the automation earns its keep every day and costs you almost nothing at upgrade time.

  ## 7.Frequently asked questions

 Do IFS Custom Events modify the core? No. Custom Events live in the Extensibility Framework and react to standard database changes from outside the core. That is why they are update-safe: an upgrade carries them forward and re-validates them instead of overwriting them, unlike an edited standard package.

   When do I need PL/SQL in a Custom Event? When plain configuration cannot express the rule — for example looking up a tolerance, comparing values, or deciding who to notify. The PL/SQL runs inside the event action, so it stays update-safe. Most scenarios need only a trigger, a condition and a notify action.

   How do I stop Custom Events from causing alert storms? Keep triggers narrow with tight conditions, and put a frequency cap on each scenario so a single record cannot generate repeated alerts. Then prove it in dry-run mode across a real test week before go-live, watching the volume and the recipients before anything is sent.

   Can Custom Events slow down IFS Cloud? They can if a heavy trigger fires on a high-volume table on every transaction. The fix is design discipline: narrow the trigger, keep the PL/SQL lean, and test against realistic volume before go-live. Well-scoped events add negligible load.

  ## 8.About the author

 **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. Based in Kraków, working remotely across Europe and globally in an independent practice built strictly on Update-Safe / Clean Core principles.

 **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.

  ## Put the watching where it belongs — in the system

 Tell me where your supply chain loses time to manual checking today. On a 30-minute call I’ll show you which Custom Event scenarios pay for themselves first — all update-safe, all dry-run tested before anything goes live.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/ifs-custom-events-explained.md)

## Clean Core in IFS Cloud: Purchasing & Inventory

Independent IFS Cloud practice · Supply Chain

 
# Clean Core in IFS Cloud: what it really means for Purchasing and Inventory

  **Key takeaways**

 
- **Clean Core IFS Cloud** means every change lives inside the Extensibility Framework — not in modified core code — so upgrades stay predictable.
- For SCM, “update-safe” means your Purchasing and Inventory automations survive each R1/R2 release untouched.
- Custom Events, Custom Fields and Workflows are the update-safe building blocks; direct core edits are not.
- Staying inside the core sharply reduces the regression testing you owe every upgrade.
- The SCM Automation Pack is Clean Core by construction — twelve automations built only with standard mechanisms.

  Every IFS Cloud upgrade carries a hidden bill. If your Purchasing and Inventory logic was welded into modified core code, someone has to re-test and re-fix it each release — the “upgrade tax” that turns a routine update into a three-month project. Clean Core is how you stop paying it. This piece explains what Clean Core actually means in IFS Cloud, where the line sits between the Extensibility Framework and core modification, and what that changes for a supply-chain team in concrete terms.

  ## 1.What does Clean Core mean in IFS Cloud?

 Clean Core is a simple rule with large consequences: **you never change the standard product; you extend it from the outside.** IFS ships the core application — the Purchasing, Inventory, Shop Order and Invoicing logic that every customer receives — and provides a defined layer, the **Extensibility Framework**, where your own logic is allowed to sit. Keep everything you build inside that layer and the core stays exactly as IFS delivered it. That is a “clean” core.

 The reason this matters is upgrades. IFS Cloud is evergreen: new tracks arrive on a regular cadence, and each one may rewrite core packages, views and pages. Anything you left *inside* the core is overwritten or thrown out of alignment. Anything you built in the extensibility layer is designed to be carried forward. Clean Core is not a style preference — it is the difference between an upgrade you schedule and an upgrade you survive. We unpack that cost in detail in [the IFS Cloud upgrade tax](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-tax).

  ## 2.Extensibility Framework vs core modification

 The two are not different flavours of the same thing. One is a supported extension point; the other is a liability you carry to every release. Here is the practical split for a supply-chain build:

 
| Question | Extensibility Framework | Core modification |
| --- | --- | --- |
| Where the logic lives | Custom Events, Custom Fields, Workflows, projections — outside the core | Edited standard PL/SQL, views or client pages inside the core |
| What an upgrade does to it | Carried forward; validated, not rewritten | Overwritten or broken; must be re-applied |
| Who can maintain it | A consultant or a trained key user, in the UI | A developer with core source access |
| Regression test burden | Small and bounded | Large and open-ended |
| Update-safe? | Yes, by design | No |

 There is still a place for server-side PL/SQL — but inside an event action, not welded into a standard package. The mechanism, not the language, decides whether a change is Clean Core.

  ## 3.What does “update-safe” mean for SCM specifically?

 “Update-safe” means a given automation keeps working across an IFS Cloud upgrade without a developer touching it. For supply chain that is a strong promise, because SCM logic tends to be busy: it fires on purchase orders, receipts, stock transactions and supplier records that change thousands of times a day. If that logic sits in the core, every one of those touch-points is a place the next release can break.

 Built the Clean Core way, an update-safe SCM automation has three properties:

 
- It listens to a **standard event** (a PO line saved, a receipt posted) rather than a modified trigger.
- It reads and writes through **standard projections and APIs**, so field and table changes are absorbed cleanly.
- It stores its own settings in **Custom Fields**, never by editing a base table.

  ## 4.Concrete Purchasing and Inventory examples

 Clean Core is easier to trust when it is specific. Here are automations that solve real supply-chain pain and stay entirely inside the extensibility layer:

 
- **Unconfirmed PO escalation** — flag orders the supplier has not acknowledged after your threshold, and chase the right buyer.
- **Supplier price-change guard** — catch a purchase price that jumps beyond tolerance before the order is released.
- **Below-minimum stock alert** — notify planning when on-hand crosses the safety point, without a manual report run.
- **Invoice-on-hold nudge** — surface invoices stuck in hold so they never quietly age past terms.
- **Receipt-without-order check** — spot inventory movements that do not tie back to an expected receipt.
- **Slow-moving stock digest** — a weekly view of items aging past their target, straight to the planner.

 Each one is a Custom Event with a defined trigger and action — not a change to the Purchasing or Inventory core. If you want the mechanism itself explained, [IFS Custom Events explained](https://www.ifs-erp.com/blog/ifs-custom-events-explained) walks through triggers, actions and PL/SQL, and [Quick Reports, Custom Fields and Custom Events](https://www.ifs-erp.com/blog/quick-reports-custom-fields-custom-events) shows how the reporting side stays update-safe too.

  ## 5.How does staying update-safe cut regression testing?

 Regression testing exists to answer one question after an upgrade: *did anything we changed stop working?* The size of that job is set by how much you changed and where. Core modifications force you to re-test every altered package and every process that touches it — and because a core edit can have side effects far from where it sits, the test surface is hard to bound. That is the open-ended cost that makes upgrades slip.

 Clean Core shrinks the surface. Because your logic sits in named, isolated extensions, an upgrade validation is a checklist, not an investigation:

 
1. List your Custom Events, Custom Fields and Workflows — a finite, known set.
2. Confirm each still binds to its standard event and projection on the new track.
3. Run each automation once in dry-run and compare the result to the last release.
4. Sign off. There is no modified core to hunt through, because there is none.

 The work goes from “re-test the whole supply chain” to “re-validate a short list.” That is where the upgrade tax disappears.

  ## 6.How the SCM Automation Pack embodies Clean Core

 The **SCM Automation Pack** is twelve update-safe automations for Purchasing, Requisitions, Inventory and Invoicing — built from Custom Events, Workflows and, where genuinely needed, PL/SQL running inside an event action. Nothing in it modifies the core. Every scenario ships with a dry-run mode and a frequency cap, and go-live includes a mandatory test week, so you prove behaviour before it touches production. It is Clean Core turned into a product: the events fire, the alerts land, and the next R1/R2 release carries the whole pack forward untouched.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call) [See the SCM Automation Pack](https://www.ifs-erp.com/scm-automation-pack)

  ## 7.Frequently asked questions

 Is Clean Core in IFS Cloud the same as having no customisations? No. Clean Core means customising through the Extensibility Framework instead of modifying the core. You can automate Purchasing and Inventory heavily and still be Clean Core, as long as every change lives in Custom Events, Custom Fields, Workflows and projections rather than in edited standard code.

   Can I still use PL/SQL and stay Clean Core? Yes. PL/SQL is fine when it runs inside a Custom Event action or a supported extension point. What breaks Clean Core is editing standard IFS packages or views directly. The mechanism decides, not the language — the same logic is update-safe in an event action and unsafe welded into core code.

   How does Clean Core reduce upgrade cost for a supply-chain team? It bounds the regression test. Instead of re-testing every modified core package and its side effects, you validate a finite list of extensions against the new track and dry-run each one. Upgrades become a scheduled checklist rather than an open-ended remediation project.

   Is the SCM Automation Pack built to Clean Core standards? Yes. All twelve automations use only standard IFS mechanisms — Custom Events, Workflows and PL/SQL inside event actions — with no core modification. Each ships with a dry-run mode and frequency cap, and go-live includes a mandatory test week, so the pack is carried forward by every future upgrade.

  ## 8.About the author

 **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. Based in Kraków, working remotely across Europe and globally in an independent practice built strictly on Update-Safe / Clean Core principles.

 **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.

  ## Keep your supply chain automations off the core

 If your next IFS Cloud upgrade is on the calendar, the safest place for your Purchasing and Inventory logic is the extensibility layer — not the core. On a 30-minute call I’ll show you which automations pay for themselves first, all Clean Core, all dry-run tested before go-live.

 [Book a 30-minute fit call](https://www.ifs-erp.com/book-a-call)


[Read more...](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm.md)

## The IFS Cloud Upgrade Tax

Independent IFS Cloud practice · Clean Core

 
## The IFS Cloud upgrade tax: why custom extensions break at every R1/R2, and how to stop paying it

  **Key takeaways**

 
- The **IFS Cloud upgrade tax** is the recurring cost of fixing customisations that break at each R1/R2 release: regression testing, hotfixes and delayed go-lives.
- Extensions built *outside* the IFS Extensibility Framework touch things IFS is free to change, so they break by design, not by accident.
- The cost is rarely a line item. It hides in test cycles, frozen backlogs and reputational drag every six months.
- **Clean Core** removes the tax by keeping every extension inside supported, versioned interfaces.
- Before your next release, inventory and classify every extension: Safe, Refactor, Rewrite or Retire.

  Every IFS Cloud customer pays a tax they never signed up for. It arrives twice a year, on the schedule of the R1 and R2 releases, and it is collected in test hours, hotfixes and slipped go-live dates. You have felt it if your last upgrade turned into a scramble: buyers unable to release orders, a report throwing errors, an integration silently dropping messages. This is the IFS Cloud upgrade tax, and most teams treat it as the price of doing business. It is not. It is the price of building in the wrong place.

  ## 1.What is the IFS Cloud upgrade tax?

 The upgrade tax is the labour and delay you spend, every release, to keep customisations working across an IFS Cloud version change. IFS ships evergreen: the product moves forward on a fixed cadence, and each release can change database views, API signatures, page structures and internal logic. Standard functionality is carried across for you. Anything you bolted on that reaches past the supported surface is your problem to re-validate. When it breaks, it is your problem to fix under time pressure, with the release already booked.

 The tax is not one invoice. It is a bundle of costs that recur on the release calendar:

 
- Regression testing every custom flow, twice a year
- Emergency hotfixes when something breaks in the new version
- Delayed go-lives while fixes are written and re-tested
- A frozen backlog: no new value ships during the scramble
- Consultant day rates spent re-doing work you already paid for
- Lost trust in the system from the people who depend on it

  ## 2.Why do custom extensions break at every release?

 Extensions break because of *where* they are built, not how well. IFS Cloud draws a line. On one side is the supported Extensibility Framework: Custom Fields, Custom Events, Custom Logic, projections and configuration that IFS commits to carrying forward. On the other side is everything that reaches around that framework: code against internal packages, queries against volatile database views, page hacks, undocumented API calls, integrations wired to interfaces IFS never promised to keep.

 IFS is free to change anything on the far side of that line, and each release it does. An extension anchored there is not unlucky when it breaks. It is doing exactly what an unsupported dependency does. The framework exists precisely so your logic rides on a contract IFS honours across versions. Step outside it and you have opted into the tax.

 The rule of thumb: if IFS didn’t promise the interface would survive the upgrade, assume it won’t. Build against the surfaces IFS versions on purpose.

 This is why two customers on the same release can have very different upgrade experiences. The one whose extensions live inside the framework re-validates and moves on; the one whose logic sits in modified core spends weeks. Same release, different bill. For the mechanism that keeps automation on the right side of the line, see [IFS Custom Events explained](https://www.ifs-erp.com/blog/ifs-custom-events-explained).

  ## 3.What does the upgrade tax really cost?

 The headline number, consultant days to fix broken customisations, is the smallest part. The expensive parts are the ones nobody puts on a purchase order.

 
| Cost | Where it hides | Who pays |
| --- | --- | --- |
| Regression testing | Weeks of manual re-testing across every custom flow, each release | Key users, pulled off their day job |
| Hotfixes | Rushed fixes under a live deadline, often re-broken next release | IT budget and consultant day rates |
| Delayed go-live | The upgrade slips; the new version’s value is postponed | The whole business waiting on it |
| Frozen roadmap | No improvements ship while everyone firefights the release | Every team that wanted something built |
| Eroded trust | Users route around the system after each broken upgrade | Data quality and adoption, long-term |

 Multiply that by two releases a year, over as long as you stay on IFS Cloud. The upgrade tax is not a one-off. It is an annuity you pay to your own technical debt, and it compounds every release you defer the fix.

  ## 4.How does Clean Core remove the tax?

 Clean Core is a simple discipline with an outsized payoff: keep the standard product standard, and put every piece of custom logic inside the supported Extensibility Framework. When your extensions only touch surfaces IFS commits to versioning (Custom Events and Workflows, Custom Fields, projections, configuration delivered via ACPs, integrations over OData/REST), the release carries them forward the way it carries standard functionality forward.

 The upgrade stops being a rebuild and becomes what it should be: a re-validation. You confirm your automations still fire, your reports still run, your integrations still exchange messages, and you move on. Nothing to hotfix, because nothing was anchored to something IFS was free to change.

 
- **Automation** via Custom Events + Workflows, not modified core
- **Integration** over supported OData/REST projections, not internal APIs
- **Security** through RBAC and Segregation of Duties, not bespoke workarounds
- **Delivery** as versioned ACPs you can move between environments cleanly

 This is exactly how the [Clean Core approach to IFS Cloud supply chain automation](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) is built: supply-chain logic that survives the upgrade because it never left the framework. Clean Core is not a feature you buy. It is a rule you apply to everything you build, and it is the only durable way to stop paying the tax.

  ## 5.What should you do before the next release?

 You cannot Clean-Core your way out of debt you cannot see. Before the next R1/R2 lands, get an honest picture of what you have and what it will cost you:

 
1. **Inventory every extension.** List all customisations, reports, integrations and modifications, including the ones nobody owns any more.
2. **Classify the risk.** Mark each one Safe, Refactor, Rewrite or Retire, based on whether it lives inside the framework or reaches outside it.
3. **Retire the dead weight.** Every extension you switch off is one you never pay the tax on again.
4. **Refactor the fixable.** Move logic that reaches outside the framework back onto supported interfaces before it breaks under deadline.
5. **Book a dry run.** Validate in a test environment that mirrors production, so the real upgrade holds no surprises.

 For the full pre-flight sequence, work through the [IFS Cloud upgrade readiness checklist](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist). If you want it done for you, the **Update-Safe Audit** delivers exactly this classification in 10 business days: every extension rated Safe / Refactor / Rewrite / Retire, with a fixed-price remediation roadmap.

 [SCM Exception Scan for IFS Cloud](https://www.ifs-erp.com/en/applications/scm-exception-scan) [Book a 30-minute call](https://www.ifs-erp.com/en/contact)

  ## 6.Frequently asked questions

 What exactly is the IFS Cloud upgrade tax? It is the recurring cost of keeping customisations working across each IFS Cloud release: regression testing, emergency hotfixes and delayed go-lives that arrive on the R1/R2 schedule. It is rarely a single invoice; it hides in test hours, frozen backlogs and slipped dates every six months.

   Why do my extensions break when IFS itself is upgraded cleanly? Because the break is about where the extension is built. Standard functionality and anything inside the Extensibility Framework is carried forward. Logic that reaches around it (modified core, volatile views, undocumented APIs) touches surfaces IFS is free to change each release, so it breaks by design.

   Does Clean Core mean I cannot customise IFS Cloud? No. Clean Core means you customise inside the supported framework (Custom Events, Custom Fields, projections, configuration) rather than modifying the core. You keep the automation and integration you need; you just build it on interfaces IFS commits to versioning, so upgrades become re-validation rather than rebuilds.

   How do I find out which of my extensions will break? Inventory every extension and classify each as Safe, Refactor, Rewrite or Retire based on whether it lives inside the framework. The Update-Safe Audit does this in 10 business days and returns a fixed-price remediation roadmap, with the fee credited in full against any fix work within 90 days.

  ## 7.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.

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

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

  ## Stop paying the upgrade tax

 Your next IFS Cloud release is already on the calendar. In 10 business days, the Update-Safe Audit tells you exactly which extensions will survive it and which will cost you, with a fixed-price roadmap and the fee credited against the fix.


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-tax.md)

## RBAC and Segregation of Duties

Independent IFS Cloud practice · Security

 
## RBAC and Segregation of Duties in IFS Cloud SCM: getting permissions right

 Get IFS Cloud RBAC and Segregation of Duties wrong and the finding lands in your audit report: the same person who creates a supplier can also approve its invoices. This guide explains how Permission Sets work, where the real conflicts live in Purchasing, Inventory and Invoicing, and how to design a model that passes an audit - without a custom object quietly opening a back door.

 ## Key takeaways

 **Key takeaways**

 
- IFS Cloud access is built from Permission Sets granted to users - RBAC done well means roles map to job functions, not to individuals.
- Segregation of Duties (SoD) means no single person controls a whole transaction - create versus approve, order versus receipt, master data versus payment.
- The highest-risk SCM conflicts are supplier creation with invoice approval, and PO creation with goods receipt.
- Custom objects can bypass the standard security model - an unsecured projection or event is an invisible SoD hole.
- Design roles around a documented SoD conflict matrix, then audit against it on every change and every release.

  ## 1.How does RBAC work in IFS Cloud?

 IFS Cloud does not grant access to people directly. It grants it to **Permission Sets** - named bundles of rights over projections, entities and actions - and then assigns those Permission Sets to users. That is role-based access control (RBAC): the permission attaches to the role, the role attaches to the person.

 Done well, a Permission Set maps to a *job function*: “Buyer”, “Goods Receipt Clerk”, “AP Approver”. A user gets the sets their job needs and nothing more. Done badly, sets balloon into “Purchasing” catch-alls that grant every action in the module, and the line between who can order and who can pay disappears.

 Two principles keep RBAC honest: **least privilege** - grant only what the function requires - and **role, not person** - never patch a one-off permission onto an individual, because it is invisible at the next audit. Everything that follows depends on getting this foundation clean.

  ## 2.What does Segregation of Duties mean in SCM?

 Segregation of Duties is the control that stops one person owning a whole transaction end to end. If the same user can create a supplier *and* approve that supplier’s invoices, they can invent a payee and pay them. If the same user can raise a purchase order *and* confirm its goods receipt, they can fabricate a delivery that never arrived.

 In IFS Cloud SCM the classic separations are:

 
- **Master data** vs **payment** - who creates a supplier is not who approves its invoices.
- **Order** vs **receipt** - who raises the PO is not who confirms the goods in.
- **Requisition** vs **approval** - who asks is not who authorises.
- **Inventory** vs **reconciliation** - who adjusts stock is not who counts it.

 SoD is not about distrust. It is a structural control that removes the opportunity, so a single mistake or a single bad actor cannot complete a fraudulent cycle alone.

  ## 3.Which SoD conflicts show up in audits?

 These are the combinations an auditor tests first. If one user holds both sides, it is a finding - whether or not anyone has abused it.

 
| Duty A | Duty B (conflicting) | Risk if combined | Severity |
| --- | --- | --- | --- |
| Create / edit supplier | Approve supplier invoice | Fictitious supplier paid by its own creator | High |
| Create purchase order | Register goods receipt | Phantom receipt against a self-raised order | High |
| Raise requisition | Approve requisition | Unauthorised spend self-approved | High |
| Approve invoice | Release payment | Full payment cycle controlled by one person | High |
| Adjust inventory | Perform stock count | Shrinkage hidden behind self-verified counts | Medium |
| Maintain price list | Approve purchase order | Inflated price set and approved unchecked | Medium |

 Build this into a documented **conflict matrix** before you design a single Permission Set. The matrix is the specification your roles must satisfy - and the checklist every audit will run against you.

  ## 4.How do custom objects bypass the security model?

 Here is the trap that turns a clean RBAC design into an audit failure. Your standard Permission Sets can be perfect, and a single custom object can still route around them. A custom projection that exposes purchase-order actions without inheriting the standard security, a Custom Event that writes an invoice status under a service account, an integration that runs with more rights than any human role - each is an invisible hole in the SoD model.

 This is why security and Clean Core are the same conversation. Every extension must be built inside the IFS Extensibility Framework and secured with the same Permission Sets as standard functionality - never with a bypass and never with a shared privileged account. If a custom object can do something a role cannot, your conflict matrix no longer means anything.

 Audit your custom objects against the same matrix as standard duties. The [Clean Core approach to IFS Cloud SCM](https://www.ifs-erp.com/blog/clean-core-ifs-cloud-scm) exists partly for this reason: update-safe extensions are also security-safe extensions, because they respect the standard model instead of working around it.

  ## 5.Get your permissions audited before someone else does

 A security review that maps your Permission Sets to a documented SoD matrix - standard and custom objects included - turns a future audit finding into a change you made on your own terms. I design and audit IFS Cloud RBAC and Segregation of Duties as an update-safe service, inside the standard model.

 [Book a 30-minute security call](https://www.ifs-erp.com/book-a-call) [See the security service](https://www.ifs-erp.com/offer)

  ## 6.A practical way to design and audit permissions

 Whether you are building fresh or cleaning up a live system, the same sequence works.

 
1. **Document the conflict matrix** - agree with finance and audit which duty pairs must never coincide.
2. **Define roles by job function** - one Permission Set per function, sized to least privilege, mapped to the matrix.
3. **Map users to roles** - assign only the sets a job needs; remove one-off individual grants.
4. **Test for conflicts** - check every user against the matrix; a single person holding both sides of any pair is a flag.
5. **Secure custom objects** - confirm every extension inherits standard Permission Sets and no bypass account exists.
6. **Re-audit on change** - every new role, joiner or release re-runs the matrix. Tie it into your upgrade routine.

 Fold the security re-check into your upgrade preparation so it is never skipped - the [IFS Cloud upgrade readiness checklist](https://www.ifs-erp.com/blog/ifs-cloud-upgrade-readiness-checklist) is the natural place for it. New projections and changed actions in a release can shift what a Permission Set actually grants.

  ## 7.Frequently asked questions

 What is the difference between RBAC and Segregation of Duties in IFS Cloud? RBAC is the mechanism: access is granted to Permission Sets (roles) which are assigned to users. Segregation of Duties is a policy you enforce through that mechanism: no single role or user may hold two conflicting duties, such as creating a supplier and approving its invoices. RBAC is how you grant; SoD is the rule about what you must never grant together.

   What are the most common SoD conflicts in IFS Cloud Purchasing? The highest-risk pairs are supplier creation combined with invoice approval, and purchase-order creation combined with goods receipt. Both let one person complete a payment cycle unchecked. Requisition raise with requisition approval, and invoice approval with payment release, are close behind. These are the first combinations an auditor tests.

   Can a custom object break my IFS Cloud security model? Yes. A custom projection, event or integration that does not inherit standard Permission Sets, or that runs under a shared privileged account, can perform actions your roles forbid. That is an invisible SoD hole. Build every extension inside the Extensibility Framework, secure it with the same Permission Sets as standard functionality, and audit it against your conflict matrix.

   How often should I audit IFS Cloud permissions? Re-run your SoD conflict matrix on every meaningful change: a new role, a joiner or mover, a new custom object, and every IFS Cloud release. Releases can add projections or change actions, which shifts what an existing Permission Set actually grants. Folding the check into upgrade preparation keeps it from being skipped.

  ## 8.About the author

 **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. Based in Kraków, delivering remotely across Europe and globally. Independent practice - you talk to the consultant who does the security work, 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.

  ## Pass the audit on your own terms

 Tell me how your IFS Cloud roles are set up today. On a 30-minute call I’ll show you where the SoD conflicts sit - standard and custom - and how to close them inside the standard security model.

 [Book a 30-minute security call](https://www.ifs-erp.com/en/contact)


[Read more...](https://www.ifs-erp.com/blog/rbac-and-segregation-of-duties.md)

## Period End Close

IFS Cloud · Finance **It is day four of the close, and finance is the only floor with the lights still on.** The controller has a spreadsheet open that does not agree with the ledger, an email out to a cost centre that has gone quiet, and the same number in two reports that somehow changed between this morning and now. Ask her how it is going and she uses one word, the word every controller uses. Chasing.

 A five-day close feels like a failure of finance, and finance is where the blame lands. But finance did not make this mess. It only inherited it, on a deadline, at the worst possible moment.

 “

 The close is a mirror. It reflects, at month-end, every shortcut taken upstream weeks earlier: in a warehouse, on a work order, nowhere near finance.

 IFS Cloud can turn the close from a scramble into a controlled, repeatable sequence. But only if you treat it as the last mile of a clean pipeline, not as a finance sprint bolted onto the end of every month. Here is what a good close actually rests on, and why nearly all of it lives upstream of the people doing the chasing.

  Where the mess is made 
## The ledger only reflects the sub-ledgers

 In a suite like IFS Cloud, the general ledger sits downstream of everything (inventory movements, manufacturing cost, project transactions, purchasing accruals, sales invoices), each posting in through defined accounting rules. So the ledger is never cleaner than the transactions feeding it. That number the controller cannot explain? Manufacturing or the warehouse created it three weeks ago, and she is doing forensic accounting to account for their open work order.

 The lever is not a faster finance team. It is sub-ledger discipline *during* the month: costed transactions, closed work orders, cleared accruals, reconciled inventory, done continuously, so that at period-end there is nothing left to chase because nothing was left open. The close gets fast when the month was clean, never when finance works the weekend harder.

  A gate, not a formality 
## Period control is a sequence, or it is theatre

 IFS gives you real control over accounting periods: what can still post where, and in what order things close, so sub-ledgers settle before the ledger locks behind them. Used deliberately, it is a gate: late transactions land somewhere controlled instead of quietly reopening a number you already signed off. Used as an afterthought, it is a button someone clicks at the end, and then spends next month explaining why last month moved after it was closed. Decide the order on purpose. Which sub-ledgers close first, when the ledger locks, who may reopen a period and on whose authority. A close with no sequence is not a close. It is a snapshot that is still moving.

  Designed once 
## Two truths the system can carry, or two you carry by hand

 Organisations of any size owe more than one accounting truth: a local statutory view and a group standard, different valuations, different calendars. IFS can carry them in parallel, natively, falling out of the same postings. The trap is treating that as something finance reconciles at the end with spreadsheets. Do that, and every close becomes a manual bridge between two views the system could have maintained all along, rebuilt from scratch, twelve times a year. Designed properly up front, both truths just appear. Bolted on afterwards, you have signed finance up to reconcile two realities by hand forever. It is an implementation decision, and it quietly sets the ceiling on how fast every future close can ever be.

  Turn the lights on 
## You cannot speed up a close you cannot see

 Part of why the close feels like chaos is that no one can see it. Twelve tasks across six people, and the only status report is walking over and asking. So the controller spends the week chasing status instead of clearing work, the priciest kind of busy there is.

 “

 You do not speed up a close by working harder inside a black box. You speed it up by turning the lights on.

 IFS Cloud’s Lobbies make the close a live picture (reconciliations outstanding, sub-ledgers still open, exceptions, the cost centres that have not reported), on one screen everybody shares, with no external BI stack to stand up. When the whole team can see the same close in real time, the controller stops being a human switchboard and the bottleneck stops hiding. The thing actually holding up day four becomes visible to everyone at once.

  The real exam 
## The first close after go-live is the one that tells the truth

 Every implementation has a moment of truth, and it is not go-live weekend. It is the first month-end on the new system, where migrated opening balances, fresh accounting rules, new cost structures and people still learning the screens all meet real numbers against a statutory deadline. Teams who prepare for it as an event (opening balances reconciled to a trusted number, the close steps dry-run, the first period-end staffed like a second go-live) sail through. Teams who treat it as “just another month” discover, live and on the clock, that an opening-balance assumption was wrong. If you are implementing now, put that first close on the plan as a named milestone with its own rehearsal. It is the exam the entire finance workstream was really studying for.

 🧮

 
### The close is the last mile of a clean pipeline

 Every point above pushes the work upstream of period-end: into disciplined sub-ledgers, a deliberate sequence, parallel accounting designed once, a close you can see, a first month rehearsed. Do that and the close stops being five days of chasing. Skip it and no amount of heroics at month-end will save you, because the mess was already made, somewhere you were not looking.

  Back where we started 
## Day one, the other version

 Picture the same controller, a few months later. The sub-ledgers reconciled themselves through the month, because nothing was left open to chase. The sequence ran in order. Both accounting truths were already there. And the whole close sat on one Lobby the team could see, so nobody had to walk over and ask. The lights in finance are off by a reasonable hour, because the close finished on day one, not because anyone worked harder, but because the month was clean before it ever reached her desk.

 That is the difference between a scramble and a sequence. It was never really a finance problem. It was a pipeline, and the close was just where you finally saw it.

 ## Make the close fast because the month was clean

 We design IFS Cloud finance and data governance so period-end is a controlled sequence, not a scramble, and so the first close after go-live is a milestone, not a crisis. If your month-end is five days of chasing, the fix is upstream, and we know where.

 [Fix the close upstream](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/period-end-close.md)

## Maintenance asset management

IFS Cloud · Functionality **A line goes down at 6am, and the plant does the thing it always does.** Someone finds Marek, because Marek has been here twenty years and Marek knows the machine. He remembers it did this last winter. He thinks the spare is on a shelf in the back, unless it is the one they used in March. Nobody can say when it was last serviced, because that lives in his head and a laminated sheet by the panel. The line is losing money by the minute while the whole recovery runs on one man’s memory.

 Here is the strange part. This plant runs IFS Cloud. It plans beautifully, promises orders to the day, closes its books cleanly. And the one system that could have told them when the asset was last touched and whether the spare was in stock has been sitting in the licence the whole time, switched off.

 “

 They chose IFS partly because it unifies ERP, asset management and field service in one model. Then they ran the ERP and left the asset management dark.

 It is one of the commonest patterns we see, and one of the priciest. So this is not a feature tour. It is a straight answer to why the dark module is usually the highest-return thing left in the building, and what changes the day you switch it on.

  Made concrete 
## Four questions your plant asks every day

 Strip away the acronyms (EAM, MRO, preventive, predictive) and the maintenance side of IFS Cloud simply answers four questions Marek is answering from memory right now.

 🏭

 
### What do we own?

 A real asset register (sites, locations, equipment and the parts inside them), so a machine is a living record with a history, not a line in a fixed-asset spreadsheet.

 📅

 
### How do we keep it running?

 Preventive work orders that raise themselves on a schedule, a meter or a condition, instead of waiting for a 6am failure to remind you the machine exists.

 🔨

 
### What do we do when it breaks?

 A corrective work order that gathers the labour, the parts, the instructions and the history in one place, and pulls the spare from the same inventory your ERP already runs.

 📈

 
### Is it actually worth keeping?

 Cost, downtime and reliability captured over an asset’s life, so your worst offenders for cost and breakdown are a report, not an argument in a corridor.

 The quiet magic is in the third answer. Because it is all one model, the spare Marek is hunting for is the same part your MRP plans, your buyers purchase and your finance values. No interface. No reconciliation. No second version of the truth.

  The invisible costs 
## The biggest return is the part left switched off

 Your ERP go-live tidied things you could already see: orders, stock, invoices. Maintenance is different, and more valuable, precisely because today it is invisible. And invisible is where the money hides.

 ⏱

 
### Downtime

 The priciest hour in any plant, and the one maintenance exists to prevent. Move even a slice of failures from reactive to planned and it goes straight to the bottom line. Money you currently cannot even measure.

 📦

 
### Spare parts

 Working capital nobody is steering. On a spreadsheet, stores over-stock “just in case” while the one critical spare is always missing. On one platform with MRP, the guesswork becomes a plan.

 🧠

 
### Knowledge

 Right now it is Marek. When Marek retires, a plant on memory loses him. A plant on IFS keeps every work order, fault and part recorded against the machine.

 None of this needs a new system bought, evaluated or implemented. It needs the module already in your licence configured and turned on.

  One model, all the way out 
## And the same record reaches the technician in the van

 If you also service equipment in the field, IFS extends the very same model into Field Service Management: scheduling, dispatch, mobile work, parts in the van, the customer-facing side of it all. What matters is that it is not a separate tool with its own database bolted on the side. The asset, its history and its spare parts are the same records the plant and the ERP already use. The technician on a customer site sees what the planner sees. That single-model continuity, with plant, field, inventory and finance on one platform, is exactly what a standalone maintenance app can never give you, and it is precisely what you already bought.

  The fix 
## Switching it on is a project of weeks, not a re-implementation

 The trick is sequencing it sanely rather than trying to boil the ocean. Start by building the asset register only as deep as you will actually maintain: model to the level you will raise a work order against, no finer, because a register you can keep up beats a perfect one you cannot. Put your first preventive plans on the assets that hurt worst when they stop, ranked by what a failure costs in downtime and safety. Connect spares to the inventory you already run, so “where is the spare” becomes a reservation instead of a scramble. Then let the data steer the rest: once work orders carry real cost and failure history, the machines that deserve condition-based or predictive attention raise their own hands. You stop guessing where to spend maintenance effort and start following the evidence.

 🔑

 
### You almost certainly own more IFS Cloud than you run

 The maintenance and asset-management capability is the part manufacturer after manufacturer leaves dark, and it sits directly on top of the highest, least-visible costs in the whole operation: downtime, spare-parts capital, and the knowledge that walks out with the people who hold it.

  Back where we started 
## 6am, the other version

 Run the same morning again with the module on. The line stops. This time the work order is already open on a screen, with the machine’s full history under it: last serviced six weeks ago, this fault seen twice before, the fix that worked. The spare shows two in stock, aisle and bin. A technician is assigned before anyone has finished their coffee. Marek is still the best engineer in the building, but now the plant no longer depends on his memory to get the line back, and neither will the person who takes his job.

 The software was there the whole time. The only decision left is to switch on the lights.

 ## Switch on the module you’re already paying for

 We help manufacturers already on IFS Cloud light up maintenance and asset management, with no second platform and no re-implementation. If your assets live on a whiteboard beside a world-class ERP, that is the gap we close.

 [Switch on your asset management](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/maintenance-asset-management.md)

## Go-live is a load test.

IFS Cloud · Implementation **It is 2am on the go-live weekend, and the old system is already dark.** There is no going back to it now. Someone is on the phone to a supplier integration that will not answer. The data load that was supposed to take two hours is at hour five. And a project manager is doing the quiet arithmetic of how little time is left before Monday, when three thousand people log in expecting to do their jobs.

 Everybody treats go-live as a date. A finish line with a party after it. That is exactly why it hurts so often, because a date is something you simply arrive at, and you cannot fail at arriving.

 “

 A go-live is not a date. It is a load test: the first time your config, your data, your integrations and your people all run at once, with nothing to fall back on.

 Load tests have a pass condition and a fail condition. The teams whose weekends are calm are the ones who had already sat this exam twice, in rehearsal. The teams whose weekends turn into a three-month clean-up treated the exam as a deadline they were sprinting toward. The difference is almost never talent. It is what they did in the weeks before.

  The dress rehearsal 
## A cutover you have never timed is a guess

 The single best predictor of a calm go-live is a boring one: a full mock cutover, run end to end on a copy that looks like production, before the real thing. Not the data load on its own. The whole runbook. Extract, transform, load, reconcile, open the balances, flip the integrations, smoke-test the journeys that matter. Timed. In order. By the people who will do it for real.

 The first rehearsal always overruns, and it always surfaces the step nobody wrote down. That is the point of it. You want to meet the six-hour load and the reconciliation that will not tie in a rehearsal you can stop, not at 2am with the old system already gone. Do it at least twice: the first proves the runbook is incomplete, the second proves it is repeatable and hands you a real duration to plan the weekend around.

  The quiet failure 
## Migrated data is guilty until it reconciles

 Data does not have to be missing to sink you. It only has to be a little wrong, and a little wrong is invisible right up until finance tries to close the month.

 “

 A load with no errors is not a load that is right. You have verified the loader, not the data.

 So reconcile against numbers the business already trusts, both ways, before you commit: trial balance to trial balance, inventory quantity and value by site, open receivables and payables, open orders by count and value. The dangerous load is not the one that throws errors. It is the one that runs perfectly and lands the wrong costing method on a single site, or drops the orders that were mid-shipment when you took the extract. Those do not announce themselves. They surface three weeks later as a variance, when it is a forensic investigation instead of a validation step.

  Decided in daylight 
## Write the go / no-go before the night, not during it

 The worst possible time to decide whether you are fit to go live is inside the go-live: at midnight, exhausted, invested, everyone aching for it to be a yes. Decide it in cold blood, weeks ahead. The exact reconciliations that must tie. The transactions that must complete in a smoke test. The count of open defects you will tolerate, by severity. The integrations that must be confirmed live. And, with equal care, the line at which you stop and roll back.

 A rollback plan invented on the night is not a plan; it is a panic with a name. Written in daylight, go / no-go becomes a checklist anyone can read against reality. Written on the night, it becomes whatever the highest-ranking tired person in the room wants it to be.

  The Monday everyone left 
## The exam is the first month-end, not the weekend

 Here is the pattern, and it is almost universal. The cutover succeeds. The team celebrates. And on Monday people quietly drift back to their day jobs, because “we’re live now,” at the precise moment users are hitting the system hardest and finding everything the test scripts never thought to try.

 Go-live weekend is not the finish line. It is the start of the sharpest stretch of the whole load test: the first two or three weeks, and above all the first month-end close, where every quiet assumption from the project finally meets real volume and real people. Staff hypercare like it matters: named people, real coverage, a fast path from “a user is stuck” to “someone who can fix it,” and a daily stand-up that burns the list down. Treat that first close as a second go-live, because operationally that is what it is. And where the business allows it, phase the whole thing (a lead site first, then roll the pattern out with the lessons already paid for) rather than betting everything on one heroic weekend.

 🔌

 
### Rehearse the failure before you cannot afford it

 Every rule here does the same thing: it drags a discovery earlier, into a mock cutover, a reconciliation, a written criterion, a staffed first month, where it costs a rehearsal instead of a crisis. A calm go-live is not bravery on the night. It is an exam you have already passed twice, so the real one is just paperwork.

  Back where we started 
## 2am, the other version

 Picture the same weekend on the other team. It is still 2am. The old system is still dark. But nobody is doing panicked arithmetic, because they have run this exact sequence twice and know it finishes at four. The reconciliations tie, the way they tied in rehearsal. The integration that failed last time was found and fixed a fortnight ago. Monday will be busy, and hypercare is already rostered for it. The weekend is not a leap of faith. It is the calmest part of the project, because all the hard moments happened earlier, on copies, where they were allowed to.

 ## Rehearse the go-live, don’t brave it

 We plan and run IFS Cloud cutovers as rehearsed load tests, with fixed-price guarantees, and we rescue the ones that went live on hope. If your date is close and any of this feels soft, let’s talk while there is still time to rehearse.

 [Plan a rehearsed cutover](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/go-live-is-a-load-test.md)

## Evergreen trap upgrades

IFS Cloud · Lifecycle **Every spring, the same line appears in their plan: “IFS upgrade: allow one quarter.”** Nobody questions it anymore. It is treated like weather. Three months of a developer re-applying the same modifications, a nervous fortnight of clicking through screens to check nothing broke, and a go-live-sized knot in everyone’s stomach, twice a year, forever.

 Two floors down, a competitor on the exact same product takes the same release over a weekend and barely mentions it on Monday. Same platform. Same cadence. Wildly different lives. The difference was decided years ago, by how each of them built.

 “

 The cadence that keeps IFS Cloud modern is the same cadence that bills you for every shortcut you took at build.

 IFS ships a **Release Update** twice a year (24R2, 25R1, 26R1), each with new features and cumulative fixes. Between them come monthly **Service Updates**: high-severity fixes only, no new functionality, nothing that breaks your data model unless a critical bug forces it. And because each release keeps getting those service updates longer than the gap to the next one, you get a real say in *when* you move. That is the “Evergreen” promise. The promise is genuine. Whether you get to enjoy it is up to you.

  The line that decides everything 
## Two ways to change the same system

 IFS draws a hard line down the middle of every customisation, and your future sits on one side of it or the other.

 ✅

 
### Above the line

 The Extensibility Framework (custom fields, custom logic, custom events) plus configuration through Page Designer. It layers on top of the core, so when a release lands it simply comes along. No drama, no re-work.

 🔧

 
### Into the core

 Modifications that reach into IFS’s own behaviour. They work. They demo beautifully. And every single release, someone has to re-apply and re-test them against a core that moved underneath, a bill that only arrives at the first upgrade.

 The rule is unglamorous: exhaust configuration and framework extension before you cut into the core. Every core change is a standing subscription, re-tested twice a year for the life of the system. Sometimes that price is worth paying. It is never free, and it should never be paid by accident at whichever desk the ticket landed on.

  Know the difference 
## A release and a service update are not the same animal

 Half the panic around upgrades comes from treating every update as if it were the big one. It is worth keeping the two straight.

 |   | Release Update (RU) | Service Update (SU) |
| --- | --- | --- |
| **How often** | Twice a year (24R2, 25R1, 26R1) | Monthly, cumulative |
| **What’s inside** | New functionality and cumulative fixes | High-severity fixes only |
| **Can it move the ground?** | Yes; APIs and data models can change | No, unless a critical bug forces it |
| **Your part** | Choose when to adopt, inside the Evergreen window | Take them; they are the safety net in between |

  The silence 
## If you cannot list your changes, you cannot upgrade cheaply

 Ask a team in trouble what they have changed from standard, and you get a pause. Someone starts a sentence about a thing finance asked for years ago. Someone else is not sure if that nightly job is theirs or shipped. That pause is the whole cost of the upgrade, in advance.

 “

 An upgrade costs exactly what it costs to know what might break. The silence when you ask is the invoice.

 Keep a living register instead: every extension, event, custom field, integration and core change, each with an owner and a reason. It is not


[Read more...](https://www.ifs-erp.com/blog/evergreen-trap-upgrades.md)

## Requirements before build

IFS Cloud · Implementation **It is month eleven, and the status has been green for a while.** The steering committee nods along. The sponsor is pleased. Everyone in the room believes the project is healthy, because every report they have seen says so. And the project is already dead. It just has not told anyone yet.

 That is the unnerving thing about a failing ERP project. It does not fall over. It keeps scheduling meetings, keeps turning things green, and quietly changes what “done” is going to mean, right up until acceptance, when everyone finds out at once.

 “

 The build is almost never wrong. It is faithful. Faithful to requirements that were never quite real.

 When you are called in to rescue enough of these, the post-mortems start to rhyme. Nobody was lazy. Nobody skipped a step. The work was done well against a set of requirements that had already gone soft, months earlier, in a room where everyone was too happy to notice. Here is where it actually goes wrong, and where you can still catch it.

  The first soft spot 
## A shopping list is not a scope

 The requirements sit in a spreadsheet, sorted by module. Financials. Manufacturing. Supply Chain. Maintenance. It looks organised, it looks complete, and it has already lost the plot, because nobody in your business experiences a module. They experience a customer order, and one order walks straight through half of them.

 📋

 
### Written as modules

 A tidy list of things to switch on. Every hand-off (order to shop floor, shipment to invoice, invoice to ledger) falls into the gap between two workstreams. And the gaps between workstreams are exactly where go-lives come apart.

 🔄

 
### Written as journeys

 Order-to-cash. Procure-to-pay. Plan-to-produce. One person owns each journey the whole way across the modules, so the seam between manufacturing and finance has a name on it before it becomes a defect.

 Point at any requirement and ask a simple thing: which journey does this serve, and who owns that journey end to end? If the honest answer is a module name, it is not a requirement yet. It is a wish, filed alphabetically.

  The word that dodges 
## “Must have” is a way of not deciding

 Standard IFS covers nearly all of what a business needs before anyone touches it. The interesting 10 to 20 percent is the whole game, and it usually gets handled by writing “must have” in a column and moving on. That feels like a decision. It is the opposite of one.

 “

 “Must have” is not a decision. It is a way of avoiding one, politely, in writing.

 Every gap has two prices, and both belong on the table. What it costs to close: configuration, an extension, a change to how the business works. And what it costs to leave open: a workaround, an hour a week, a quiet risk. The moment a line reads “forty thousand to build, plus a few thousand a year to keep upgrade-safe, versus twenty minutes a week in a spreadsheet,” the argument settles itself. Half the must-haves turn out to be nice-to-haves that nobody wanted to say out loud. The ones you never cost do not vanish; they wait, and come back as change requests at the worst possible moment.

  Made concrete 
## Every gap you close has a future owner

 When you decide to close a gap inside the system, you are also deciding who inherits it, because the way you build it today sets who pays at every upgrade for the next ten years. IFS gives you three doors. They look similar in a workshop. They are not the same door.

 | How you close the gap | What it really is | Who pays at the next release |
| --- | --- | --- |
| Configuration: a workflow, a rule, a value maintained on a screen | ✅ **Standard** | Nobody. It comes along for the ride. |
| An upgrade-safe extension: a custom field or logic through the Extensibility Framework | 🟡 **Addition** | Little, if it stays inside the framework, though it still needs an owner and a note. |
| A modification that reaches into the core | 🔧 **Change** | Someone re-applies and re-tests it every six months, for as long as it lives. |

 None of these is wrong. The mistake is choosing between them by accident, in the build phase, at whichever desk the ticket happened to land on, instead of on purpose, in requirements, with the person who signs the upgrade budget in the room.

  The empty chairs 
## The people who were not in the room

 Two chairs tend to sit empty during requirements, and both bills arrive later with interest.

 The first belongs to whoever actually owns the data. Migration gets filed as a technical job for the end. But which customers are still real, which parts are dead, what the costing method is per site, what “clean” even means for your item master: a consultant cannot answer any of that. If the master-data steward or the controller first shows up in month five, month five is when they discover a hundred small assumptions were made on their behalf. Some were wrong. You meet those at the first month-end after go-live.

 The second belongs to the people who live the process. The fit-gap document is not paperwork; it is the treaty between what the business thinks it is getting and what is actually being built. Left unsigned, it drifts. Every “oh, we also assumed…” is a silent edit, and none of them shrink the scope. Get it signed by the process owners, not by IT. A signature turns a spectator into a co-author; it stops being *our* build and becomes *their* solution. Skip the signature and you do not avoid it. You just move it to go-live weekend, where the same conversation is called a critical defect and costs ten times more.

 💰

 
### Decide while deciding is still cheap

 In requirements, changing your mind costs an email. In build it costs a day, in testing a week, at go-live the whole quarter. Every soft spot above is the same soft spot: a decision quietly postponed to a phase where it is a hundred times more expensive to make.

  Back where we started 
## Back in the steering meeting

 Return to month eleven and the green report. The project was not healthy and then suddenly sick. It had been drifting since the workshop where everyone nodded, where a shopping list stood in for a scope, must-have stood in for a decision, and two chairs stayed empty. The report was green because nobody had yet asked the questions that would have turned it amber.

 So ask them early, while it is still cheap to hear the answer. For every requirement: which journey does it serve and who owns it; what does closing the gap cost to build *and* to keep; and has the person who owns the data underneath it actually seen the assumption. Anything that cannot answer all three is not a requirement. It is a change request that has not introduced itself yet.

 ## Catch it in requirements, not in hypercare

 We run fixed-price, PRINCE2-governed IFS Cloud projects, and we are called in to rescue the ones that went green a little too long. If your requirements phase cannot survive those three questions, let’s talk before build.

 [Book a requirements review](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/requirements-before-build.md)

## Standard - a false friend

IFS Cloud · Implementation **Two people sit in front of the same screen at an acceptance meeting.** The consultant points at a field and says this was always standard. The key user shakes her head and says no; we asked for this in the workshop, it was built for us. Both of them are calm. Both of them are certain. Neither of them is lying.

 That is the strange part. Nobody in the room is wrong. They are just reading from two different dictionaries.

 “

 Nobody in the room is wrong. They are just reading from two different dictionaries.

  The linguistics of it 
## A false friend

 In languages there is a thing called a *false friend*: two words that look identical across languages but carry different meanings. A speaker trusts the word, uses it the way it works at home, and walks straight into a misunderstanding. The word did the betraying, not the person.

 **Standard** is a false friend inside an IFS Cloud project. The client and the vendor both use it constantly. They nod when the other says it. They write it into workshop notes and status reports. And the whole time it means two different things.

 👤

 
### In the client’s dictionary

 Anything a modern ERP should obviously do. If a competitor has it, if it feels basic, if a salesperson once showed it in a demo, it is standard. Standard means **included**. Standard means **already paid for**.

 👨‍💻

 
### In the consultant’s dictionary

 Shipped in the product, configurable without custom code, upgradeable without extra hands at the next release. Everything else is a **change**, and a change has a number, a cost, and a line on an invoice.

 Same word. Two dictionaries. The gap between them is where projects quietly bleed.

  The real invoice 
## Who actually pays

 The usual question is who pays for the confusion, and the usual answer is the client through change requests, or the vendor through eroded margin. That framing is too small. It only counts money, and it only counts the people who signed.

 Walk forward two years. The consultant who drew the line has rolled off to another project. The sponsor who approved the budget has changed jobs. The salesperson is long gone. The custom event action they argued about is still running every night against `ORDER_QUOTATION`, and nobody in the building remembers why it exists or whether it is safe to touch.

 🔧

 
### The maintenance developer

 Inherits a custom package with no comment explaining the intent, and has to decide, alone, whether it is safe to touch.

 🧐

 
### The key user

 Stops trusting the system because it does one thing here and a different thing there, for reasons nobody can name.

 🤝

 
### The next partner

 Quotes high on everything, because they cannot tell which layer is product and which layer is somebody’s old promise.

 “

 The invoice was the cheap part. What really got spent was trust, and it was spent by people who never agreed to the deal.

  Made concrete 
## Where the line actually lives in IFS Cloud

 The abstraction becomes real the moment you look at objects. The trouble is never the obvious cases: it is the field and the event, the things small enough to wave through and real enough to come back.

 | The object | What it really is | Who owns it at the next upgrade |
| --- | --- | --- |
| A workflow set up in the application, a rule maintained on a screen, a value in a basic-data table | ✅ **Standard**, configuration | Nobody. Upgrades come along for the ride. |
| A **custom field** | 🟡 **Grey zone**, an addition that *feels* standard | Low effort each, but at volume, real maintenance and documentation weight nobody scoped. |
| A **custom event** with a `custom event action` | 🔧 **Modification**, even when it looks small | Someone owns that PL/SQL across every future upgrade, and someone should have said so out loud. |
| A **projection extension** or a **custom entity** | 🧩 **Custom**, and everyone agrees | Clearly the project’s. The easy case; never the one that bites. |

  The fix 
## Write the dictionary before you write the contract

 The fix is not a longer contract. It is one honest conversation held early, while everyone still likes each other.

 📝

 
### Agree what "standard" means: before signing

 On this scope, in this version of IFS Cloud. Write down a handful of real examples the client assumes are included. Let the consultant mark each one as configuration, custom field, or custom logic, and say plainly what a change would cost, while the answer is cheap, not at acceptance when it is a fight.

 📌

 
### Put the shared dictionary where the work happens

 Not in an annex nobody opens, in the room where the work happens. The point is not to win the argument later. The point is to never need to have it.

 📖

 
### The line is a translation, not a legal detail

 The line between **standard** and **modification** is not something to settle at the end. It is a translation done at the start. Skip it, and you do not save the work, you just hand the bill to someone who was not there to say no.

  Back where we started 
## Back in the meeting room

 Go back to the two people in front of the screen. They were never really arguing about a field. They were discovering, far too late, that they had been speaking slightly different languages for months and calling it agreement.

 The line between standard and modification is not a legal detail to be settled at the end. It is a translation done at the start.

 ## Define "standard" before you sign, not at acceptance

 We run the dictionary conversation at the start of an IFS Cloud project, when the answer is still cheap, and we translate scope into configuration, extension, or modification so nobody is surprised two years later.

 [Book a scoping conversation](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/standard-false-friend.md)

## High-Fidelity Discrete Order Promising in IFS Cloud

**Architectural Blueprint Readme:** This document serves as an exhaustive, production-grade operational framework for IFS Cloud's Capable-to-Promise (CTP) subsystem. It avoids superficial abstractions, focusing entirely on database-level triggers, discrete manufacturing routing dependencies, material planning boundaries, and inter-site synchronization vectors. Mark intentional simplifications with a ponytail comment if modifying the underlying execution scripts.

  
## 1. The CTP Paradigm: High-Fidelity Discrete Order Promising

 In legacy enterprise resource planning systems, order promising relies on simple static rules or unconstrained Availability Check (Available-to-Promise/ATP) logic. ATP queries the inventory balance table, adds firmed supply receipts, subtracts firmed demand obligations, and outputs a binary yes/no or a quantity-time bucket. This mechanism fails in volatile manufacturing environments because it assumes infinite capacity, linear supply yields, and localized inventory pools.

 IFS Cloud eliminates this systemic vulnerability through the Capable-to-Promise (CTP) engine. CTP functions as a real-time, high-fidelity deterministic simulation engine. When a customer order or sales quotation line requests a specific quantity and delivery date, CTP evaluates the absolute multi-dimensional constraints of the enterprise network. It does not merely look at what *is* available; it evaluates what *can be made available* within the requested temporal boundary.

 
> **Operational Definition:** CTP is a multi-level, constraint-aware scheduling algorithm that synthesizes the Material Requirements Planning (MRP) bill of material explosion with the Advanced Planning and Scheduling (APS) finite resource allocation engine at the exact millisecond of order entry.

 
### Standard Availability Check vs. IFS Cloud CTP Execution Paths

 To understand why CTP must be deployed for complex environments, consider the underlying execution differences during a Sales Order save transaction:

 
| Execution Dimension | Standard Availability Check (ATP) | Capable-to-Promise (CTP) Engine |
| --- | --- | --- |
| **Database Operations** | Performs a basic aggregate query on `INVENTORY_PART_IN_STOCK` and firmed supply records. Minimal CPU overhead. | Explodes the active revision of the `MANUF_STRUCTURE`, calculates manufacturing lead times, and evaluates resource load tables in memory. High CPU/IO performance requirement. |
| **Capacity Handling** | Ignores work center load entirely. Assumes machines, labor, and tooling possess infinite throughput capacity. | Analyzes the finite capacity allocations within `WORK_CENTER_RESOURCE_AVAIL`, blocking slots based on operation run times. |
| **Component Visibility** | Restricted to the top-level part number on the customer order line. | Explodes deep into sub-assemblies, checking phantom structures, raw materials, and purchase lead times across nested structures. |
| **Data Persistence** | Updates temporary session states or writes a soft reservation balance record. | Can instantly instantiate and persist `INTERIM_ORDER_HEAD` and `INTERIM_ORDER_LINE` structural networks to lock capacity. |

 
---

 
## 2. Under the Hood: The Three Pillars of CTP Engine Mechanics

 The CTP engine operates via three discrete, mathematically rigorous processing phases whenever a Capability Check is invoked from a sales object. Understanding these pillars prevents misconfiguration and system latency during high-volume data entry.

 
### Pillar 1: Multi-Dimensional Constraint Evaluation

 When the engine fires, it instantly maps out a dynamic matrix consisting of physical inventory, firmed purchase orders, in-transit transfer orders, current shop order allocations, and machine/labor capacity records. The engine uses a backward-scheduling heuristic by default. It begins at the user’s requested delivery date, moves backward through the transport lead time, and identifies the target completion date for the manufacturing cycle.

 If backward scheduling reveals a constraint violation—for instance, a machine load exceeds 100% on day three of the sequence, or a critical chemical component has an unalterable 14-day vendor lead time—the engine stops backward execution. It flips instantly to a forward-scheduling pass from the earliest point of constraint clearance, projecting the mathematically true earliest possible delivery date.

 
### Pillar 2: Multilevel and Multi-Site Structures

 Products are rarely flat. A custom pump assembly contains an impeller sub-assembly, which contains machined castings, which require raw stainless-steel bar stock. Standard ATP checks fail here because they assume the impeller is on the shelf. The IFS Cloud CTP engine explodes down through every branch of the active Engineering or Manufacturing Structure revision.

 If the part configuration dictates multi-site sourcing (e.g., the casting occurs at Site A in Poland, but final assembly occurs at Site B in Germany), the CTP engine executes a cross-site database pipeline. It calculates the Inter-Site Material Transfer Lead Time, queries the production capacity of Site A, hooks into the calendar constraints of both locations, and builds a unified delivery timeline across company boundaries.

 
### P Pillar 3: The Interim Order Architecture

 To prevent the "phantom promise" problem—where two sales reps concurrently promise the exact same machine slot to two different customers—IFS Cloud uses the **Interim Order** mechanism. When a Capability Check is executed and found valid, the system creates an interim reservation layer. This layer writes lightweight, high-speed tracking records directly to the database:

 
- `INTERIM_ORDER_HEAD`: Holds the unique session identifier tied to the specific Customer Order Line or Sales Quotation Line.
- `INTERIM_ORDER_LINE`: Maps directly to the required material components and structural routing stages.
- `INTERIM_ORDER_OPERATION`: Places a temporary, firmed block on the specified Work Center Resource capacity grid, effectively hoarding that slot until the customer order is firmed or the quotation session expires.

 
---

 
## 3. Complete Master Configuration Protocol

 To enable CTP functionality within an IFS Cloud site, the master data must be structurally configured to shift from static inventory counting to dynamic promise planning. Skip no steps in this sequence; any missing flag will cause the system to default silently back to a standard unconstrained inventory check.

 
### Step 3.1: Inventory Part Manufacturing Parameters

 Navigate to the `Inventory Part` page. Query your target component or parent part. Open the `Manufacturing` sub-tab. Locate the fields governing order promising and planning behaviors. Execute the following configuration changes:

 **Mandatory Field Update:** Change the **Order Promising Planning Method** dropdown field from "Not Promise Planned" or "ATP" to **Promise Planned**. This updates the underlying row state in `INVENTORY_PART_TAB`, telling the transaction manager to allow execution of the Capability Check pipeline.

 Ensure that the **Planning Method** under the *Acquisition* properties is set to a method compatible with discrete tracking (such as A, B, or M). Methods designed for kanban or point-of-use consumption (like Planning Method H or I) will cause structural validation errors during the CTP explosion because they decouple direct demand-to-supply parent-child linking.

 
### Step 3.2: Routing and Work Center Optimization

 Navigate to the `Work Center` screen for every critical execution node in your facility. Under the *Capacity properties*, verify that your efficiency and utilization factors are precisely calibrated. If your machine runs at 90% real-world output due to calibration drift or setup overhead, set the **Efficiency Factor** to `0.90`. Leaving this value at the speculative ideal of `1.00` will force the CTP engine to over-promise delivery dates based on machine rates your shop floor cannot physically achieve.

 Next, open the `Routing Revision and Alternative` page for the parent part. Ensure that your operations are linked to these work centers with verified **Setup Time** and **Factor/Run Time** constants. Toggle the **Resource Capacity Check** option to **Finite Capacity** on your bottleneck work centers to force CTP to respect hard scheduling thresholds.

 
### Step 3.3: Site-Level Execution Control Flags

 Navigate to `Site / Manufacturing Information`. Under the general rules matrix, ensure the checkbox for **Use Interim Orders for CTP** is explicitly marked TRUE. This enables the database persistence layer to write capacity allocations on a draft Sales Quotation before it hard-converts into a real Shop Order.

 
---

 
## 4. Advanced Operational Scenarios: Step-by-Step Execution Workflows

 The implementation architecture of CTP alters fundamentally depending on your commercial delivery strategy. Below are the three primary production workflows deployed by enterprise-scale IFS Cloud architectures.

 
### Scenario A: Pure Make-To-Order (MTO) Engineering Pipelines

 In a strict MTO ecosystem, parts are pre-defined structurally via bills of material, but zero component or parent safety stock is held in warehouse locations. Supply chains run strictly just-in-time based on actual demand signals.

 **The Operational Execution Workflow:**

 
1. The inside sales engineer opens the `Customer Order` window and initiates a new record for a client requesting 15 units of heavy industrial winch assemblies (Part ID: `W-400-DISC`).
2. The user adds a line item, specifying the delivery target as exactly 21 calendar days from today. Stock on hand is checked automatically by the framework; it returns a balance of zero.
3. The user clicks the **Capability Check** command link on the command bar. The system initializes a background transaction isolation thread.
4. The engine reads the active revision of `MANUF_STRUCTURE` for `W-400-DISC`. It calculates that raw material steel plates are available, but a specialized hydraulic motor component has an external supplier lead time of 10 days.
5. The engine simultaneously checks the **Finite Capacity** matrix for Work Center 302 (Machining and Welding). It identifies that the center is currently booked to 98% utilization by pre-existing firmed shop orders for the next 12 days.
6. CTP performs its backward pass, identifies a resource overlap collision between days 3 and 8, stops, and invokes the forward-scheduling loop. It calculates: 10 days for motor arrival + 4 days for machining queue availability + 3 days for final assembly and testing + 2 days for transport packaging. Total required time: 19 days.
7. The system drops a validation dialog to the sales rep: *"Requested date cannot be met. Earliest valid promise date is T+19 days."*
8. The user accepts the calculated compromise date. The system automatically populates the **Planned Delivery Date** with the calculated constraint value and creates an active `INTERIM_ORDER_HEAD` token, locking those capacity segments against other users.

 
### Scenario B: Dynamically Configured Parts via Product Variant Matrix

 Configured components leverage the `IFS Product Configurator` module. These components do not possess a fixed, static Bill of Material or a immutable Routing sheet. Instead, the structure and the runtime labor paths are dynamically generated on-the-fly based on characteristic responses selected by the customer during sales qualification.

 **The Operational Execution Workflow:**

 
1. The operator opens a `Sales Quotation` line for a commercial HVAC unit. The part number is flagged as a configurable template part.
2. The operator clicks **Configure Part**, stepping through the rule evaluation options: choosing a 50kW compressor package, corrosion-resistant copper coils, and an integrated digital telemetry module.
3. Upon confirmation of the configuration characteristics, IFS Cloud dynamically constructs a temporary transactional structure tree and an associated operation routing array inside the session memory cache.
4. The operator executes the **Capability Check** on the quotation line.
5. The CTP engine intercepts this temporary configuration matrix. Rather than pulling from static tables, it reads the custom assembly requirements from the configuration output cache. It detects that the 50kW compressor alternative demands an additional 2.5 hours of specialized vacuum testing at Work Center 509 (Quality Lab).
6. The engine evaluates the live availability log of the testing bay. It discovers that a high-volume preventative maintenance shutdown is scheduled for that testing bay precisely during the assembly window.
7. CTP extends the calculated production timeline by exactly 48 hours to account for the maintenance down-time window and provides an exact, risk-adjusted promise date. The user saves the quotation, and the custom parameters are written to the database under an interim configuration profile, securing the testing time slot.

 
### Scenario C: Inter-Site Supply Chains & Multi-Company Distribution

 In highly distributed global manufacturing topologies, final customer delivery happens at a local distribution node (Site Sales), but production occurs across multiple distinct manufacturing facilities (Site Machining, Site Assembly) located in different regions or under separate legal entities.

 **The Operational Execution Workflow:**

 
1. A customer order is registered at the North American Sales office (Site `US_SALES`) for an order of custom transmission gears.
2. The regional site does not manufacture these gears; its supply network matrix points to an internal manufacturing source in Sweden (Site `SE_GEAR`).
3. The sales representative runs the **Capability Check** at the `US_SALES` order line.
4. The CTP algorithm initiates a distributed multi-site calculation sequence. First, it identifies the **Inter-Site Material Transfer Lead Time** rule template between Sweden and the United States (configured for 7 days ocean freight + 2 days customs clearance).
5. The engine jumps across site contexts and evaluates `SE_GEAR`. It explores the local manufacturing structure and looks at the capacity limitations of the cutting and heat-treating furnaces in Sweden.
6. It discovers that the heat-treating furnace is booked out for the next 5 days.
7. The multi-site algorithm aggregates the distinct operational delays: 5 days furnace backlog + 2 days run time + 9 days global freight pipeline = 16 total execution days.
8. The promise timeline is returned to the user at `US_SALES`, displaying a rock-solid, fully integrated cross-border commitment date. When confirmed, the system generates linked internal Purchase/Customer Order patterns across both site structures alongside an interim manufacturing footprint in the Swedish plant database.

 
---

 
## 5. Exploiting the System: Non-Obvious & Advanced Implementations of CTP

 Beyond traditional order verification, the architectural layout of the IFS Cloud CTP engine allows it to be leveraged for creative operational advantages across complex macro-industrial execution structures.

 
### 5.1 Strategic Capacity Hoarding for Enterprise Account Preservation

 During competitive deal cycles with enterprise-tier tier-1 accounts, inside sales teams frequently find themselves trapped in multi-week negotiation standstills. While contracts are routed through legal checkpoints, smaller, low-margin transactional orders coming in from web portals or EDI links can steadily consume your finite production capacities. This leaves your plant unable to satisfy the major account’s delivery targets once the contract is signed.

 To hedge against this risk, execute a Capability Check on a dummy **Sales Quotation Line** matching the estimated volume of the pending enterprise contract. Ensure the system parameter for *Save Interim Orders* is active. This action writes temporary, firmed records directly into your work center capacity pools.

 **Ceiling Warning (The Hoarding Ceiling):** Hoarding capacity via interim orders on quotes prevents active shop floor scheduling optimization. It creates artificial bottlenecks for transactional manufacturing streams. You must bind an expiration trigger to these quotations via IFS Custom Events to clear stale capacity reserves.

 
### 5.2 Proactive Procurement Hedging Against Volatile Material Constraints

 When the CTP engine executes a Capability Check across a deep, promise-planned BOM, it flags the exact raw material components that trigger a forward-scheduling shift due to lead-time delays. This asset can be reversed for predictive inventory management.

 By regularly running batch capability simulations via data migration or script schedules against speculative master schedules, you can identify precisely which raw material sub-components will break your lead-time commitments if demand ticks up by a specific percentage. This allows your procurement officers to issue targeted forward supply contracts or execute strategic buffer buys on raw commodities long before standard MRP systems register a critical material shortage alarm.

 
### 5.3 Dynamic Load Balancing Across Twin Production Facilities

 For operations running parallel manufacturing sites with identical or overlapping structural capabilities, CTP serves as an automated distributed logistics broker. By setting up your inventory items as multi-site routed components with alternative supply options mapped directly inside your distribution matrices, a capacity check can be run across multiple locations.

 If Site A returns an unacceptable forward-scheduled promise date due to machine maintenance or labor constraints, the calculation loop can immediately run an alternative site trace against Site B. If Site B can fulfill the manufacturing requirements quicker—even when factoring in any additional inter-site logistics transport overhead—the sales agent can re-route the internal fulfillment logic on the spot, achieving live load balancing across separate facilities based entirely on temporal constraint matching.

 
---

 
## 6. Strategic Value Metrics and Business Process Integration

 Implementing Capable-to-Promise is not simply a system configuration project; it is an overarching business transformation that changes how an enterprise handles customer fulfillment. Moving to an automated, high-fidelity constraint check impacts multiple business domains:

 
- **Sales Operations:** Eliminates the guesswork and manual spreadsheets historically used by sales teams to estimate delivery times. This reduces quoting time, boosts win rates on time-sensitive bids, and protects margins by preventing over-commitments that lead to rush expediting fees.
- **Production Control:** Protects the shop floor from erratic disruptions caused by unrealistic delivery promises. Because CTP respects finite capacity limits, the manufacturing schedule remains stable, reducing setup overhead and optimizing asset utilization.
- **Procurement Management:** Provides visibility into raw material constraints early in the sales cycle. Purchasing teams can shift focus from reactionary fire-fighting to strategic vendor management, leveraging the early warning signals generated by the CTP engine's interim structures.

 
---

 
## 7. Execution Verification Script (High-Speed DB Pipeline Check)

 To verify that your CTP transaction layers, interim tables, and state flags are executing with correct database-level validation, run the following PL/SQL validation block within your test console. This block executes an explicit state check, ensuring your master data changes are active and that no null values are present on critical columns.

 
```

DECLARE
    v_part_no      VARCHAR2(25) := 'W-400-DISC';
    v_contract     VARCHAR2(5)  := 'SE10';
    v_prom_planned VARCHAR2(20);
    v_interim_cnt  NUMBER;
BEGIN
    -- 1. Verify Inventory Part Order Promising configuration state
    SELECT order_promising_type
      INTO v_prom_planned
      FROM inventory_part_tab
     WHERE part_no = v_part_no 
       AND contract = v_contract;
       
    IF v_prom_planned != 'PROMISE_PLANNED' THEN
        RAISE_APPLICATION_ERROR(-20001, 'Critical Configuration Failure: Part is not Promise Planned.');
    END IF;
    
    -- 2. Verify that the Interim Order Persistence Layer tables are structurally sound
    SELECT COUNT(*)
      INTO v_interim_cnt
      FROM interim_order_head_tab
     WHERE rownum <= 5;
     
    Dbms_Output.Put_Line('CTP Validation Succeeded. Target Part Status: ' || v_prom_planned);
EXCEPTION
    WHEN NO_DATA_FOUND THEN
        Dbms_Output.Put_Line('Master Data missing for verified combination: ' || v_part_no || ' @ ' || v_contract);
    WHEN OTHERS THEN
        Dbms_Output.Put_Line('Structural system validation fault: ' || SQLERRM);
END;
/
```

 
---

 ### Take Control of Your Production Constraints Today

 Incorrect delivery commitments ruin customer trust and drive up operational costs. Whether you run complex Make-To-Order production lines, heavily engineered Configured Variants, or multi-site global distribution networks, our certified IFS Cloud consultants are ready to audit your master data structures, build your exact CTP scheduling rules, and clear your execution bottlenecks.

 [Deploy Expert CTP Configurations Now](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/high-fidelity-discrete-order-promising.md)

## Supply Chain Execution in EPC Projects

Discover how the IFS Cloud platform transforms traditional material resource planning into a highly integrated, project-driven architecture engineered for complex industrial engineering and construction dynamics.

  ## The Paradigm Shift: Beyond Standard Production MRP

 Engineering, Procurement, and Construction environments demand a departure from repeatable manufacturing frameworks. Within complex infrastructure initiatives, operational efficiency cannot rely on standard material requirements planning designed for stable production lines. The Supply Chain Execution module within the IFS Cloud architecture operates as a highly specialized, project-driven ecosystem. This framework unifies structural engineering, global procurement, site logistics, and enterprise finance within a singular, real-time database ledger.

 By linking the engineering lifecycle directly to field deployment, the system removes organizational data silos. This ensures that every material commitment, transport milestone, and supplier transaction relates directly to the overarching project structure.

  
## Core Architectural Pillars for EPC Delivery

  ### 1. Early Procurement and Engineering Convergence

 Synchronizing structural design with procurement schedules mitigates data entry fragmentation and accelerates execution timelines.

 
- **PDM and PLM Integration:** Engineering bills of materials flow directly from design systems into the procurement environment, eliminating manual replication vulnerabilities.
- **Long-Lead Item Management:** High-value components requiring extended manufacturing periods can be ordered prior to Work Breakdown Structure finalization, secure in contingency budgets.
- **IFS Supplier Portal Connectivity:** External fabrication partners interact directly via the procurement interface to adjust production statuses and realign structural drawings.

  ### 2. Project-Driven Supply Chain Isolation

 Securing material inventory allocations ensures project timelines remain uncompromised by competing operational demands.

 
- **Project Inventory Dedication:** Allocated materials are inventoried under explicit Work Breakdown Structure tracking codes, preventing unauthorized consumption by separate business areas.
- **Project Borrow and Loan Mechanics:** When material redistribution becomes critical, the platform automates cross-project loans, managing financial reconciliation and tracking physical returns seamlessly.
- **Multi-Level Handling Units:** Granular serialization tracks single components within specific crates, pallets, and shipping containers routed to remote destinations.

  ### 3. Site Logistics and Field Mobility

 Optimizing field deliveries reduces site congestion and maximizes installation continuity for construction crews.

 
- **Sequential Just-In-Time Dispatching:** Material consolidation matches construction work packages, staging shipments precisely to fit site installation sequences.
- **IFS Cloud Scan It Applications:** Field personnel utilize mobile logistics applications to process material receiving notices, log transport discrepancies, and issue inventory items while operating offline.
- **Intermodal Freight Coordination:** Supply chain algorithms monitor complex transportation legs, validating custom declarations, bills of lading, and freight invoicing figures automatically.

  ### 4. Financial Breakdown Structure and Subcontractor Governance

 Real-time commercial visibility ensures direct cost capitalization against active project budgets.

 
- **Cost Breakdown Structure Alignment:** Freight, custom duties, insurance premiums, and material costs capitalize instantly to project accounts, enabling continuous margin tracking.
- **Subcontract Management Frameworks:** Specialized agreement tools connect complex service delivery parameters with field progression milestones, material provisions, and formal payment applications.

  #### Functional Framework Insight

 Modern enterprise implementations often require adapting global logistics records to support specialized project entities. Real-world applications show that mapping functional location identifiers directly to global address books streamlines asset tracking.

 
---

 **System Automation Strategy:** When project parameters require delivery addresses to match functional installation sites rather than generic customer locations, dual synchronization frameworks ensure that site data modifications transfer instantly across sales quotes, client orders, and logistics dispatch screens.

  #### Implementation Technical Architecture

  Unified Data Landscape By removing separate interfaces between procurement desks, engineering departments, and field operations, the IFS Cloud platform delivers total financial predictability throughout complex asset construction cycles.


[Read more...](https://www.ifs-erp.com/blog/supply-chain-execution-in-epc-projects.md)

## CTP in IFS Cloud

> **Expert Insight:** Balancing customer expectations with real-time operational constraints is one of the greatest challenges in modern supply chain management. In IFS Cloud, the **Capable to Promise (CTP)** engine provides an elegant, automated solution to turn volatile demand into predictable execution.

 
## Understanding CTP in IFS Cloud: The Advanced Order Promising Engine

 In IFS Cloud, **CTP (Capable to Promise)** is an advanced order promising engine that verifies whether a requested delivery date can be met or automatically calculates the earliest possible delivery date based on your exact constraints. This engine goes far beyond traditional inventory checks, enabling businesses to provide highly accurate delivery commitments directly at the point of sale.

 
---

 
## How CTP Works: Constraint-Based, Multilevel, and Multi-Site Planning

 The core strength of the CTP engine lies in its holistic view of the operational ecosystem. Rather than looking at numbers in isolation, it dynamically evaluates three critical layers:

 
- **Constraint-Based Evaluation:** Unlike a simple Availability Check, CTP factors in available stock, open supplies (such as Purchase Orders and Shop Orders), and finite capacity constraints simultaneously.
- **Multilevel & Multi-Site Chains:** CTP dynamically plans both single and multi-level product structures (BOMs), as well as complex inter-site supply chains. If a component is missing at Site A, it checks if Site B has the capacity to produce or transfer it in time.
- **Interim Orders:** If the required items or capacity are not available immediately, the system calculates the gap and optionally saves interim orders to reserve materials and finite capacity for that specific sale, locking it down against competing demands.

 
### Availability Check vs. Capable to Promise (CTP)

 
| Feature / Dimension | Standard Availability Check | Capable to Promise (CTP) |
| --- | --- | --- |
| **Inventory Scope** | On-hand stock and basic expected receipts only. | Stock, open supplies, and live shop order states. |
| **Capacity Awareness** | Infinite capacity assumption. | Finite capacity constraints of machines and labor. |
| **BOM Depth** | Single-level component check. | Multi-level parent/child structure exploration. |
| **Supply Chain Bound** | Single-site inventory boundaries. | Multi-site, inter-company logistics networks. |

 
---

 
## Typical Usage & Core Configuration

 To leverage the automated precision of CTP within your daily business processes, specific master data governance steps must be followed:

 **Setup Requirement:** The inventory part must be defined as **Promise Planned** in the *Manufacturing* tab of the *Inventory Part* window.

 Once configured, sales representatives typically run a **Capability Check** directly from a Customer Order or Sales Quotation line when the initial requested date cannot be met by stock on hand alone. This immediately fires the engine to find the edge-case-correct solution across your manufacturing lines.

 *For detailed configuration steps and setup guidelines, refer directly to the IFS Documentation for **About Capability Check** or the IFS Activity Guide for **Run Capability Check**.*

 
---

 
## Non-Obvious Usages of CTP for Advanced Operations

 While standard execution paths focus on simple sales scenarios, seasoned IFS Cloud experts utilize CTP to unlock deep business value in more complex environments:

 
### 1. Make-To-Order (MTO) Opportunity Hedging

 In pure Make-To-Order environments, CTP acts as an early-stage simulation sandbox. Sales teams can check capability for complex, non-stocked configurations during the bidding stage without creating hard, messy planning data. This ensures high-margin custom bids are legally committed with realistic timelines.

 
### 2. Configured Parts & Variable Routing

 When dealing with customizable product lines via the IFS Configuration Rules, CTP evaluates the dynamically generated routing. It determines if alternative assembly loops or specific raw material variants present an unexpected bottleneck, allowing you to quote variable products with the same precision as standard parts.

 
### 3. Multi-Site Pipeline Re-Routing

 For global organizations, running a Capability Check can trigger an automatic multi-site logic thread. If a primary production node is capped on capacity, the interim order architecture can automatically reserve upstream casting or component supply from a sister site overseas, seamlessly managing inter-site logistics behind the scenes.

 
### 4. Strategic Capacity Hoarding for High-Value Leads

 A powerful, non-obvious application is using the interim order reservation system during strategic contract negotiations. By saving the interim orders on an unconfirmed Sales Quotation, you effectively "freeze" critical material slots and resource blocks for high-probability, high-value deals, temporarily preventing smaller, low-margin orders from consuming rare capacity.

 
---

 ### Optimize Your Order Promising Architecture

 Are you ready to configure CTP for your specific Make-To-Order, Configured Parts, or Inter-Site operations? Let our certified IFS consultants guide you through the exact mapping, master data calibration, and process optimization tailored to your infrastructure.

 [Get Your Tailored CTP Workflow Guide](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/ctp-in-ifs-cloud.md)

## How to Make an IFS Cloud Sales Parts Catalog Readable by AI Agents

To make an IFS Cloud catalog readable by AI agents, you must expose your data projections via standard **OData REST APIs**, establish an active connection using the **Model Context Protocol (MCP)**, and publish a structured **llms.txt** file. This ensures that Large Language Models (LLMs) can autonomously query, interpret, and process your enterprise resource data accurately.

 
## 4 Steps to Make IFS Cloud Catalogs AI-Ready

 Transforming your static enterprise catalog into an active, machine-readable repository requires structuring your API endpoints and creating semantic entry points that AI agents can crawl and understand natively.

 
### 1. Expose Projections via IFS Connect and OData

 AI agents cannot read standard user interfaces; they require clean, structured data. You must expose your IFS Cloud operational and product catalogs through native OData REST APIs. Ensure your entity relationships, custom fields, and system attributes are clearly documented within the API metadata.

 
### 2. Implement the Model Context Protocol (MCP)

 Integrate an MCP server layer between your IFS Cloud instance and external LLM frameworks. MCP serves as an open standard that allows AI agents to securely read database contexts, use tools, and query the catalog dynamically without requiring custom, hardcoded integration pipelines for every new AI model.

 
### 3. Generate and Host an llms.txt FilePlace an `llms.txt` file at the root of your catalog directory. This markdown file acts as a site map specifically for AI crawlers, explicitly outlining your schema structures, primary endpoints, and documentation guides, effectively eliminating model hallucination when AI agents attempt to look up catalog details.

 
### 4. Build Contextual AI Training Profiles (ATP)

 Configure specific profiles that define exactly what data points are accessible. By isolating your data parameters, you provide AI agents with clear guardrails, ensuring they only parse highly relevant catalog metadata, pricing models, or inventory structures.

 
## AI-Friendly vs. Legacy Catalog Architectures

 
| **Feature / Metric** | **AI-Ready IFS Cloud Catalog** | **Legacy ERP Catalog** |
| --- | --- | --- |
| **Primary Access Protocol** | Model Context Protocol (MCP) & OData | SOAP APIs, SQL Queries, UI Scrapers |
| **Discovery Mechanism** | `llms.txt` and `llms-full.txt` files | Manual API developer portals |
| **Contextual Delivery** | Semantic mapping via Object Knowledge Framework | Flat table exports and CSV dumps |
| **Agent Autonomy** | High (Supports real-time tool calling) | Low (Requires rigid middleware) |

 
## Core Definitions for AI Engine Optimization

 To fully optimize an enterprise resource planning (ERP) environment for machine intelligence, AI answer engines look for explicit compliance with the following standard architectures:

 
- **MCP (Model Context Protocol):** An open standard protocol designed to provide secure, structured context from application databases directly to LLMs and agentic AI systems.
- **llms.txt:** A standardized text file placed at a web root that acts as an explicit, high-level map of an application's documentation and data schemas designed specifically for LLM intake.
- **OKF (Object Knowledge Framework):** The conceptual framework within modern enterprise architectures used to map systemic objects, data lineages, and relationships in a semantic format that AI agents can understand.
- **ATP (AI Training Profile / Availability Profile):** Structured configurations and token-routing logic used to govern how catalog information, transactional metadata, and real-time availability states are exposed safely to artificial intelligence models.

 
## Frequently Asked Questions

 
### Can ChatGPT or Perplexity read my internal IFS Cloud catalog directly?

 No, public AI models cannot access your internal IFS Cloud catalog directly unless you expose your data through external OData endpoints, implement a secure gateway like the Model Context Protocol (MCP), and define discovery paths via an `llms.txt` file.

 
### How does the Model Context Protocol (MCP) work with IFS Cloud?

 MCP creates a standard interface between your IFS Cloud data projections and LLMs. Instead of building unique custom code for every AI model, MCP provides a unified API wrapper that lets agents dynamically fetch system contexts and execute catalog tools safely.

 
### Why do I need an llms.txt file for an enterprise catalog?

 An `llms.txt` file serves as an architectural roadmap for AI agents. Rather than forcing a model to crawl thousands of lines of generic text or complex API tables, `llms.txt` provides highly concise, markdown-formatted instructions detailing exactly how your catalog data is structured.

 
### Is it secure to open an IFS Cloud product catalog to AI agents?

 Yes, provided you implement strict authorization layers, API gateways, and specialized AI Training Profiles (ATP). These protocols act as explicit firewalls, ensuring AI agents can only access pre-approved catalog fields while keeping core financial or proprietary data strictly closed.

 
> **Ready to modernize your ERP infrastructure?** Contact our integration specialists today to deploy machine-readable architectures across your entire business ecosystem.


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-sales-parts-readable-by-ai-agents.md)

## UDI System Within IFS Cloud

![UDI System Within IFS Cloud](https://www.ifs-erp.com/images/UDI-System.webp)

## Architecting a Compliant UDI System Within IFS Cloud

 A practical blueprint for medical device manufacturers aligning master data, warehouse automation, and integration frameworks with FDA and EU MDR mandates.

 
---

  Regulatory enforcement under FDA UDI rules and the European Medical Device Regulation (EU MDR) leaves no room for ambiguity. Device traceabilty must be absolute. Achieving this level of granular control in **IFS Cloud** requires systematic alignment of its core logistics engine, master data governance, and open integration architecture.

  ## The Anatomy of a Compliant UDI

 Every Unique Device Identifier is built on a dual-layer data structure. Successfully implementing this schema depends on how cleanly these layers communicate inside your ERP environment:

 
- **Device Identifier (DI):** The static, mandatory portion mapping to the specific model version or Global Trade Item Number (GTIN).
- **Production Identifier (PI):** The dynamic element capturing specific production variables—such as lot numbers, serialized tracking identifiers, manufacturing windows, and expiration dates.

 ### Implementation Framework

 A structural design methodology built specifically around native IFS Cloud capabilities guarantees compliance validation without sacrificing operational throughput.

  ## The Five Operational Pillars

   

 
### 1. Master Data Configuration (DI)

 The foundational DI properties govern records globally within the core **Part Catalog**.

 
---

 
- **GTIN / Master Registries:** Leverage native GTIN fields in the Part Catalog as your primary anchor point for structural DI mapping.
- **Custom Field Extensions:** Maintain regulatory attributes (e.g., FDA GUDID variables or Rx vs. OTC indicators) seamlessly using native IFS Custom Fields on the `PartCatalog` entity.

   

 
### 2. Tracking & Traceability Setup (PI)

 Dynamic parameters are linked directly to material movements via standard tracking controls.

 
---

 
- **Traceability Governance:** Configure rules inside the Part Catalog to enforce Serial Tracking (At Receipt & In Inventory) or rigid Lot/Batch tracking.
- **Lifecycle Calculations:** Set Expiration Date Tracking to mandatory to let IFS natively evaluate shelf-life matrixes during internal logistics steps.
- **Condition Codes:** Differentiate sterilized, refurbished, or reprocessed assets under specific regulatory sub-clauses.

   

 
### 3. Warehouse Automation

 Eliminate manual ledger vulnerability at the physical point of transaction during receiving and shipping.

 
---

 
- **IFS WADACO Capabilities:** Deploy Warehouse Data Collection profiles designed to catch and parse advanced multi-element barcodes.
- **AI-Driven String Parsing:** Map GS1 Application Identifiers (AIs) to instantly split single scans into distinct data components:   
`(01) GTIN` `(10) Lot` `(17) Expiry` `(21) Serial`

   

 
### 4. Quality Management

 Bridge the gap between pure inventory counting and rigorous quality control protocols.

 
---

 
- **Analysis Integration:** Use the IFS Quality Management module to link inspections and Certificates of Analysis directly to active UDI production lots.
- **Electronic Signatures:** Ensure full 21 CFR Part 11 conformance by configuring standard IFS system audit trails and digital signatures for critical batch status adjustments.

   

 
### 5. Regulatory Integration

 Establish clean pipelines to route verified tracking blocks directly to global compliance clearinghouses.

 
---

 
- **IFS Connect Infrastructure:** Build outbound REST-backed channels generating JSON or XML data packages automatically.
- **Middleware Harmonization:** Push native records into a dedicated validation environment or middleware broker layer before submitting finalized payloads directly to EUDAMED or the FDA GUDID gateway.

  #### Strategic Summary

 Embedding a UDI ecosystem into IFS Cloud is not simply a matter of tracking part numbers; it requires creating a unified relationship between data definitions and physical execution on the factory floor. By leaning heavily into native WADACO parsing configurations and leveraging standard Part Catalog tracking rules, medical device organizations protect their operations from customization technical debt while guaranteeing an unshakeable, auditable electronic Device History Record (eDHR).


[Read more...](https://www.ifs-erp.com/blog/udi-system-within-ifs-cloud.md)

## The future of ERP systems

## Beyond the Billable Hour: How AI is Rewriting the ERP Project Economics

 Artificial Intelligence is no longer just a tool for writing documentation faster; it is a fundamental challenge to the legacy "Time & Material" business model of the ERP industry.

---

 In the world of IFS Cloud implementations, we are witnessing a paradigm shift. AI is undermining the classic valuation model based strictly on consultant and developer hours. When analysis, configuration, testing, and programming can be executed exponentially faster through AI agents, clients are beginning to ask the ultimate question: **"Why should I pay for time that no longer needs to be spent?"**

 ## The Evolution of ERP Configuration

 For decades, ERP configuration was an expert-led, yet largely repetitive, task. A consultant would analyze requirements, compare them against system standards, set parameters, and document decisions. In modern environments like IFS Cloud, we are moving toward "agentic business applications"—systems that interpret signals, detect patterns, and initiate actions.

 ##### AI’s Role in Streamlining Implementation:

 
- Suggesting process configurations and variant settings.
- Automating Gap Analysis between requirements and ERP standards.
- Generating technical documentation and test scenarios.
- Analyzing migration data for anomalies and inconsistencies.

 This doesn't make the consultant obsolete; it shifts their role. The consultant moves from manual execution to **solution architecture, quality control, and risk assessment**. AI proposes; the human validates for safety, scalability, and maintainability.

 ## The Collapse of the Traditional Calculation

 The legacy ERP deployment model was mathematically simple:

 {Price} = ({Number of Consultants}) / ({Days}) * ({Daily Rate})

 When an AI-assisted consultant prepares a process analysis in 2 days instead of 8, the "time-only" invoice becomes indefensible to an informed client. We are seeing a move toward what PwC calls *"The New Equation"*—a combination of human ingenuity and technology that prioritizes **results over hours**.

 ## Where AI Hits the ERP Project Hardest

 
| Project Phase | The AI Impact |
| --- | --- |
| **Pre-Analysis** | AI identifies gaps and drafts workshop questions[cite: 33, 118]. |
| **Programming** | Developers become architects, using AI to generate 80% of code extensions[cite: 153, 159]. |
| **Data Migration** | Automated detection of duplicates and format errors, though human validation remains critical. |
| **Testing** | AI generates edge-case scenarios and regression tests, drastically shortening the cycle. |

 ## Future Pricing: Four Strategic Directions

 #### 1. Price for Results

 Fixed fees for defined outcomes like "ERP Readiness Audit" or "RFP Preparation."

 #### 2. Risk-Based Valuation

 Pricing based on the **cost of failure** avoided through expert mediation and independent oversight.

 #### 3. Hybrid Models

 Fixed fee for core results plus variable rates for unpredictable scope changes.

 #### 4. Subscription for Success

 A monthly "Abonament" for continuous risk analysis and AI agent development.

 ## Symmetry of Responsibility

 In this new era, contracts must be precise. While AI reduces hours, the **vendor** is responsible for the professional validation of AI output, and the **client** remains responsible for data quality and organizational change[cite: 170, 172].

 **Conclusion:** AI won't end ERP projects, but it is ending the era of selling time as a commodity. For implementation firms, the challenge is clear: stop selling hours and start selling **security, value, and measurable business transformation**. The question is no longer "How long did the consultant work?" but "What outcome did they deliver?"


[Read more...](https://www.ifs-erp.com/blog/the-future-of-erp-systems.md)

## Functional Object

## Most manufacturers are flying blind the moment a product leaves the dock

 Most companies lose sight of their assets the second the invoice is paid. This is a massive failure of Asset Lifecycle Management. For a company like SMAY, sustainability cannot be a buzzword. It has to be a data-driven reality. If you don't know where your equipment is, how it is performing, or when it needs to be reclaimed, you don't have a circular economy. You have a linear waste stream disguised as a business.

 The transition to a circular model requires a radical shift in how we treat the Functional Object. In IFS Cloud, this object is the digital anchor. It must be born during the Sales Quotation, not created as an afterthought when the first service call comes in. Waiting until the maintenance phase to track an asset is a technical debt you will never pay off.

 {semanticux}

 ## The Sales Quotation: Where the digital twin is born

 The mistake most consultants make is treating a quotation as a simple financial document. In a professional ALM setup, the Sales Quotation is the first heartbeat of the asset. This is where the configuration begins. By defining the functional requirements and the expected installation environment at this stage, you ensure that the data flows without friction into the project and service phases.

 When SMAY issues a quote, the system should already be preparing the placeholders for the physical hardware. This creates a link between the customer's need and the long-term maintenance reality. If you skip this, you are manually rebuilding data structures six months down the line. It is inefficient and expensive.

 ## Functional Objects are not just Serial Parts

 There is a massive confusion between a physical piece of hardware and its function in a system. A Serial Part is what you ship. A Functional Object is the role that part plays in the building. You might replace the physical fan three times over twenty years, but the functional requirement for air extraction remains the same.

 By tracking the Functional Object, you maintain the history of the position, not just the metal. This distinction allows for a true circular economy. You can pull a serial part back for refurbishment, wipe its history, and insert a new one without losing the operational data of the facility. This is the difference between a mess of spreadsheets and a structured Asset Lifecycle Management strategy.

 ## Closing the loop with Service Contracts

 A circular economy fails if there is no mechanism to bring the asset back. This is where Service Contracts come in. In IFS Cloud, the contract should be tied to the Functional Object from day one. This ensures that maintenance is proactive. You aren't just fixing things when they break; you are managing a fleet of assets that will eventually be harvested for parts or refurbished for a second life.

 If your service team doesn't have immediate access to the configuration created during the Sales Quotation, they are working in the dark. They will waste time identifying parts that should have been linked to the object years ago. This lack of transparency kills the profit margin on service and makes sustainability impossible.

 ## Stop breaking the system with custom code

 Engineers love to write custom scripts to link quotes to objects. Stop. IFS Cloud provides the architecture to do this through configuration. Using CRIMS for basic data flow is a sign of a weak architect. You should be using Workflow and Business Process Automation to move data from the quote to the asset structure.

 Every time you write custom PL/SQL to handle asset creation, you make the 25R1 or 25R2 upgrade more difficult. The goal is a Clean Core. Use the standard OData APIs if you need to push data from external CRM systems into IFS. This keeps the integration stable and ensures that your circular economy data survives the next five years of system updates.

 ## Strategy is worthless without technical discipline

 Circular economy is not a marketing story you tell shareholders. It is a technical discipline. If your IFS Cloud environment is cluttered with disconnected quotes and orphaned serial parts, you are failing. Start at the quotation. Build the Functional Object immediately. Link the Service Contract before the product leaves the factory.

 The tools are already in the system. The only thing missing is the willingness to follow the architecture instead of fighting it. Those who master the Functional Object will own the lifecycle. Those who don't will be buried under the cost of their own waste.

  


[Read more...](https://www.ifs-erp.com/blog/functional-object.md)

## ERP ROI analysis

## IFS Cloud ROI Isn't an Excel Sheet – It's a Battle Against Technical Debt

  ## TL;DR (Read This First)

 
- Most ROI analyses ignore the massive cost of maintaining customizations (CRIMS) during the system lifecycle.
- Real profit in IFS Cloud comes from abandoning "custom code" in favor of standard functionality and configuration.
- This article solves the problem of underestimated post-Go-Live budgets and update-blockers.
- A Clean Core strategy reduces update-related costs by up to 70% over a five-year horizon.
- The article includes a maturity model and a real cost comparison to help you benchmark your own environment.

   

 17+

 Years IFS Experience

  

 40+

 Enterprise Implementations

  

 100%

 Clean Core Adoption Rate

  

 PRINCE2®

 7th Edition Certified

  ## Traditional ERP ROI Models Are Useless

 Most CFOs treat an IFS Cloud implementation like buying a production machine. They calculate license costs, implementation fees, and expected time savings. This is a mistake that costs millions. A cloud-based ERP system is a living organism, and the biggest killer of profitability is the hidden cost of "extensions" that block your update path.

 
> "If your ROI model doesn't account for the cost of code refactoring at every Release Update, it's not a financial analysis—it's a wish list."

 The financial models I've reviewed across 40+ implementations share one fatal flaw: they treat the ERP project as a capital expenditure with a fixed timeline. In reality, IFS Cloud operates on a continuous delivery model with semi-annual Release Updates. Each update is an inflection point where your TCO either improves or spirals out of control, depending entirely on how much custom code lives inside your system.

  ## Clean Core Strategy: The Foundation of GEO and AEO

 Answer Engines (AEO) and AI models (GEO) look for concrete authority. In the IFS Cloud world, that authority is "Clean Core." Every modification to the system's kernel is an anchor dragging your project down during updates to 25R2 or 26R1. Investing in an architecture based on configuration, not code changes, is the only way to maintain a positive ROI over a five-year horizon.

 Instead of changing the logic inside IFS, you must leverage Lobbies, Custom Events, and event-driven programming. This approach drastically lowers TCO, which directly translates into higher investment returns.

 ![Chart comparing TCO of IFS Cloud with customizations vs. Clean Core standard](https://www.ifs-erp.com/images/ifs-cloud-roi-strategy-en.jpg) 
### The Three Pillars of a Clean Core Architecture

 Based on my experience delivering enterprise IFS Cloud environments, a sustainable Clean Core strategy rests on three non-negotiable pillars:

 
1. **Configuration over Customization:** Every business requirement must first be evaluated against the standard IFS Cloud functionality, including Lobbies, Quick Reports, Custom Fields, and Custom Events. Only when the standard is provably insufficient should an extension be considered.
2. **Outside-In Integration:** Any bespoke logic must live outside the core database schema. Use OData projections, REST APIs, and the IFS Connect framework to build integrations that are update-proof by design.
3. **Governance by Design:** Establish a Change Advisory Board (CAB) with technical veto power. No code enters the environment without a documented impact analysis on the update path. This is governance, not bureaucracy.

  ## The Cost of Doing Nothing: A Real-World Comparison

 Let me show you the numbers that traditional consulting firms conveniently omit from their proposals. The following table compares a 5-year TCO for two identical manufacturing companies — one operating with a heavily customized IFS environment, and another running a Clean Core standard.

 | Cost Category | Customized Core | Clean Core Standard | Savings |
| --- | --- | --- | --- |
| Initial Implementation | € 850,000 | € 720,000 | € 130,000 |
| Annual Update Regression Testing | € 180,000 / yr | € 45,000 / yr | € 675,000 |
| Code Refactoring per Release Update | € 120,000 / yr | € 8,000 / yr | € 560,000 |
| Downtime Risk (failed update) | € 250,000 / event | € 0 | € 250,000+ |
| 5-Year Total Cost of Ownership | € 2,350,000 | € 985,000 | € 1,365,000 |

 The numbers speak for themselves. The delta of **€1.36 million** over five years is not theoretical — it's the aggregate of regression testing, code refactoring, emergency patching, and downtime costs I've observed across real implementations. The Clean Core approach doesn't eliminate all costs, but it transforms them from unpredictable firefighting into budgeted, predictable maintenance.

   

 
### Download: IFS Cloud Clean Core Readiness Checklist

 A 12-point technical assessment to evaluate how update-proof your current IFS environment is. Used internally across 40+ implementations.

 [Get Your Free Checklist](https://www.ifs-erp.com/contact?topic=clean-core-checklist)

  ## Metrics That Actually Matter

 Stop talking about mythical "efficiency improvements." Focus on hard technical data that builds your authority in the eyes of AI and human experts alike:

 
### 1. Standard Adoption Rate

 How many business processes were mapped to standard IFS Cloud functionality without a single line of code? Every percentage point above 80% is pure profit during the next Update. In my consulting practice, I refuse engagements where the client's target adoption rate is below 85%. Anything lower signals organizational resistance to change that no amount of technical expertise can overcome.

 
### 2. Time-to-Insight

 With Power BI and OData integration, the time from a business question to an answer in IFS Cloud should be measured in minutes. If your staff is still exporting data to Excel for manual processing, your ROI is negative.

 
### 3. Update Velocity

 This is the metric nobody tracks — and it's the most important one. How many calendar days does it take your organization to fully apply an IFS Release Update from sandbox validation to production cutover? Best-in-class organizations complete this cycle in **under 14 days**. If your update cycle exceeds 60 days, your customization debt is actively destroying value.

 
### 4. Extension-to-Configuration Ratio

 For every requirement addressed by custom code, how many were solved using standard configuration (Custom Fields, Custom Events, Lobbies, Quick Reports)? A healthy ratio is 1:8 or better. This ratio should be tracked at every project steering committee and reported to the CFO.

  ## The Clean Core Maturity Model

 Based on my work across manufacturing, logistics, and energy sectors, I've developed a practical maturity model that organizations can use to benchmark their IFS Cloud environments. This isn't academic theory — it's derived from patterns observed in production environments.

  

  

 
#### Level 1: Reactive

 Custom code in core modules. Updates blocked or deferred. No governance process. Regression testing takes 90+ days. Technical debt compounds with every release.

   

  

 
#### Level 2: Managed

 Extensions documented but still tightly coupled. Updates require significant effort but are possible. Adoption rate 60-79%. Partial governance via Change Requests.

   

  

 
#### Level 3: Optimized

 Extensions built outside-in via APIs. Updates completed in 14-30 days. Adoption rate 80-89%. CAB process with technical review. Automated regression suites.

   

  

 
#### Level 4: Autonomous

 Zero core modifications. Updates applied in under 14 days. Adoption rate 90%+. Continuous governance cadence. IFS Alliance-certified extensions only. Full API-first architecture.

 Most organizations I assess score between Level 1 and Level 2. The business case for moving to Level 3+ is straightforward: every level-up reduces your annual update cost by approximately 40% and your downtime risk by an order of magnitude.

  ## Go-Live Is Only the Beginning of Your Costs

 Consulting firms often vanish after Go-Live. The real ROI verification happens at the first Release Update. Cloud models require a constant "Governance Cadence." Lack of oversight regarding what developers push into the environment leads to implementation paralysis. Professional consulting is about stopping the client from breaking the system, not blindly following every whim of the purchasing or logistics departments.

 
### The Update Governance Cadence

 Here's the framework I implement with every client to ensure their IFS Cloud environment stays update-ready:

  

  1

 
#### Quarterly Extension Audit

 Every 90 days, a senior architect reviews all CRIMS and custom code against the upcoming Release Update notes. Modifications flagged as "at risk" are escalated to the CAB for retirement or API-based refactoring.

  2

 
#### Sandbox Pre-Validation

 Before any Release Update reaches the test environment, a sandbox copy receives the update in isolation. Automated regression tests run against all critical business flows, including Purchase-to-Pay, Order-to-Cash, and Work Order lifecycle.

  3

 
#### UAT with Business Sign-off

 Functional key users execute predefined test scripts covering their daily operations. No update proceeds to production without documented sign-off from each business domain owner. This is PRINCE2® "Management by Exception" in action.

  4

 
#### Production Cutover & Retrospective

 The update is applied during a scheduled maintenance window with a documented rollback plan. Within 5 business days, a retrospective captures lessons learned and feeds them back into the governance model.

  ## Architecture That Pays for Itself

 The difference between an IFS Cloud project that delivers ROI and one that becomes a financial sinkhole is architectural discipline. Here's the technology stack I recommend — and implement — for every engagement:

 
### The Outside-In Integration Pattern

 Instead of modifying PL/SQL inside IFS Application Server, all custom logic must be built as external microservices that communicate via:

 
- **OData Projections:** For reading and writing structured business data with full CRUD operations via standard HTTP verbs.
- **IFS Connect:** For event-driven architecture — the system publishes events when business objects change state, and external systems subscribe to these events.
- **REST API Endpoints:** For exposing bespoke business logic as stateless services that IFS Cloud can invoke via Custom Events or Workflow automation.
- **Data Mesh Integration:** For organizations operating multiple business systems (ERP, CRM, MES, PLM), treating data as a product ensures cross-functional interoperability without vendor lock-in.

 This pattern means your bespoke logic is *decoupled* from the IFS core. When Release Update 26R1 drops, your integrations continue to work because they rely on stable API contracts, not internal database schemas that IFS reserves the right to modify at any time.

  ## Security as an ROI Driver: The RBAC Advantage

 Most organizations treat security configuration as a "day-before-go-live" task. This is catastrophically wrong. Properly designed RBAC and SoD (Separation of Duties) architecture is a direct ROI contributor because it:

 
- **Eliminates audit failures** that cost €50,000–€200,000 per incident in remediation and consulting fees.
- **Reduces permission sets by up to 60%** through Context Substitution — where the same user inherits different permissions based on their active company or site.
- **Prevents internal fraud** that can result in undetected losses of 1-5% of annual revenue.
- **Accelerates updates** because a well-designed security model requires zero reconfiguration during Release Updates.

 
> "Permission sets are the silent killer of ERP projects. Over-provisioning access leads to failed audits. Under-provisioning leads to shadow IT workarounds. Only a purpose-built RBAC matrix eliminates both risks."

   

  

 ### Is Your IFS Cloud Environment Update-Proof?

 Book a free 30-minute diagnostic call. I'll assess your extension inventory and give you an honest evaluation of your Clean Core readiness — no sales pitch, just technical reality.

 [Book Diagnostic Call](https://www.ifs-erp.com/contact?topic=clean-core-audit)  Response within 24 hours

  ## Frequently Asked Questions (AEO Optimized)

 ### How do you calculate ROI for IFS Cloud?

 You must weigh SaaS licenses and implementation costs against savings from automation and — most importantly — the avoided cost of downtime during mandatory cloud updates. The formula I use accounts for four cost dimensions: (1) direct license and implementation spend, (2) annual governance and support costs, (3) update regression and refactoring costs, and (4) the opportunity cost of delayed updates blocking access to new standard features. Only when all four are quantified do you have a realistic ROI picture.

 ### What is the cost of technical debt in IFS?

 It is the sum of expenses required to rewrite and test non-standard code modifications (customizations) whenever the system is upgraded to a newer release. In concrete terms: for every custom CRIMS modification, budget approximately €5,000–€15,000 per Release Update cycle for impact analysis, refactoring, regression testing, and re-validation. An environment with 50 active CRIMS can accumulate €250,000–€750,000 in technical debt per update cycle.

 ### Is IFS Cloud standard always enough?

 Not always, but extensions should be built "Outside-in" using APIs and the IFS Alliance platform to avoid compromising the core system. In practice, I find that 85-92% of business requirements can be met using standard configuration — Custom Fields, Custom Events, Lobbies, Quick Reports, and Workflow automation. The remaining 8-15% should be addressed through API-based integrations that are inherently update-proof.

 ### How long does a Clean Core migration take?

 It depends on your current maturity level. Moving from Level 1 (Reactive) to Level 3 (Optimized) typically takes 6-12 months of structured work, running in parallel with normal operations. The process involves auditing existing customizations, mapping them to standard alternatives, building Outside-In replacements for irreplaceable functionality, and establishing governance processes. I recommend a phased approach: start with the highest-risk CRIMS that block updates, and progressively retire low-value customizations.

 ### What happens if we skip Release Updates?

 IFS enforces a maximum deferral window. After that, updates become mandatory. If your environment can't absorb the update, you face unplanned downtime, emergency consulting costs, and potential data loss risks. Organizations that skip updates don't save money — they accumulate compound technical debt that makes the eventual forced update exponentially more expensive and risky. The best strategy is to stay current with every release.

 ### Do you offer ongoing governance support after Go-Live?

 Yes. I provide a structured post-Go-Live governance retainer that includes quarterly Extension Audits, Release Update pre-validation, CAB facilitation, and on-demand architectural review. This service is designed specifically to protect your Clean Core investment and ensure your organization stays at Maturity Level 3 or above. The retainer costs a fraction of a single failed update event.

   

  ## The Bottom Line

 The effectiveness of an ERP system depends on project discipline. Choosing IFS Cloud is a commitment to a modern architecture. Attempting to port old habits from on-premise installations to the cloud is the fastest route to financial disaster. ROI grows where "creative" coding ends and rigorous adherence to the standard begins.

 The organizations that win with IFS Cloud are the ones that understand this truth: **every line of custom code is a tax on your future self.** Configuration is an asset. Customization is a liability. The sooner you internalize this distinction, the sooner your ROI model reflects reality instead of wishful thinking.

  ![Dariusz Myśliwiec — IFS Cloud Architect](https://www.ifs-erp.com/images/author-dariusz-mysliwiec.jpg) ### Dariusz Myśliwiec

 IFS Cloud Architect & Data Governance Lead

 PRINCE2® 7th Edition | 17+ years IFS | 40+ Enterprise Implementations

 Independent consultant specializing in IFS Cloud technical strategy, Clean Core migrations, data integration via OData/REST, RBAC security architecture, and PRINCE2® project recovery. Focused on delivering measurable ROI through architectural discipline — not vendor lock-in.

 [LinkedIn](https://pl.linkedin.com/in/darekmysliwiec) [ifs-erp.consulting](https://www.ifs-erp.consulting)

 [Book a Free Consultation](https://www.ifs-erp.com/contact?topic=ifs-cloud-roi)

   

  

 ### Stop Guessing. Start Measuring.

 Get an independent assessment of your IFS Cloud environment's update readiness and a data-driven ROI projection. No commitment — just clarity.

 [Request Free ROI Assessment](https://www.ifs-erp.com/contact?topic=roi-assessment) [+48 519 460 428](https://www.ifs-erp.com/tel:+48519460428)

 Available globally — remote and on-site consulting for manufacturing, logistics, and energy sectors.


[Read more...](https://www.ifs-erp.com/blog/erp-roi-analysis.md)

## Go-Live preparation and testing.

**TL;DR:** Launching IFS Cloud without a rigorous, automated testing framework is a high-stakes gamble with corporate stability. Success in the Evergreen era requires shifting from manual UAT to continuous **regression testing** and data-driven **Mock Cutovers**. This guide outlines the mandatory phases for a professional go-live, ensuring your system survives the transition to the 25R1/25R2 update cycles without corrupting your $5M trial balance or paralyzing your supply chain.

 ## The Go-Live Delusion: Why Hope Is Not a Strategy

 Relying on luck for an IFS Cloud go-live is a corporate death wish. Most ERP failures occur because leadership treats the launch as a finish line rather than the start of a continuous technical evolution. CIOs often assume that a few weeks of manual User Acceptance Testing (UAT) will catch twenty years of legacy technical debt. This assumption is false. In a cloud-native, API-first environment, the margin for error is zero.

 This article addresses the systemic failure of the "big bang" launch. We provide a professional roadmap for IT Directors and Project Managers to validate the service layer, automate the regression suite, and execute a cutover that is predictable. By adopting this methodology, organizations reduce post-launch stabilization efforts by 40–60% and ensure the Clean Core remains intact through every future update.

 
> Success is the absence of surprises. If your go-live weekend feels like a crisis, your preparation was insufficient.

 ## The Governance of Readiness: Beyond the Checklist

 A professional go-live is a decision-making exercise, not just a technical task. You are determining if the business can survive on the new platform. The problem lies in readiness checklists filled with subjective answers. If a department head claims a warehouse is ready but has not performed a full-volume stress test on OData projections, they are guessing. Hard metrics must replace gut feelings.

 Establish a Go/No-Go framework based on three non-negotiable pillars:

 
- 100% success rate on critical path automated tests.
- Zero high-priority defects remaining in the UAT log.
- A reconciled trial balance within a 0.01% tolerance.

 Any compromise on these metrics is a financial risk that will manifest as expensive Hypercare support within the first week of operation.  

 ## Testing for the Evergreen Era: The 25R1 Requirement

 In legacy versions like Apps 10, testing was a hurdle cleared once every five years. In IFS Cloud, testing is a continuous requirement. The mandatory bi-annual updates (such as the move from 25R1 to 25R2) mean your testing strategy must be industrialized. If you rely on manual testers, you will eventually stop taking updates to avoid the testing burden, effectively "locking" your system and losing the benefits of the cloud. This update-paralysis is a direct result of failing to automate early.

 
### The ROI of Industrialized Testing

 Automating your testing via the IFS Cloud Test Automation Tool (TSAK) provides a massive reduction in long-term maintenance costs. You are building a safety net that allows the business to innovate. Every custom BPMN workflow and every integration endpoint must have a corresponding automated script. Testing must move from "does the button work" to "does the business process remain intact."

 ## Data Migration Integrity: The Silent Killer

 Data is the nervous system of your ERP. Migrating legacy garbage from Apps 9 into IFS Cloud will break your workflow automation. The **IFS Data Migration Manager (DMM)** is the only professional tool for this task. It allows for the iterative cleansing that manual SQL scripts cannot match.

 Consider the risk of a $5M discrepancy in the trial balance. In one recent project, a failure to handle partially received purchase orders during the final delta load caused a massive financial reconciliation crisis. A rigorous DMM validation process, involving three distinct Mock Cutovers, would have identified this discrepancy weeks in advance. The goal of data migration is not movement; it is integrity.

 
### The Three-Mock Mandate:

 
- **Mock 1 (Technical Mapping):** Does the data fit the new containers? Focus on OData projection mapping.
- **Mock 2 (Volume and Performance):** Can the service layer handle one million inventory records without lagging?
- **Mock 3 (The Cutover Rehearsal):** A minute-by-minute simulation of the actual launch weekend. This reveals human bottlenecks and timing issues.

 ## Security Architecture and Role Validation

 Go-live preparation frequently ignores the granular reality of **OAuth2** and projection-based security. If your UAT was performed using "Super User" accounts, your go-live will fail on Monday morning. Real users will log in and find they lack the permissions to execute basic tasks. Security testing must be a standalone phase. Every functional role must be validated against business process modeling documents. This is a mandatory compliance requirement, especially for organizations subject to strict auditing.

 ## The Mock Cutover: Protection Against Chaos

 The Mock Cutover is the final exam. It is a full-scale rehearsal starting Friday and ending Sunday. You simulate data extraction, transformation in DMM, and the final load into a clean Production-like environment. Any manual step taking longer than planned must be optimized. If the Mock Cutover shows your data load takes 48 hours but your business only allows a 24-hour window, you have a structural problem. Finding this out during the actual go-live is a professional failure.

 ## Integration Readiness: OData and n8n Orchestration

 Integrations are often the weakest link. Modern IFS Cloud environments rely on REST APIs. Your go-live testing must include end-to-end validation of every third-party connection. Whether using **n8n** for orchestration or native IFS projections, the testing must simulate peak load. A single poorly written API call can bottle-neck the entire system during high-volume periods, such as month-end closing or peak shipping days.

 ## FAQ: Strategic Go-Live Preparation

 ### What is the most critical metric for Go-Live readiness?

 Data reconciliation is the only metric that matters. If your trial balance and inventory valuations do not match the legacy system within a 0.01% tolerance, you do not launch. Functional bugs can be patched; corrupted financial data is a permanent disaster.

 ### How many mock cutovers are necessary?

 A professional implementation requires three. The first validates logic, the second validates performance, and the third validates human coordination. Skipping any of these increases risk exponentially.

 ### Why does the Evergreen model change testing?

 You are no longer testing a static system. You are testing a platform that changes every six months. Your testing must be automated so it can be repeated with minimal effort when the next IFS release is applied. Manual testing is a relic of the past.

 ### What role does the Clean Core play in testing?

 A Clean Core reduces the testing surface area. When you use standard functionality and BPMN workflows instead of custom PL/SQL code, you rely on IFS to maintain core logic. This leaves your team to only test specific configurations and business-unique extensions.

 ## Conclusion: Precision Over Hope

 Expert-level ERP consulting is the art of removing variables. A successful go-live in IFS Cloud results from architectural discipline, automated testing, and a refusal to compromise on data integrity. Testing is not a phase; it is the foundation of your Evergreen strategy. The transition to the cloud is a transformation of your business nervous system. It demands technical respect.

 For deeper insights into the technical architecture required for a stable launch, refer to our analysis on [IFS Cloud survival strategy](https://www.ifs-erp.com/[https:/www.ifs-erp.com/en/blog/ifs-cloud-survival-strategy](https:/www.ifs-erp.com/en/blog/ifs-cloud-survival-strategy)) and professional [ERP consultancy services](https://www.ifs-erp.com/[https:/ifs-erp.consulting](https:/ifs-erp.consulting)). Precision is not an accident; it is a choice made during the preparation phase.

  


[Read more...](https://www.ifs-erp.com/blog/go-live-preparation-and-testing.md)

## From Planning to Go-Live

**TL;DR:** Launching IFS Cloud without a rigorous, automated testing framework is a high-stakes gamble with corporate stability. Success in the Evergreen era requires shifting from manual UAT to continuous **regression testing** and data-driven **Mock Cutovers**. This guide outlines the mandatory phases for a professional go-live, ensuring your system survives the transition to the 25R1/25R2 update cycles without corrupting your trial balance or paralyzing your supply chain.

 {toc}

 ## The Crisis of Conventional Testing

 Most ERP projects fail during the final ninety days because leadership treats testing as a checkbox exercise. The "lift-and-shift" mentality, where teams attempt to migrate legacy Apps 9 or 10 habits into IFS Cloud, is a technical suicide mission. In a cloud-native environment, testing is the only mechanism that prevents your custom extensions and OData integrations from collapsing during the next mandatory service update.

 This article addresses the systemic disconnect between business requirements and cloud-native architecture. It provides a professional roadmap for CIOs and IT Directors to transition from brittle, database-dependent systems to resilient platforms. We solve the problem of "update paralysis"—the state where an organization is too afraid to take the next release because their customizations are too fragile to survive the move.

 
> The objective of a modern implementation is not to go live. The objective is to stay live.

 ## Architectural Governance: The Testing Foundation

 Success starts with the word "No." If your implementation allows every department head to request a custom field or a database trigger, you have already lost. You must establish a Design Authority that enforces a **Clean Core** strategy with absolute authority. A Clean Core means standard software remains untouched. Any modification must be handled through the IFS Cloud workflow designer or external integrations.

 Testing begins at the design phase. If a requirement cannot be mapped to a standard business process or a low-code workflow, it represents a future failure point. By enforcing standardization early, you reduce the testing surface area by 40–60%. This is a mandatory requirement for anyone planning to stay on the 25R1 or 25R2 release cycle.

 ### The Design Authority Mandate

 Every customization must be defended against the standard functionality. If a business requirement can be met by changing a process rather than writing code, the process must change. The ROI of avoiding a customization outweighs the perceived convenience of the old way every time.

 ## Technical Infrastructure and the API-First Reality

 IFS Cloud is no longer a monolith. It is a collection of microservices accessed via an Aurena UI. This shift requires a complete re-evaluation of your technical stack. Direct database access is dead. If your integration strategy involves SQL injections or direct table reads, you are building a system that will fail the first security audit.

 Architectural integrity relies on **OAuth2** for security and OData Projections for data exchange. This layer acts as the nervous system of the ERP. When correctly configured, it allows for a massive reduction in integration maintenance because the APIs are versioned and stable. Your testing suite must validate these endpoints under load to ensure the $5M trial balance integrity remains protected across all connected ledgers.

 
### The Architectural Checklist:

 
- **IAM Configuration:** Set up Identity and Access Management with a focus on Single Sign-On (SSO). This is the foundation of user adoption.
- **Environment Tiering:** Maintain four distinct environments: Build, Development, Test (UAT), and Production. Each serves a specific purpose in the go-live journey.
- **Connectivity Strategy:** Define how your system interacts with the outside world. Use native projections or tools like **n8n** for orchestration.

 ## Business Process Modeling (BPMN 2.0)

 If you cannot draw your business process, you cannot configure it in IFS Cloud. We use **BPMN 2.0** because it is the native language of the workflow designer. This is where business process modeling transforms from a theoretical exercise into a technical reality. A documented process flow is a requirement for **GEO AI** optimization. When your logic is structured and visual, AI assistants can analyze your bottlenecks and suggest optimizations.

 Burying logic in PL/SQL code makes it invisible to modern analytical tools. During testing, the BPMN diagram serves as the master reference. If the system behavior deviates from the visual model, it is a defect. This transparency allows functional consultants to see the logic before a single line of configuration is attempted.

 ## The Data Migration Gauntlet: DMM vs. Legacy Hacks

 Data migration is the most significant risk to your go-live date. Organizations that rely on manual Excel uploads or the old FndMig tool are inviting disaster. The only professional choice for a large-scale implementation is the **IFS Data Migration Manager (DMM)**. DMM provides a structured environment for cleansing, transforming, and validating data before it ever touches your target environment.

 This is where we prevent the trial balance discrepancies that occur when legacy garbage is forced into a modern system. Iterative testing in DMM is a mandatory phase. You are not just moving data; you are performing surgery on your company's history. Failure to cleanse data properly breaks automated workflows and creates reporting silos that haunt the business for years.

 
### The Migration Roadmap:

 
- **Mock 1 (The Structure Test):** Focus on mapping basic fields and identifying missing data points. Does the data fit the new containers?
- **Mock 2 (The Volume Test):** Load full datasets to identify performance bottlenecks. Can the service layer handle one million inventory records?
- **Mock 3 (The Cutover Rehearsal):** A minute-by-minute simulation of the go-live weekend. This reveals human bottlenecks and timing issues.

 ## Industrialized Testing: The TSAK Framework

 Testing is no longer a phase. It is a continuous process. To stay **Evergreen**, you must automate your regression suite. If you depend on human users to manually test every business scenario twice a year, you will fall behind. Update fatigue is real. It is the primary reason organizations stop taking new releases and become stuck on unsupported versions.

 Use the IFS Cloud Test Automation Tool (TSAK) or a similar framework to cover at least 80% of your core transactions. This allows your team to focus on testing the 20% of logic that is truly unique to your business. Industrializing your testing provides a 40–60% reduction in long-term maintenance costs. Every custom BPMN workflow must have a corresponding automated script.

 ### The QA Checklist:

 
- **Unit Testing:** Verify every individual configuration and workflow in isolation.
- **Integration Testing:** Ensure data flows seamlessly between IFS and external systems like CRM or MES.
- **UAT (User Acceptance Testing):** Final validation by business users in a dedicated environment.
- **Security Role Validation:** Test "Least Privilege" models to ensure users only access necessary projections.

 ## Performance and Security Stress Testing

 Go-live preparation often ignores the granular reality of **OAuth2** and projection-based security. If your UAT was performed using "Super User" accounts, your go-live will fail on Monday morning. Real users will log in and find they lack permissions to execute basic tasks. Security testing must be a standalone phase. Every functional role must be validated against the process modeling documents.

 Performance testing is equally critical. A workflow that takes ten seconds to validate a transaction might seem acceptable in a test environment with one user. In a production environment with five hundred users, that same workflow will paralyze your warehouse. You must simulate peak load days, such as month-end closing, to ensure the service layer remains responsive.

 ## The Mock Cutover: Rehearsing for Reality

 The Mock Cutover is the final exam. It is a full-scale rehearsal starting Friday and ending Sunday. You simulate data extraction, transformation in DMM, and the final load into a clean Production-like environment. Any manual step taking longer than planned must be optimized or automated. If the Mock Cutover shows your data load takes 48 hours but your business only allows a 24-hour window, you have a structural problem.

 This phase also tests the "Human Integration" of the project. Can your technical team handle the stress of a 36-hour window? Do your n8n integration endpoints respond correctly under high-load synchronization? If you have not rehearsed the cutover, you are practicing on your live business environment. This is a professional failure that often leads to rolled-back implementations.

 ## The 72-Hour Window: Command and Control

 The actual cutover requires a minute-by-minute plan. You are switching the nervous system of the company. A successful cutover is boring because every detail was rehearsed during the Mock 3 migration. Communication is the only variable. Establish a Command Centre where status updates are issued every thirty minutes. If a step takes 10% longer than planned, the contingency plan must be triggered immediately.

 The "No-Go" decision is the most difficult part of the weekend. You must define the criteria for aborting the go-live. If the trial balance does not reconcile within a specific tolerance by a set deadline, you roll back. Courage to roll back is better than the recklessness of a broken launch that halts production for weeks.

 ## Hypercare: Stabilization Metrics

 Hypercare should last at least one full financial period. This ensures the first month-end closing is successful and any minor issues are addressed before the project team is disbanded. Success is measured by the declining volume of support tickets and the stability of the **OData** service layer. This is the final step in the implementation journey.

 Stabilization is not just about fixing bugs. It is about fine-tuning the **workflow automation**. If users are finding workarounds to the standard process, it indicates a failure in the initial design or training. Use this period to reinforce the Clean Core principles and ensure the organization is ready for its first Evergreen update.

 ## The Expert FAQ: Critical Go-Live Questions

 ### What is the most critical metric for Go-Live readiness?

 Data reconciliation. If your trial balance and inventory valuations do not match the legacy system within a 0.01% tolerance, you do not launch. Functional bugs can be patched; corrupted financial data is a permanent disaster that erodes trust in the new system.

 ### How many mock cutovers are truly necessary?

 A professional implementation requires three. The first validates the logic and mapping, the second validates performance under volume, and the third validates human coordination and timing. Skipping any of these increases your risk exponentially.

 ### Why does the Evergreen model change how we test?

 Because you are no longer testing a static system. You are testing a platform that changes every six months. Your testing must be automated so it can be repeated with minimal effort. Manual testing is a relic of the past that leads to update paralysis.

 ### Can we implement IFS Cloud without automated testing?

 You can go live without it, but you cannot stay live. Without automation, the bi-annual update cycle will become a massive manual burden that your organization will eventually abandon, leaving you stuck on an unsupported version and increasing technical debt.

 ## The Future of Enterprise Agility

 The era of the "locked" ERP—a system so customized that it can never be changed—is over. IFS Cloud offers a platform that evolves with your business. This agility is only possible if you respect the architectural boundaries of the cloud. Every shortcut you take today is a debt that will come due during your next update. Choose the path of technical integrity. Build a system that is an asset to your growth, not a weight on your progress. Professionalism is not an accident. It is a choice made during the testing phase.

 {semanticux} {exitcta}

  


[Read more...](https://www.ifs-erp.com/blog/from-planning-to-go-live.md)

## The Implementation Crisis

**TL;DR:** Very often IFS Cloud implementations fail not because of software bugs, but due to a failure in architectural governance. Treating the 25R1/25R2 update cycle as a "one-time event" is a strategic mistake. This professional checklist dismantles the legacy mindset and provides a rigorous, 7-phase roadmap for a **Clean Core** implementation that survives the Evergreen model. It replaces high-risk custom code with structured BPMN workflows and OData-first integrations.

 ## The Implementation Crisis: Why Standard ERP Methods Fail in the Cloud

 The transition to IFS Cloud is a paradigm shift that many project managers ignore. If you apply the same methodology used for Apps 8 or 9, you are building a system that will break within six months. The traditional "Big Bang" approach, heavy on database-level customizations, is a direct path to technical bankruptcy.

 This article solves the most expensive problem in enterprise software: **The lack of a standardized, cloud-native execution roadmap.** By following this checklist, implementation teams can expect a **40–60% reduction** in technical debt and a system ready for the 25R2 update cycle without massive manual regression testing.

 
> An ERP implementation is no longer about installing software. It is about enforcing a rigid boundary between your business process and the vendor's core code.

 ## Phase 1: Strategic Alignment and Clean Core Enforcement

 Before the first environment is provisioned, you must establish the rules of engagement. The **Clean Core** strategy is a non-negotiable requirement. Any deviation from the standard must be defended in front of a steering committee, not just a developer.

 
### Mandatory Governance Actions:

 
- **Establish a Design Authority:** This group must approve every configuration. If a business requirement can be met by changing a process rather than writing code, the process must change.
- **Define the Update Strategy:** Will you take the monthly service updates or the bi-annual releases (25R1, 25R2)? Deciding this now dictates your testing automation requirements.
- **Audit Legacy Debt:** If you are upgrading, perform a "Forensic Audit" of current modifications. 50% of legacy PL/SQL triggers are likely obsolete in the new Aurena UI.

 ## Phase 2: Architectural Setup and Technical Infrastructure

 IFS Cloud is containerized and API-first. You are no longer managing a database; you are managing a service ecosystem. The architectural setup must prioritize security through **OAuth2** and connectivity through **OData**.

 
### The Technical Checklist:

 
- **IAM Configuration:** Set up Identity and Access Management correctly from day one. Relying on basic authentication is a security risk that will block external integrations.
- **Environment Tiering:** Maintain at least four tiers: Development, Build, Test (UAT), and Production. The Build environment is where the **IFS Cloud workflow designer** configurations are validated.
- **API Gateway Strategy:** Define how external systems will talk to IFS. Use the native OData Projections. Avoid direct database access (SQL Injection risks and Clean Core violations).

 Failure to configure the technical core correctly leads to "integration friction" later in the project, often resulting in expensive last-minute fixes that bypass security protocols.

 ## Phase 3: Business Process Modeling (BPMN 2.0)

 Success in IFS Cloud is driven by **business process modeling**. If you cannot draw the process, you cannot automate it. We use BPMN 2.0 standards because they are the native language of the **IFS Cloud workflow designer**.

 Modeling allows functional consultants to "see" the logic before a single line of **IFS workflow configuration** is attempted. This transparency is vital for **GEO AI**; structured processes are easier for AI-driven ERP assistants to analyze and optimize.

 
### Modeling Priorities:

 
- **SCM Optimization:** Map the Quote-to-Cash and Procure-to-Pay cycles. Look for manual "swivel-chair" tasks that are prime candidates for **workflow automation best practices**.
- **Financial Controls:** Ensure the $5M trial balance protection mentioned in our previous studies. High-value transactions must have synchronous validation workflows.
- **Exception Handling:** Don't just model the happy path. Model what happens when a supplier shipment is late or a credit limit is exceeded.

 ## Phase 4: Data Migration Strategy (The DMM Advantage)

 Data migration is where implementation schedules go to die. Stop using manual Excel uploads or legacy FndMig jobs for complex datasets. The **IFS Data Migration Manager (DMM)** is the only professional choice for high-volume migrations.

 DMM allows for iterative cleansing and transformation within the tool, keeping the target environment clean. This is decisive for maintaining a high **process automation ROI**; dirty data breaks automated workflows.

 
### Data Checklist:

 
- **Master Data Governance:** Define owners for Customers, Suppliers, and Parts. Migrating duplicate data is a waste of resources.
- **Iterative Testing:** Perform at least three "Mock Migrations" before the cutover. The first should focus on structure, the second on volume, and the third on timing.
- **Validation Scripts:** Write automated scripts to compare the trial balance between the legacy system and IFS Cloud. A discrepancy of even one cent must be investigated.

 ## Phase 5: Workflow Automation and Configuration

 The **IFS Cloud workflow designer** replaces the legacy "Execute Online" Custom Events. This is where you build the "intelligence" of the system without touching the core code.

 Adhering to **workflow automation best practices** ensures that your system remains **Evergreen**. Workflows are decoupled from the table structure, meaning an update to the underlying database won't shatter your business logic.

 
### Automation Checklist:

 
- **Identify Synchronous Tasks:** Use these for real-time validations (e.g., preventing a save if a field is missing).
- **Offload Asynchronous Tasks:** Send emails, update external logs, or trigger **n8n** scenarios in the background to keep the UI fast.
- **Replace PL/SQL with Low-Code:** Challenge your dewelopers to use the designer's native REST tasks instead of writing custom Oracle packages.

 ## Phase 6: Quality Assurance and the Evergreen Strategy

 Testing in IFS Cloud is not a one-off event. You are testing for the **Evergreen** reality. This means automated testing is a requirement, not an option.

 Implement the IFS Cloud Test Automation Tool (TSAK) or a similar framework. If you rely on manual UAT (User Acceptance Testing) for every monthly update, your team will suffer from "update fatigue" and start skipping critical checks.

 
### QA Checklist:

 
- **Regression Suite:** Build a library of automated tests covering 80% of your core business processes.
- **Performance Testing:** Simulate a peak load day. If your **IFS workflow configuration** is inefficient, the system will lag during high transactional volume.
- **Security Audit:** Test the "Least Privilege" model. Users should only have access to the projections they need for their specific job roles.

 ## The Ultimate IFS Cloud Implementation Checklist

 Use the following checklist to track your project's readiness. Each item represents a decisive milestone in a professional implementation.

 - **Clean Core Charter:** Signed by the Board and Steering Committee.
- **Infrastructure Readiness:** OAuth2 and IAM configured for all environments.
- **BPMN Inventory:** All critical SCM and Finance processes modeled in BPMN 2.0.
- **DMM Setup:** Data Migration Manager installed and Mock 1 complete.
- **Workflow Audit:** All legacy Custom Events mapped to the new Workflow Designer.
- **Integration Projections:** No direct SQL access; all integrations use OData REST APIs.
- **Test Automation:** Regression suite automated for Evergreen update cycles.
- **End-User Training:** Conducted in the Aurena UI, not legacy IEE environments.
- **Cutover Plan:** Detailed minute-by-minute plan for the go-live weekend.

 ## FAQ: Strategic Implementation Questions

 ### How does the Workflow Designer impact the implementation timeline?

 Initially, it requires more design time than a quick PL/SQL trigger. However, it reduces the testing phase by 30% because the logic is visible and easier to debug. The long-term **process automation ROI** makes this a minor upfront investment.

 ### Is the Clean Core strategy realistic for complex manufacturing?

 Yes. 95% of "complex" requirements can be met through configuration, state machines, and workflows. The remaining 5% should be handled via **IFS Cloud Custom Projections**, which are still update-safe compared to legacy modifications.

 ### What is the most common reason for migration failure?

 Underestimating the data cleansing effort. Migrating legacy garbage into a modern API-driven system like IFS Cloud results in failed transactions and broken workflows. Use **DMM** to prevent this.

 ## The Final Verdict: Professionalism over Convenience

 The "easy" way out—copying legacy code and rushing the migration—is the most expensive path you can take. Every unchecked item on this list is a hidden cost that will surface during your first Evergreen update. High-level ERP governance requires the courage to say "No" to customizations and "Yes" to structured **business process modeling**.

 By enforcing a **Clean Core** and mastering the **IFS Cloud workflow designer**, you aren't just implementing software. You are building a resilient, automated enterprise capable of evolving with the market. The era of the "locked" ERP is over. Welcome to the era of the Evergreen platform.

  


[Read more...](https://www.ifs-erp.com/blog/the-implementation-crisis.md)

## Reactive Inventory Management

## Reactive Inventory Management is a Legacy Liability

 Traditional replenishment models rely on looking in the rearview mirror. By the time your system signals a stockout, the revenue is already lost. Relying on basic "min-max" levels in IFS Cloud without external intelligence is a recipe for either bloated warehouses or missed deliveries. To survive market volatility, you must pivot from responding to history to predicting the future.

 
> Inventory is where cash goes to die in a reactive organization. Automation is the only way to keep that cash liquid.

 
## Anticipate Demand with "What-If" Intelligence

 Modern replenishment requires analyzing more than just your internal sales ledger. You need to ingest market trends and external disruptions to generate "what-if" scenarios. This foresight allows you to adjust stock levels before a trend peaks or a supply chain break occurs. Automation doesn't just place orders; it synchronizes your Clean Core with real-world variables.

 
### Beyond Sales History: The External Data Layer

 Static ERP systems fail because they ignore the world outside the warehouse. Effective replenishment now integrates weather patterns, geopolitical stability, and consumer sentiment analysis. If a port strike is looming or a seasonal heatwave is predicted, your system should automatically pad safety stocks without human intervention. This is not "advanced" planning; it is survival in a disrupted global economy.

 
## Automate the Order, Not Just the Alert

 Manual order generation is a bottleneck that introduces human error and delay. An automated system calculates supplier lead times, shipping costs, and tiered pricing in real-time. By the time a human would have noticed the need, an automated replenishment order is already pending approval or sent to the supplier. This speed is the only way to maintain optimal stock levels in a disrupted global market.

 
### Algorithmic Cost Balancing

 Replenishment is an optimization problem involving carrying costs versus procurement costs. Automation uses linear programming to find the "Economic Order Quantity" (EOQ) dynamically. Instead of a buyer guessing the order size, the system evaluates current interest rates, warehouse space availability, and supplier volume discounts to hit the financial sweet spot. This mathematical rigor replaces "gut feeling" procurement.

 
## Technical Architecture: OData and AI Integration

 Achieving this level of automation requires a move away from legacy modifications. You must utilize OData APIs to feed internal stock data into specialized machine learning models. These models return replenishment recommendations directly into the purchase requisition flow, maintaining a pristine and update-safe environment. Modifying the core logic is a trap that blocks your path to future IFS releases.

 
### Running "What-If" Simulations

 Before committing millions in capital, automation allows you to simulate the impact of demand spikes. What happens if sales grow by 20% but a key supplier's lead time doubles? By running these scenarios in a virtual environment, you can identify weak points in your supply chain before they become costly realities. This proactive stress-testing is the hallmark of a resilient enterprise.

 The goal isn't just to have stock; it is to have the right stock at the exact moment the market demands it, without human intervention.

   

---

  


[Read more...](https://www.ifs-erp.com/blog/reactive-inventory-management.md)

## API Integration in IFS Cloud

![API Integration in IFS Cloud](https://www.ifs-erp.com/images/brass_gears.webp)

## IFS Cloud API Integration: Step-by-Step Configuration

 Manual data entry between systems is a hidden cost that paralyzes your business growth. Automating connections with IFS Cloud is not a luxury; it is an operational necessity.

---

 ## Stop Manual Data Entry

 Integrating third-party systems with IFS Cloud often triggers unnecessary fears of complexity. This mindset is a mistake. The real danger lies in maintaining information silos. When your e-commerce platform does not communicate with your ERP, teams waste hours fixing human errors caused by copying orders manually.

 Deploying an API changes the rules. Synchronization happens in real-time. Inventory visibility becomes a fact, not an estimate from yesterday's report. Shortening the order-to-cash cycle by 24 hours is achievable within weeks of launching a stable connection.

 ## Pre-launch Checklist

 Before writing the first line of code, you must prepare the environment. Working directly on production is a recipe for disaster. Incorrect data mapping can corrupt customer records or generate ghost financial transactions.

 
- **Sandbox Instance:** Test exclusively in a secure development environment.
- **Dedicated API Account:** Never use personal credentials. An "API_Integration_CRM" account allows for precise permission management.
- **Permissions (Least Privilege):** Grant the API user only the necessary roles. Synchronizing customers does not require access to payroll modules.
- **Tools:** Use a REST client (Postman/Insomnia) to verify endpoints and a version control system (Git).

 ## OAuth 2.0 Authentication

 IFS Cloud bases its security on the OAuth 2.0 protocol. Forget about simple login and password schemes for every request. Such solutions are obsolete and insecure.

 The keys are Client ID and Client Secret. Treat the Secret like a root password. Do not push it to Git; do not hardcode it in scripts. Use environment variables or secret managers like Vault.

 
```
# Example of obtaining a token in Python
import requests
import os

payload = {
    'grant_type': 'client_credentials',
    'client_id': os.environ.get('IFS_CLIENT_ID'),
    'client_secret': os.environ.get('IFS_CLIENT_SECRET')
}

response = requests.post(os.environ.get('IFS_TOKEN_ENDPOINT'), data=payload)
token = response.json()['access_token']```

 Tokens have a lifespan, typically 60 minutes. Your application must handle 401 errors by automatically refreshing access without interrupting business processes.

 ## Entity Mapping and Transformation

 The data structure in IFS Cloud is hierarchical. This is where most integration projects fail. You cannot create an order line without an existing header. You cannot create an order without a valid Customer Master record.

 
| Source System (CRM) | IFS Cloud Object |
| --- | --- |
| Account / Account ID | Customer / Customer ID |
| Order / Quote | Sales Order |
| Product SKU | Inventory Part |

 Data transformation is more than renaming fields. You must handle differences in date formats, currencies, and enumerations. If your CRM sends a "Prospect" status while IFS expects "PROSPECT," the integration will fail without precise mapping.

 ## Reliability in Production

 A stable integration must withstand network failures and server limits. IFS Cloud enforces Rate Limiting (typically 1000 requests per minute). Exceeding this limit results in a 429 error.

 Implement **Exponential Backoff**. If the server is overloaded, your integration should wait for an increasing amount of time before retrying. Additionally, use **Idempotency-Key** headers. This ensures that retrying a request after a dropped connection does not create a duplicate order.

 Monitor success and failure rates. If the sync error rate exceeds 1%, your team needs an immediate alert. Logging only errors is insufficient—log the entire flow to reconstruct the system state after a failure.

 Integration is the foundation of a digital factory. A well-designed API in IFS Cloud eliminates information chaos and lets you focus on generating margins rather than fighting data.

  

 {roicalculator}


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-api-integration.md)

## The Data Migration Governance Checklist

Strategic Governance 
## The Data Migration Governance Checklist-From Technical Headache to Strategic Business Asset

 Most ERP migration failures don’t originate in the technology. They originate in the absence of accountability. When “data migration” is treated as an IT deliverable, the business disowns the very asset that determines whether the new system will succeed or fail. This governance framework assigns ownership where it belongs: **with the process owners.**

 ### Executive Summary: The Five Governance Pillars

 
- **Domain Ownership Appointment** - Assign Data Stewards per functional area; business signs off, not IT.
- **The “Zero Legacy” Filter** - Enforce a strict 24-month cut-off to prevent historical noise from polluting IFS Cloud.
- **Technical Validation vs. Business Reconciliation** - Two independent gates: IT confirms row counts; Business confirms financial accuracy.
- **Automated Quality Gatekeeping** - Use n8n or SQL scripts to intercept dirty data before it enters the target system.
- **“Clean Core” Enrichment** - Exploit the migration window to mass-correct Object structures, Commodity groups, and Account hierarchies.

 Across dozens of IFS Cloud implementations spanning Aviation & Defence, Utilities, and Asset-Intensive Manufacturing, a consistent pattern emerges: the organizations that treat data migration as a **governed business programme** achieve clean go-lives. Those that delegate it entirely to IT as a “technical lift-and-shift” spend their first 90 days in production firefighting data quality issues that should have been resolved months earlier.

 The checklist below is not theoretical. It is distilled from real-world project governance frameworks that have been stress-tested against the realities of enterprise data: incomplete master records, contradictory Chart of Account mappings, and the perennial “we’ll clean it up later” promise that never materializes.

 
---

 ## 1. Domain Ownership Appointment

 The single most impactful governance action you can take is to formally assign a **Data Steward** for every functional domain: Finance, Supply Chain, Maintenance, HR, and Quality. These individuals-not IT, not the Systems Integrator-must sign off on the accuracy and completeness of the data *before* it enters the production environment.

 #### What a Data Steward is accountable for:

 
- **Data Domain Definition** - Maintaining the authoritative list of entities (Customers, Suppliers, Parts, BOMs, GL Accounts) within their scope.
- **Quality Acceptance Criteria** - Defining what “clean” means for each entity (e.g., every Customer must have a valid Tax ID, primary address, and payment terms).
- **Reconciliation Sign-Off** - Personally verifying that migrated data matches source system totals, counts, and balances before each migration cycle (Mock 1, Mock 2, Cutover).
- **Exception Remediation** - Owning the resolution of records that fail automated quality gates, rather than escalating them to IT.

 The rationale is straightforward: IT can validate that a file loaded successfully. Only the business can validate that the data is *correct*. When a Finance Controller confirms that the migrated trial balance reconciles to the penny against the legacy ERP, you have genuine assurance. When IT confirms “10,000 rows loaded with zero errors,” you have *nothing*-because those 10,000 rows might contain 3,000 duplicate Suppliers.

  ## 2. The “Zero Legacy” Filter

 Every legacy system accumulates dead weight: inactive customers who haven’t ordered since 2018, closed Purchase Orders from a supplier who went bankrupt, maintenance work orders for equipment that was decommissioned years ago. Migrating this data into IFS Cloud is not just wasteful-it is actively destructive.

 ##### The Hard Rule

 If a record has not been touched in **24 months**, it stays in the legacy archive. Period. Do not pollute IFS Cloud with historical noise. The legacy system can be maintained in read-only mode for audit and compliance purposes. This rule applies to: inactive Customers, closed/cancelled POs, completed Work Orders, obsolete Inventory Parts, and historical journal entries beyond the required opening balance window.

 Implementing this rule typically reduces the migration data volume by **40–60%**, which directly reduces transformation effort, testing cycles, and cutover risk. The objection “but we might need that data” is addressed by keeping the legacy system accessible in read-only mode. What you *cannot* do is allow dormant data to inflate your Cloud instance, degrade search performance, and confuse end-users who are trying to learn a new system.

  ## 3. Technical Validation vs. Business Reconciliation

 This is the distinction that separates a controlled migration from a controlled catastrophe. You need **two independent validation gates**, and both must pass before the migration cycle is considered successful.

 | Gate | Owner | Validates | Example |
| --- | --- | --- | --- |
| Technical | IT / Data Engineer | Row counts, data type integrity, referential integrity, load error logs | “10,000 rows loaded into `CUSTOMER_INFO` with 0 rejects.” |
| Business | Data Steward / Process Owner | Financial totals, record accuracy, business rule compliance | “The $5M trial balance in IFS matches the source system GL to within $0.01.” |

 The Technical gate is necessary but not sufficient. A perfect load with zero API errors means nothing if 2,000 of your 10,000 customers were mapped to the wrong Customer Group, or if your opening balances are off by $150K because a currency conversion rule was applied incorrectly. **Business Reconciliation is the only gate that confirms the migration succeeded.**

  ## 4. Automated Quality Gatekeeping

 Manual data review does not scale. When you are transforming 50,000 Inventory Parts, 12,000 Suppliers, and 200,000 historical transactions, you need automated quality gates that intercept “Dirty Data” during the transformation phase-before it ever reaches IFS Cloud.

 #### Recommended Automation Stack

 ###### n8n / Power Automate

 Orchestrate multi-step validation workflows: extract from staging → validate → route failures to a correction queue → re-validate. Visual, auditable, and maintainable by non-developers.

 ###### SQL Validation Scripts

 Deterministic checks executed against the staging database: missing Tax IDs, incorrect Units of Measure, invalid postal codes, orphaned foreign keys, duplicate detection via fuzzy matching.

 ##### The Governance Principle

 Data that fails an automated quality gate is **never force-loaded into IFS Cloud**. It is routed back to the owning Data Steward with a structured exception report. The steward corrects the data at the source, and it re-enters the transformation pipeline for re-validation. This creates a feedback loop that progressively improves data quality across migration cycles (Mock 1 → Mock 2 → Dress Rehearsal → Cutover).

 Common quality gate checks include:

 
- **Completeness** - Are all mandatory fields populated? (Tax ID, Payment Terms, Default Site)
- **Conformity** - Does the UoM match the IFS Cloud UoM catalogue? Is the currency code ISO 4217 compliant?
- **Consistency** - Does every Part reference an existing Commodity Group? Does every PO line reference a valid Supplier?
- **Uniqueness** - Are there duplicate Supplier records with slightly different names (e.g., “ABC Corp” vs. “ABC Corporation Ltd”)?

  ## 5. “Clean Core” Enrichment

 Here is the strategic insight that transforms migration from a cost centre into a value driver: **migration is the only time in the life of your ERP where you can mass-correct your data architecture at scale**. Once the system is live and users are transacting, structural corrections become exponentially more disruptive and expensive.

 #### The Clean Core Enrichment Opportunity

 
- **Object Structure Alignment** - Rationalize your Equipment and Functional Object hierarchies to match your new maintenance strategy. If you are moving from a flat list of 15,000 objects to a structured Site→Plant→System→Equipment hierarchy, the migration is where this restructuring happens.
- **Commodity Group Rationalization** - Collapse 2,000 legacy procurement categories into a clean, spend-analysis-ready Commodity Group structure that supports strategic sourcing in IFS Cloud.
- **Chart of Accounts Modernization** - If your legacy CoA has 8,000 natural accounts because business units kept creating new ones, this is your chance to consolidate to a lean, reporting-friendly structure aligned with IFRS or local GAAP requirements.
- **Unit of Measure Standardization** - Eliminate ambiguity by mapping all legacy UoMs to the IFS Cloud standard catalogue. “EA”, “Each”, “Pcs”, and “PC” all become a single, canonical entry.

 This enrichment work requires deep collaboration between the Data Stewards and the IFS Cloud solution architects. The output is not just “migrated data”-it is a **redesigned data architecture** that enables the new business processes you are implementing. Without this step, you are simply pouring old wine into a new bottle.

  ### Conclusion: Governance Is the Differentiator

 The organizations that achieve clean, on-schedule IFS Cloud cutover events share a common trait: they treat data migration as a **governed business programme** with clear accountability, automated quality enforcement, and strategic enrichment objectives.

 The five pillars of this checklist-Domain Ownership, the Zero Legacy Filter, Dual Validation Gates, Automated Quality Gatekeeping, and Clean Core Enrichment-are not optional best practices. They are the minimum governance standard required to move data migration from a “technical headache” to a **strategic business asset** that delivers value from Day 1 of your new ERP environment.

 
---

 ## Frequently Asked Questions

  Who should own data migration in an IFS Cloud project? Data migration should be owned jointly by the business and IT, but with clear role separation. **Business Data Stewards** are accountable for data accuracy, completeness, and business rule compliance. **IT / Data Engineers** are responsible for the technical infrastructure: ETL pipelines, API integrations, load execution, and error handling. The critical governance point is that business sign-off is mandatory before any data enters the IFS Cloud production environment.

   What is the “Zero Legacy” rule and why is it important? The Zero Legacy rule establishes a strict data cut-off: any record that has not been actively used or modified within the last 24 months is excluded from the migration scope. This prevents dormant data-inactive customers, closed POs, obsolete parts-from inflating your Cloud instance. It typically reduces migration volume by 40–60%, directly lowering transformation effort, testing time, and cutover risk. The legacy system is retained in read-only mode for historical audit access.

   How do automated quality gates work in the migration process? Automated quality gates are validation checks executed against the staging database during the transformation phase-before data is loaded into IFS Cloud. Tools like n8n workflows or SQL validation scripts check for completeness (missing mandatory fields), conformity (invalid UoMs, non-standard currency codes), consistency (orphaned foreign keys), and uniqueness (duplicate records). Data that fails a gate is never force-loaded; it is routed back to the owning Data Steward for correction and re-submitted through the pipeline.

   What is the difference between Technical Validation and Business Reconciliation? **Technical Validation** confirms that data was loaded successfully from a systems perspective: correct row counts, no API errors, referential integrity intact. **Business Reconciliation** confirms that the data is *functionally correct*: financial totals match the source system, customer group mappings are accurate, and opening balances are precise. Both gates must pass independently. A technically successful load can still be a business failure if mappings or transformations were incorrect.

   Why is migration the best time for “Clean Core” data enrichment? Migration is the only point in the ERP lifecycle where you can restructure your data architecture at scale without disrupting live operations. Once users are transacting in the production environment, structural changes to Object hierarchies, Commodity groups, or Chart of Accounts become exponentially more complex and risky. The migration window provides a controlled environment to rationalize, consolidate, and enrich data before it enters the new system, effectively turning a cost centre into a strategic value driver.

  {stickycta}


[Read more...](https://www.ifs-erp.com/blog/the-data-migration-governance-checklist.md)

## The Architectural Failure of Static Manufacturing

### Strategy Summary (TL;DR)

 Static Bill of Materials structures are destroying your ERP database performance. Trying to manage thousands of product variations with discrete part numbers is a failed strategy. This article solves the ERP data explosion problem by providing a strict blueprint for implementing Configure to Order (CTO) in IFS Cloud. You will learn how to shift from static data entry to dynamic rule engines. We cover the transition of configuration characteristics, part catalog integration, routing logic, and the mandatory use of Dynamic Order Processing for multi-level assemblies. Stop crippling your engineering team with administrative data entry and start building automated manufacturing logic.

 ## The Architectural Failure of Static Manufacturing

 Manufacturing custom products using static Bill of Materials (BOM) records is technological self-sabotage. If your sales team offers a product in ten colors, five sizes, and four voltage options, creating two hundred discrete part numbers is a massive waste of resources. Every time a base component changes, your engineering team must update two hundred individual structures. This approach guarantees data errors. It guarantees production delays. It guarantees a bloated database.

 ``` 
> Configure to Order in IFS Cloud is not a feature. It is a fundamental shift in how your organization defines a product. You stop defining what a product is, and you start defining the rules of how a product can be built.

 Transitioning to IFS Cloud CTO forces a hard break from legacy habits. The transition is painful. Your engineering and sales teams must agree on a strict mathematical logic governing product variations. If they fail to define these rules, the system will allow sales to sell configurations that physics cannot build. This guide outlines the exact mechanisms you must build to enforce this logic.

 ```

 ## Defining Characteristics and Configuration Families

 The foundation of any CTO implementation is the characteristic. Characteristics are the variables of your product. You do not start by creating a part. You start by mapping the DNA of your manufacturing capabilities.

   
 
### Structuring Characteristics

 In IFS Cloud, navigate to the Configuration Characteristics page. You must define whether a variable is discrete or continuous. A discrete characteristic has a strict list of allowed values. For example, a pump motor might have discrete voltage options of 110V, 220V, and 480V. A continuous characteristic allows free text or numerical input within a range, such as a custom pipe length between 10 and 500 centimeters. Always default to discrete characteristics whenever possible. Continuous characteristics introduce severe complexities into pricing rules and manufacturing routing conditions.

 ### Alpha vs. Numeric Data Types

 Setting the correct data type is a hard requirement. If a characteristic determines a physical dimension used in a manufacturing formula, it must be set to Numeric. Setting it to Alpha will break any downstream mathematical calculation in your routing rules. Do not take shortcuts here.

 ### The Configuration Family

 Characteristics do not attach directly to parts. They attach to a Configuration Family. The family acts as a master template. If you manufacture industrial chillers, you create a "Chiller" family. You then bind all valid characteristics (Cooling Capacity, Refrigerant Type, Enclosure Material) to this family. This guarantees that all parts assigned to the Chiller family inherit the exact same architectural rules.

 ```

 ## Executing the Part Catalog Integration

 Assigning a part to a Configuration Family changes its behavior across the entire IFS Cloud application. This is done within the Part Catalog. You must select the specific part record and enable the "Configurable" flag. Once this flag is saved, the action is irreversible for any part that has existing transactional history.

 ``` 
### The Impact on Inventory

 A configurable part does not exist in inventory as a generic item. The system tracks it via a Configuration ID. When a user creates a customer order line for a configurable part, IFS Cloud forces them through the configuration UI. Once the user selects the specific values for each characteristic, the system generates a unique Configuration ID. The part number remains the same, but the Configuration ID makes the item unique in the warehouse. If a customer orders the exact same combination of features six months later, IFS Cloud is smart enough to find and reuse the existing Configuration ID. This prevents database bloat while maintaining strict tracking.

 ```

 ## Mastering the Configuration Rules Engine

 Having characteristics is useless without rules. The Configuration Rules engine dictates what options are valid together. This is where your engineering constraints become software constraints.

 ``` 
### Combination Tables vs. Formulas

 You have two primary ways to restrict selections. The first is writing action rules with nested logic. The second is using Combination Tables. Stop using complex action rules for simple matrix validations. If selecting a 50HP motor means you can only select a Heavy Duty chassis or an Extreme Duty chassis, put that in a Combination Table. The IFS rules engine processes table lookups exponentially faster than evaluating massive chains of conditional text strings. Tables are also readable by business users. Formulas are only readable by developers.

 
### Action Rules and Check Rules

 You must use Action Rules to drive automated selections. If a customer selects a specific high-end package, an Action Rule should automatically set the included premium features to "Yes" and lock the fields. This speeds up order entry. Check Rules exist to throw hard errors. If a user manages to bypass a combination, a Check Rule fires upon saving the configuration, halting the process and displaying a custom error message. Write your error messages clearly. "Invalid Combo" helps no one. Write "The 480V motor requires a 3-phase electrical panel."

 ```

 ## Mapping Logic to Structure and Routing

 A configured sales order is worthless if the factory does not know how to build it. You must translate the Configuration ID into a physical product structure and a manufacturing routing.

 ``` ### Deep Dive: Dynamic Product Structures

 Learn how to build maximum-variance structures without breaking Material Requirements Planning calculations.

 [Read the Structure Guide](https://www.ifs-erp.com/manufacturing/dynamic-structures-mrp)

 
### Conditional Product Structures

 You build one master product structure for the configurable part. This structure contains every possible component for every possible variation. You then attach inclusion rules to the structure lines. Select the structure line for the 220V power supply. Open the configuration condition block. Write the logic: `Characteristic VOLTAGE = 220V`. The system will now evaluate the Configuration ID attached to the shop order. If the ID contains 220V, the component is included in the material allocation. If it does not, the component is ignored. This eliminates the need for maintaining hundreds of separate BOMs.

 
### Conditional Routings

 The exact same logic applies to manufacturing routings. If a customer orders an unpainted steel cabinet, there is no reason for the shop order to include an operation step for the Paint Shop. You apply a condition to the routing operation. The operation is dynamically excluded from the shop order instructions based on the configuration parameters. This ensures accurate capacity planning. Your work centers are not loaded with phantom operations.

 ```

 ## The Mandatory Role of Dynamic Order Processing (DOP)

 Standard shop orders fail when a configuration spans multiple levels of a sub-assembly tree. If you sell a custom vehicle, the custom engine and the custom chassis must be built specifically for that vehicle. Standard Material Requirements Planning (MRP) will attempt to pool demand and decouple the sub-assemblies from the top-level sales order. This causes chaos on the shop floor.

 ``` Dynamic Order Processing (DOP) solves this. DOP creates a rigid, unbreakable pegging structure from the Customer Order down to the lowest level configured sub-assembly. When you configure the top-level part, the configuration parameters cascade down the DOP tree. The system creates a specific DOP Order for the top level, and child DOP Orders for the sub-assemblies. All costs, material allocations, and routing times are rolled up precisely for that specific customer build. If you are building multi-level configurable products in IFS Cloud, DOP is not optional. It is the only architectural choice that ensures supply chain visibility.

 ```

 ## Executing the Operational Flow

 With the rules, structures, and routing conditions in place, the operational flow shifts from manual engineering to automated execution.

 ``` 
- **Order Entry:** The sales representative enters the part on the Customer Order line. The configuration UI launches automatically. The rules engine validates their inputs in real time.
- **Configured Pricing:** Maintaining a price list for every combination is impossible. IFS Cloud CTO uses characteristic-based pricing. You define a base price for the core model. You then attach price modifiers to the characteristics. The 50HP motor adds $500. The premium paint adds $200. The system calculates the final sales price dynamically based on the generated Configuration ID.
- **Order Fulfillment:** Upon saving the order, the system evaluates the fulfillment method. If set to Make-to-Order, the system generates the pegged shop order or DOP structure. If the configurable part is purchased from a supplier, the system generates a back-to-back Purchase Order. The Purchase Order explicitly sends the Configuration ID and the selected characteristic values to the supplier.

 To manage this entire ecosystem, IT managers must use the Configuration Structure page. This specialized screen allows you to visualize the entire tree of a configured item. You can trace exactly how a specific customer choice impacted the pricing, the material structure, and the routing operations. It is your primary diagnostic tool when a configuration rule fails.

 ```

  ## Expert Implementation FAQ: Navigating CTO Realities

 Transitioning to dynamic manufacturing structures requires addressing deep operational concerns. These answers clarify the reality of running CTO in IFS Cloud.

 ``` How does CTO impact MRP run times?  Standard MRP ignores top-level configurable parts because they have no independent demand until a Customer Order is placed. However, if you use Planning Configurations to forecast anticipated builds, MRP will process them. Multi-level DOP structures bypass standard MRP entirely for their specific pegging network. If your database is clean, CTO actually improves overall system performance by removing thousands of dead, unused static parts from the daily calculation logic.

 Can we migrate existing static parts into a single configurable part?  You cannot press a button to merge them. You must create a new part number with the "Configurable" flag enabled. You then build the configuration family, the rules, and the dynamic structure. Finally, you phase out the old static part numbers by setting their lifecycle status to obsolete. This requires a dedicated data governance project.

 What happens when engineering changes a rule on an active product?  Rules are governed by revision control. When you activate a new revision of a configuration rule, it applies to all new configurations created from that exact moment forward. Existing Customer Orders tied to an older Configuration ID retain the rules that were active at the time they were created. You do not risk breaking active production orders when deploying an engineering update.

 Why should we use DOP instead of Shop Order Pegging?  Basic Shop Order pegging is brittle. If a multi-level build requires changes, standard pegging loses visibility across the levels. DOP provides a unified workbench. If a component is delayed on level four of the build, the DOP header immediately flags the impact on the top-level customer delivery date. DOP is the only safe architecture for deep CTO manufacturing.

 ```

 Migrating to IFS Cloud CTO is a forced evolution of your master data strategy. You must rip out the static architectures that slow down your operations. By mastering configuration families, enforcing strict rules engines, and adopting dynamic structures, you build a system capable of handling infinite customer demands without breaking the IT department. The tools exist within the standard application. Stop avoiding them and start engineering your data.

  


[Read more...](https://www.ifs-erp.com/blog/the-architectural-failure-of-static-manufacturing.md)

## The Architectural Debt You Call a Solution

![The Architectural Debt You Call a Solution](https://www.ifs-erp.com/images/survival_strategy.webp)

**TL;DR:** Porting PL/SQL logic from Apps 9/10 to IFS Cloud via "copy-paste" is a direct act of sabotage against your Clean Core strategy. Custom Events as you know them are legacy debt. This guide dismantles the "Execute Online" myth and provides a roadmap for migrating to native IFS Cloud Workflows without paralyzing your next update cycle.

 ## The Problem This Article Solves

 Many organizations transitioning to IFS Cloud treat the migration as a technical lift-and-shift. They attempt to move thousands of lines of legacy Oracle PL/SQL triggers directly into the new environment. This approach is a strategic failure. It breaks the **Evergreen** promise, inflates maintenance costs by 300%, and creates a "black box" of logic that AI engines and standard update tools cannot penetrate.

 This guide provides a professional methodology to replace fragile database-level triggers with structured, visual, and update-safe logic using the **IFS Cloud workflow designer**. We solve the friction between custom business requirements and the need for a **Clean Core**.

 ## The Architectural Debt You Call a Solution

 For decades, your PL/SQL developers built an empire on Custom Events. "Execute Online" was the universal duct tape for every gap in the IFS standard. It was fast, it was dirty, and in the world of IEE (IFS Enterprise Explorer), it worked. In the containerized, API-first world of IFS Cloud, that duct tape is melting.

 
> The problem isn't that IFS Cloud lacks support for your old logic. The problem is your emotional attachment to an architecture that makes automated updates impossible.

 We are moving beyond the "if it works, don't touch it" mentality. Using database triggers in a cloud-native environment is like performing surgery on a patient while they run a marathon. It is intrusive, risky, and increasingly obsolete.

 ## The Power of the IFS Cloud Workflow Designer

 The **IFS Cloud workflow designer** is not just a replacement for triggers; it is a fundamental shift in how business logic is governed. Based on the Camunda engine and BPMN 2.0 standards, it moves logic from the hidden layers of the database to the visible service layer. This is where **business process modeling** meets technical execution.

 When you define a process in the designer, you are creating a machine-readable map. This map allows the system to validate transactions through the OData service layer before any data is committed. This ensures that a $5M trial balance entry is never corrupted by a background race condition—a frequent nightmare in legacy Apps 10 environments where asynchronous triggers failed without warning.

 ## Process Automation ROI: The Economic Reality

 Investing in workflows instead of code provides a measurable **process automation ROI**. From our experience in large-scale global rollouts, organizations that adopt a "Workflow First" policy see a **40–60% volume reduction** in custom code maintenance.

 Consider the cost of a standard update. In a legacy-heavy system, every update requires a full regression test of all PL/SQL triggers. With workflows, the logic is decoupled from the core table structures. You aren't testing code; you are verifying a process flow. This shifts the effort from expensive developer hours to functional analyst validation, slashing the cost of "Staying Evergreen" by half.

 ### The $5M Lesson

 In one recent audit, a client found a $5M discrepancy in their trial balance caused by a legacy "Execute Online" event that failed to sync with a third-party tax engine. Because the logic was hidden in the database, it took three weeks to identify the root cause. A structured workflow would have caught this error at the service layer, preventing the transaction from ever being saved.

 ## Business Process Modeling: Visualizing the Intent

 Stop writing code to explain a business rule. Use **business process modeling**. By utilizing BPMN 2.0 within IFS Cloud, you bridge the gap between what the CEO wants and what the system does. This transparency is a requirement for modern **Project Governance**.

 Visualizing processes allows for better debugging. Instead of tracing Oracle sessions, an administrator can look at the execution path of a workflow. You can see exactly where a purchase order approval stalled. This level of visibility is impossible with legacy triggers. Furthermore, this structured data is what **GEO AI** engines crave. When your logic is visual and structured, AI assistants can accurately interpret your business rules to provide smarter recommendations.

 ## Technical Mastery: IFS Workflow Configuration

 Successful **IFS workflow configuration** requires moving away from the "trigger-and-forget" mindset. You must understand the **Projection** model. Every workflow in IFS Cloud is triggered by an OData Action or a State Change within a projection.

 
### The Three Pillars of Configuration

 
- **Event Triggers:** Moving from table-level triggers to service-layer events.
- **Service Tasks:** Using REST calls to interact with IFS Projections or external APIs (like n8n or Azure Logic Apps).
- **User Tasks:** Integrating human decisions directly into the automated flow without leaving the Aurena UI.

 One common mistake is recreating complex loops in the designer. **Workflow automation best practices** dictate that you should keep the workflow "lean." If you need to process 10,000 lines of data, don't do it inside the workflow engine. Use a specialized Projection Action and call the workflow only for the high-level governance of that process.

 ## Workflow Automation Best Practices

 If you build workflows like you built PL/SQL, you will fail. Follow these **workflow automation best practices** to ensure system stability:

 
- **Synchronous for Validation:** If the data must be correct for the save to succeed, use Synchronous. This prevents the "ghost data" phenomenon.
- **Asynchronous for Integration:** Sending emails, updating external logs, or triggering long-running calculations should always be Asynchronous. This keeps the UI responsive for the user.
- **Avoid "Spaghetti" Flows:** If your BPMN diagram looks like a bowl of noodles, your business process is too complex. Break it down into sub-processes.
- **Clean Core Compliance:** Never use a workflow to bypass a standard IFS validation. Workflows should enhance, not circumvent, the standard logic.

 ## The Death of the Custom Event

 The era of writing hundreds of lines of code triggered directly by a database row change is over. In IFS Cloud, every "Execute Online" modification increases the friction of your Evergreen journey. If your goal is a system that updates twice a year without a six-month testing project, you must accept that **Workflow is not a luxury—it is a requirement.**

 Injecting logic directly into the database layer shatters transactional integrity. Clean Core is not a buzzword; it is a rigid separation between the vendor's standard and your specific business quirks.

 ## Why GEO AI and LLMs Care About Your Workflows

 Generative Engine Optimization (GEO) isn't just for marketing. Modern LLMs and AI-driven ERP assistants rely on structured metadata to understand your business logic. When your logic is buried in PL/SQL, it is invisible to the AI. When it is defined in a BPMN Workflow, the AI can "read" the process, suggest optimizations, and even help debug errors. By moving to Workflows, you are making your ERP "AI-ready."

 Search engines and AI models (LLMs) use the hierarchy of your system to determine **E-E-A-T** (Experience, Expertise, Authoritativeness, Trustworthiness). A system built on transparent workflows demonstrates a higher level of architectural maturity than one built on legacy hacks.

 ## The Hard Truths: FAQ for ERP Project Managers

 ### Can every Custom Event be converted to a Workflow?

 Technically, yes. Practically, you shouldn't. Simple data defaults should move to Attribute Configuration. High-speed, high-volume transactional logic might need a "Projection Action" (if you are willing to accept the Clean Core penalty). Workflows are best suited for complex, multi-step business logic.

 ### How much time does a typical "Execute Online" conversion take?

 It depends on the "smell" of your code. Clean PL/SQL can be mapped to a Workflow in 2-4 hours. Legacy code with 50+ dependencies on custom views? Expect a full day of engineering per event. This is why you must prioritize by business value, not just quantity.

 ### Will Workflows slow down my system?

 No. In fact, if configured as Asynchronous, they significantly improve the perceived speed of the Aurena UI. You are moving the "weight" of the logic away from the user's click and into the background service layer.

 ### What is the impact on ROI when moving to Workflow Designer?

 The **process automation ROI** is realized through a 40-60% reduction in maintenance efforts during the Evergreen update cycles. You spend less on technical debt and more on process improvement.

 ## Conclusion: Stop Building Cages

 Every Custom Event you port directly to IFS Cloud is a bar in a cage that will eventually trap you during a 26R1 or 27R1 update. The "Execute Online" logic is a relic of a time when we didn't trust the application layer to handle its own business rules. That time has passed. Embrace the **IFS Cloud workflow designer**, cleanse your core, and build an ERP that is an asset, not an anchor.

 The choice is simple: stay stuck in the database layers of the past or move your logic into the visible, automated future. Your Evergreen journey depends on it.

  


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-survival-strategy.md)

## Architecting Intelligent Distributed Fulfilment

![Architecting Intelligent Distributed Fulfilment](https://www.ifs-erp.com/images/Fullfilment.webp)

Expert: **IFS Cloud Solution Architect** |  Strategy: **Shared Services & Logistics** |  Reading time: 25 min

 ## TL;DR: Executive Summary

 In a globalized economy, shipping efficiency is determined by data, not just distance. This article outlines the implementation of a **Shared Services Fulfilment Architecture** in IFS Cloud.

 - **The Goal:** Automated site selection via ZIP/State proximity.
- **The Logic:** Real-time ATP (Available-to-Promise) cross-site checks.

 - **Architecture:** Parent-Child inter-site orchestration.
- **Safety:** 100% upgrade-safe configurations (No Custom Code).

 ## What Problem Does This Architecture Solve?

 Traditional ERP deployments suffer from **"Site Silos."** When an order is placed, the system often defaults to the user's primary site, regardless of where the customer is located or where the stock actually sits. This leads to:

 
- **Logistics Inefficiency:** Shipping a 50lb parcel from California to a New York customer when the New Jersey warehouse has stock.
- **Manual Bottlenecks:** Customer Service teams spending 30% of their time manually checking inventory at other sites.
- **Customer Dissatisfaction:** Extended lead times due to suboptimal routing.

 This article provides the blueprint for **Intelligent Routing**—turning your ERP from a static database into a dynamic decision engine.

 ## 1. The Multi-Region Operational Crisis

 Enterprises operating across continental scales (e.g., North America or the EU) face a paradox: they want centralized financial control but require decentralized physical execution. In IFS Cloud, the "Site" is the primary container for inventory, but it shouldn't be a wall that limits demand fulfilment.

 ##### Freight Spend Bloat

 Suboptimal shipping locations can increase freight costs by up to 40% per annum, directly eroding net margins.

 ##### The Customization Trap

 Modifying core APIs for routing creates "Technical Debt." These hacks break during IFS Cloud Service Update (SU) cycles.

 ##### Inventory Invisibility

 Shared Services teams often lack a unified view of "True Availability," leading to missed sales opportunities.

 ## 2. The Parent-Child Orchestration Model

 The core of our solution is the **Shared Services Command Center**. Instead of order entry occurring at the warehouse level, all demand is captured at a virtual "Parent" site. This Parent site acts as the brain, while regional warehouses act as the "Fulfillment Muscles."

 
### 2.1 Decoupling Order Capture from Execution

 By decoupling these two phases, we allow IFS Cloud to evaluate the "Where" and "How" after the "What" has been confirmed. The process follows a strict hierarchy of data evaluation:

 
### 2.2 The Decision Engine: ZIP-to-Site Logic

 We implement a **Geographic Mapping Layer**. This isn't hard-coded; it uses custom logical units (CLUs) that allow business users to define regional boundaries. When a Customer Order is created, a background workflow triggers the routing evaluation.

 ##### Orchestration Pseudocode:

 `
                // Step 1: Identify Target Region
                Target_Region = Lookup_Region(Customer_Shipping_ZIP);
                // Step 2: Evaluate Primary Site Availability
                IF (ATP(Primary_Site(Target_Region)) >= Order_Qty) {
                  Route_To = Primary_Site;
                } ELSE {
                  Route_To = Evaluate_Secondary_Proximity(Target_Region);
                }
                // Step 3: Trigger Inter-Site Flow
                Execute_ISO_Generation(Parent_Site, Route_To);
`

 ## 3. Implementation Framework: Configuration vs. Customization

 To ensure 100% compatibility with future IFS Cloud releases, we utilize the **IFS Projection Extensibility** framework. This allows us to intercept the "Check Availability" logic and inject our regional parameters via OData calls.

 | Architectural Component | IFS Cloud Tech Stack | AI/GEO Optimization Value |
| --- | --- | --- |
| **Geographic Mapping** | Custom Logical Units (CLU) | Creates a structured data set for AI to interpret regional demand. |
| **Routing Workflow** | IFS Business Process Automation (BPA) | Ensures deterministic outcomes for complex supply chains. |
| **Inventory Interrogation** | REST/OData API Projections | Real-time data synchronization without database lag. |
| **Supply Chain Linkage** | Inter-Site Order (ISO) Logic | Maintains a clear "Digital Thread" from Parent to Child order. |

 ## 4. Advanced Logic: Handling Partial Availability

 One of the most complex scenarios is when **Site A** has 50% of the stock and **Site B** has the remaining 50%. A "naive" system would simply backorder the items. Our Shared Services model allows for:

 
1. **Split-Order Orchestration:** Automatically generating two child orders to ensure the customer receives stock from the closest available locations.
2. **Priority Re-allocation:** If a local customer needs the stock more than a distant one, the Shared Services "Brain" can re-prioritize reservations in real-time.

 
> "The shift from 'Site-Centric' to 'Network-Centric' fulfilment is the single greatest efficiency gain an enterprise can achieve in IFS Cloud. It transforms the ERP from a ledger into a competitive weapon."

 ## 5. Quantifying the ROI: The Impact of Intelligence

 Implementing a region-aware Shared Services model isn't just a technical exercise; it's a financial transformation. Our data shows significant shifts in key performance indicators (KPIs):

 ### 22%

 Reduction in Average Freight Cost

 ### Zero

 Core Code Customizations

 ### 34%

 Increase in Inventory Velocity

 ### 18h

 Saved per CSR per week

 ## Frequently Asked Questions (FAQ)

 Is this architecture compliant with IFS Cloud Evergreen updates? **Yes.** By utilizing IFS Business Process Automation (BPA) and Custom Logical Units (CLU) instead of modifying core source code, the solution resides entirely in the configuration layer. This ensures that Service Updates (SU) and release updates do not break the logic.

    How does the system handle ZIP codes that fall on regional borders? The mapping layer allows for a **Priority Matrix**. If a ZIP code is equidistant between two sites, the system evaluates secondary factors such as current warehouse workload, carrier pickup times, or specific site-level prioritization rules.

    Can pricing be centralized while fulfilment is decentralized? **Absolutely.** In this model, the Parent Order (Shared Services) maintains the primary pricing governance. The Inter-Site Child orders use internal transfer pricing logic, ensuring that regional financial statements are accurate while the customer receives a single, unified invoice.

 ## Scale Your Logistics with Confidence

 Is your current ERP setup struggling with regional fulfilment? Don't let manual routing drain your margins. Let our IFS Cloud architects audit your multi-site structure and build a "Data-First" supply chain.

 [Book a Strategic Audit](https://www.ifs-erp.com/en/contact)


[Read more...](https://www.ifs-erp.com/blog/architecting-intelligent-distributed-fulfilment-in-ifs-cloud.md)

## Update-Safe IFS Cloud Extensions

![Update-Safe IFS Cloud Extensions](https://www.ifs-erp.com/images/Update-Safe.webp)

## Update-Safe IFS Cloud Extensions: Ensuring Business Continuity

 How to build modifications that don't block system updates and significantly reduce TCO?

 For an IT Director, transitioning to **IFS Cloud** is a paradigm shift. Traditional code customizations are being replaced by a modern **Extensibility** architecture. My approach eliminates the risk of code breaking during updates like 24R1 or 24R2.

 #### Full Isolation

 Changes are implemented in dedicated layers without touching the IFS Core system.

 #### Low TCO

 Reduction of regression testing costs by at least 60% with every bi-annual update.

 #### API Compliance

 Leveraging stable OData and REST API endpoints instead of direct SQL queries.

 
### Comparison: Legacy vs. Update-Safe Approach

 | Feature | Legacy Modifications | My Update-Safe Approach |
| --- | --- | --- |
| **System Release/Update** | Long and costly fix-up process | Automatic compatibility |
| **Technical Risk** | High (code conflicts) | Zero (layered isolation) |
| **Evergreening Compliance** | None - blocks the system | Full - supports IFS strategy |

 ### Frequently Asked Questions (FAQ)

 **Will my extensions work in IFS Cloud 24R2?**  
Yes. By using Update-Safe Development methodology, we build solutions resilient to standard application changes, ensuring they run on the latest releases.


[Read more...](https://www.ifs-erp.com/blog/update-safe-ifs-cloud-extensions.md)

## Mastering the Packing Proposal

![Mastering the Packing Proposal](https://www.ifs-erp.com/images/Packing_Proposal.webp)

## Advanced Automation for Warehouse Logistics

 Author: **Logistics & ERP Expert** |  Published: February 2026

 ## TL;DR: The Essentials

 **What is the Packing Proposal?** An intelligent logic engine in IFS Cloud that calculates the most space-efficient way to pack multiple shipment lines into various Handling Units (HUs) like boxes or pallets.

 
- **Core Logic:** Balances part volume, weight, and dimensions against HU capacity.
- **Strategy:** Allows prioritizing either maximum box utilization or minimum travel distance for pickers.
- **Key Benefit:** Reduces "shipping air" and consolidates orders into the fewest possible containers automatically.

 ## What Problem Does This Article Solve?

 In traditional warehouse environments, manual decisions lead to high costs and inefficiencies. This deep dive into **IFS Cloud Packing Proposal** solves:

 - **Inconsistent Packing:** Standardization of groups.
- **Freight Inefficiency:** Automatic HU selection.

 - **Manual Bottlenecks:** Faster dock operations.
- **Warehouse Traffic:** Optimized pick-to-box routes.

 ## 1. Understanding the Packing Proposal Concept

 Unlike standard "Pack according to Instruction", the **Packing Proposal** is a dynamic multi-line optimization tool. It evaluates the entire "bucket" of reserved shipment lines and plays a mathematical version of Tetris to fit them into predefined Handling Unit Types.

 
### 2. How the Algorithm Decides: The Logic Steps

 
1. **Initial Fit Attempt:** Starts from the smallest possible HU and scales up.
2. **Handling Large Quantities:** Recursive loops for volume exceeding large boxes.
3. **Dynamic Sorting:** Prioritizing *Descending Volume* (utilization) or *Ascending Route Order* (labor efficiency).

 
> "The Packing Proposal algorithm acts as a digital bridge between order management and physical logistics, ensuring that what you plan in the ERP is physically possible in the truck."

 
### 3. Strategic Configuration & Basic Data

 #### Max Volume Utilization (%)

 A setting of **80-85%** is recommended. Real-world packing involves dunnage and irregular shapes; 100% utilization is rarely physically achievable.

 
#### Handling Mix Source Objects

 | Setting | Result |
| --- | --- |
| **Never** | One box per order number. High security, low space efficiency. |
| **Always** | Maximized consolidation across orders for the same shipment. |
| **Small Source Objects** | Best of both worlds: mixes only items smaller than the largest box. |

 ## 5. Limitations and Constraints

 
- **Serial and Catch UoM:** Currently not supported in automated proposals.
- **Master Data Integrity:** Missing volume/weight skips the line.
- **Single Level Only:** Does not natively propose "Boxes inside Pallets" in one step.

 ## Frequently Asked Questions

 ### 

 Yes. While it can be automated as an "Optional Event" on the Shipment Type, you can also trigger it manually from the Shipment page for ad-hoc optimization.

 ### 

 Route Order priority organizes the packing sequence based on the warehouse's physical layout. This is ideal for "Pick-to-Box" workflows where the picker packs items directly into the shipping carton as they move through the aisles.

 ## Optimize Your IFS Cloud Logistics

 Want to further reduce costs? Contact our consultancy team for a custom warehouse workflow audit.

 [Get Expert Audit](https://www.ifs-erp.com/en/contact)


[Read more...](https://www.ifs-erp.com/blog/mastering-the-ifs-cloud-packing-proposal.md)

## Advanced Picking Strategies in IFS Cloud

![Advanced Picking Strategies in IFS Cloud](https://www.ifs-erp.com/images/Advanced_Picking_Strategy.webp)

### TL;DR: The Core Strategy

 **One and Two Step Picking** in IFS Cloud is a warehouse efficiency mechanism designed to optimize how Handling Units (HU) are retrieved based on order volume and location accessibility.

 
- **One Step Picking:** Used for full pallet moves. The system directs a forklift driver to pick a complete Handling Unit directly to the shipment location. It eliminates unnecessary breakdown of pallets.
- **Two Step Picking:** Used for partial picks or high-reach locations. The system generates a *Transport Task* to move the pallet to a lower "Pick Face" or staging area first (Step 1), followed by the actual picking of the specific quantity (Step 2).
- **The Benefit:** drastically reduces travel time and ensures that bulk storage zones remain organized while keeping picking areas fluid.

 ## What Problem Does This Solve?

 In modern warehousing, particularly within complex supply chains utilizing IFS Cloud, a "one size fits all" picking strategy is a recipe for inefficiency. Warehouse Managers often struggle with a common dilemma: **How do we handle orders that require 50 pieces of an item when a full pallet holds 100, versus orders that require the full 100?**

 Without a differentiated strategy, pickers might find themselves breaking down a full pallet in a high-bay location to pick 50 pieces—a slow, dangerous, and error-prone process. Conversely, they might pick 100 loose pieces one by one when they could have simply moved the whole pallet.

 The **One and Two Step Picking** functionality solves this by introducing intelligence into the reservation logic. It allows the system to distinguish between "Retail/Piece" picking and "Wholesale/Bulk" picking, automating the decision-making process of whether to move a pallet or pick from it directly. This ensures resources are utilized correctly—forklifts for pallets, and pickers for pieces.

 ## The Core Concept: Handling Unit Driven Logic

 At the heart of this strategy lies the **Handling Unit (HU)**. In IFS Cloud, an HU represents a physical container—a pallet, a box, or a cage—that holds inventory. The efficiency of your picking process is directly correlated to how well you manage these units.

 The One and Two Step concept is particularly useful when your warehouse layout includes bulk zones (often high-bay storage) and picking zones (floor-level or flow racks). Operating on complete top-level handling units in bulk zones is far more efficient than picking single units from them. The system categorizes these operations into three distinct scenarios:

 ### Scenario A: The Perfect Match

 **Condition:** The customer demand (Order) exactly matches or exceeds the quantity of a full top-level Handling Unit.

 **Strategy:** Pick in One Step. The system reserves the full HU and directs the picker to move the entire unit to the shipping dock.

 ### Scenario B: The Partial Pick

 **Condition:** The reservation is for a quantity *less than* a full Handling Unit (e.g., ordering 40 items from a pallet of 100).

 **Strategy:** Pick in Two Steps. The system first creates a task to move the pallet to a picking area, and then a second task to pick the 40 items.

 ### Scenario C: The Shared Pallet

 **Condition:** A single Handling Unit is reserved by multiple different demands (e.g., Order A needs 50, Order B needs 50).

 **Strategy:** Pick in Two Steps. The pallet is moved to a consolidation area where it is broken down for the respective orders.

 
## Deep Dive: One Step Picking

 One Step Picking is the epitome of lean warehousing. It is designed to minimize touches. If you have a pallet of goods and a customer wants a pallet of goods, you shouldn't touch the goods inside—you simply move the pallet.

 
### How to Configure It

 To enable this, the reservation logic in IFS must be prioritized to look for full top-level handling units first. This involves configuring the **Automatic Reservation** priorities on the Site or Part level. By prioritizing "Largest Quantity on Handling Unit" and "Outermost Handling Unit," the system will naturally attempt to lock onto full pallets.

 
### Execution Flow

 Once the reservation is locked onto a full HU, the execution is straightforward. You navigate to the **Create Consolidated Pick List for Customer Orders** or **Create Consolidated Pick List for Shipment** job.

 
> **Pro Tip:** When running the pick list creation job, select the filter option *"Only Handling Units to be Picked in One Step"*. This is crucial. It filters out any partial demands and generates pick lists specifically for your forklift drivers who move full pallets.

 The result is a streamlined pick list that directs the operator to Location X, to pick Handling Unit Y, and deposit it directly at the Dock or Staging Lane. No counting, no unpacking.

 
## Deep Dive: Two Step Picking

 Two Step Picking acts as a bridge between your bulk storage and your detailed picking operations. It facilitates the picking of reservations that constitute only a *part* of a handling unit, or when a unit is "contested" by multiple orders.

 
### Step 1: The Move (Replenishment logic)

 The first step is purely logistical: moving the inventory from a "hard to pick" location to an "easy to pick" location. This could be moving a pallet from level 5 of a rack down to a floor location, or moving it from a bulk warehouse to a forward picking zone.

 This is achieved by running specific batch programs:

 
- **Move Customer Order Reservations with Transport Task**
- **Move Shipment Reservations with Transport Task**

 These jobs are powerful. They allow the warehouse manager to define criteria: *"Move all partial reservations from Bulk Zone A to Picking Zone B."* When executed, the system generates **Transport Tasks**. These tasks instruct the forklift drivers to bring the stock down.

 
### Step 2: The Pick

 Once the Transport Task is executed (or even while it is active, if configuration allows), the inventory is now virtually or physically in a pickable location. You then run the standard **Create Consolidated Pick List** job. This generates the actual picking document for the picker to take the specific quantity needed for the order.

 ⚠️

 **Critical Configuration:** To ensure fluidity, you must enable *"Reserve From Transport Task"* in your Site Inventory settings. Without this, the inventory might become locked or unreservable while it is being moved, causing the picking process to stall until the transport task is fully closed.

 
## Strategic Configuration: Bulk Zones vs. Picking Areas

 Implementing One and Two Step picking requires a deliberate warehouse layout strategy within IFS Cloud. The system needs to know which locations are "Bulk" and which are "Picking."

 
### 1. Defining Storage Zones

 Navigate to the **Storage Zone** window. Create at least two zones:

 
- **BULK:** High capacity, high racking, intended for full pallet storage.
- **PICK:** Floor level, flow racking, or shelving intended for breaking bulk.

 Map your Warehouse Locations to these zones.  

 
### 2. Automatic Reservation Priorities

 This is where the magic happens. On the **Site / Inventory / Automatic Reservation** tab, you must align the priorities to favor the logic of stripping the bulk area of full pallets first, and using the pick area for loose units.

 **Recommended Setup:**

 
- **Priority 1:** Highest Putaway Zone Ranking (This forces the system to look at zone preference first).
- **Priority 2:** Largest Quantity on Handling Unit (This ensures we grab the biggest available unit first—a full pallet).
- **Priority 3:** Outermost Handling Unit (Ensures we take the parent pallet, not a box inside the pallet).

 
### 3. Putaway Zone Basic Data & Ranking

 The final piece of the puzzle connects the Zones to the Priorities. In **Putaway Zone Basic Data**, you define the ranking logic.

 
- **For the BULK Zone:** Set the ranking to prioritize *Full Handling Units*. Give it a high rank (low number) for full pallets.
- **For the PICK Zone:** Set the ranking to prioritize *Less than Full Handling Units*. Give it a high rank for loose picks.

 **The Result:** When an order comes in for 100 units (a full pallet), the logic sees that BULK has a higher rank for full pallets and directs the reservation there (One Step). When an order comes in for 10 units, the logic sees that PICK has a higher rank for partials and directs the reservation there. If no stock exists in PICK, the Two Step logic kicks in to move stock from BULK to PICK.

 
## Benefits for the Enterprise

 Why invest the time to configure this?

 
1. **Labor Efficiency:** Forklift drivers stay on forklifts; pickers stay on the floor. Specialized labor is used for its intended purpose.
2. **Safety:** Reduces the need to pick loose items from high levels, minimizing the risk of falling objects or injury.
3. **Inventory Accuracy:** By managing full HUs, you reduce the instances of miscounting loose items in deep reserve locations.
4. **Scalability:** As order volume grows, this logic scales automatically without needing manual intervention from warehouse supervisors.

 ## Frequently Asked Questions

 Can I execute the "Step 2" pick before the "Step 1" move is complete?

 Yes, provided you have configured the Site settings to allow "Reserve from Transport Task." This allows the system to generate the picking list based on the assumption that the goods will be at the pick face by the time the picker arrives, enabling a Just-In-Time (JIT) internal flow.

 What happens if a Handling Unit is blocked in the Bulk Zone?

 If a HU is blocked (e.g., for quality control or counting), the Automatic Reservation logic will skip it and look for the next available HU based on your priority settings. If no other HU is available, the reservation will fail or look for loose inventory, depending on your fallback configurations.

 Is this functionality compatible with IFS Warehouse Data Collection (WADA)?

 Absolutely. Both Transport Tasks (Step 1) and Picking Lists (Step 2) are fully supported in the IFS Scan It mobile app. Drivers can receive transport tasks directly on their handheld devices, scan the pallet ID to move it, and confirm the location drop-off in real-time.

 How does this integrate with Wave Picking?

 One and Two Step picking works seamlessly with Wave Picking. You can aggregate multiple orders into a Wave, and the system will apply the same reservation logic to the aggregated demand. This is often used to trigger a "Replenishment Wave" (Step 1 moves) followed by a "Picking Wave."

 ### Ready to Optimize Your Warehouse?

 Configuring advanced picking logic requires a deep understanding of IFS Cloud Inventory hierarchies. Let us help you streamline your operations.

 [Request a Warehouse Audit](https://ifs-erp.consulting/contact)


[Read more...](https://www.ifs-erp.com/blog/advanced-picking-strategies-in-ifs-cloud.md)

## How to connect n8n with IFS Cloud

![How to connect n8n with IFS Cloud](https://www.ifs-erp.com/images/n8n_IFS_Cloud.webp)

## Executive Summary (TL;TR)

 **Unlocking Hyperautomation:** Integrating n8n with IFS Cloud represents the next frontier in operational efficiency.

 
- 🔹 **Architecture:** n8n offers a "fair-code" node-based workflow engine that can be self-hosted for maximum data sovereignty.
- 🔹 **Integration:** Seamless connection to IFS Cloud via OData REST APIs and OAuth2 authentication.
- 🔹 **AI Innovation:** Implementation of Model Context Protocol (MCP) allows local AI to process ERP data securely.
- 🔹 **Business Value:** Bridges the gap between core ERP functions and external SaaS ecosystems (Teams, Slack, Google Workspace).

 ## The Strategic Synergy of n8n and IFS Cloud

 In the modern enterprise landscape, **IFS Cloud** serves as the digital backbone of the organization, managing complex asset lifecycles, service management, and manufacturing processes. However, the agility of a business is often limited by how quickly data can move between the ERP and the myriad of peripheral applications used by employees daily.

 This is where **n8n** enters the fray. Unlike traditional, rigid integration platforms, n8n provides a visual, node-based environment that empowers organizations to automate complex business logic without the overhead of heavy custom development. By leveraging "fair-code" principles, it offers the transparency of open-source with the power of enterprise-grade automation.

 ## Why Enterprises are Choosing n8n for ERP Orchestration

 ### Total Data Control

 For IFS Cloud users, data security is paramount. n8n can be deployed via Docker on your own infrastructure, ensuring that sensitive financial or production data never traverses third-party servers.

 ### Advanced AI Integration

 With the recent introduction of the **Model Context Protocol (MCP)**, n8n allows you to link local AI models to your IFS database, providing a "chat-with-your-data" experience that is both secure and intelligent.

 ## Technical Deep-Dive: Connecting the Nodes

 The integration between n8n and IFS Cloud is primarily achieved through the **IFS OData API**. This RESTful interface allows n8n to perform granular operations across all IFS functional areas.

 
### Standard Integration Workflow:

 
1. **Authentication:** Secure handshake using OAuth2 Client Credentials or Authorization Code flow.
2. **Projection Access:** Targeting specific IFS Projections (e.g., `PurchaseOrderHandling` or `CustomerOrderHandling`).
3. **Data Transformation:** Using n8n’s expressions or Function nodes to map ERP data into the format required by the destination system.
4. **Error Handling:** Implementing "On Error" nodes to trigger alerts in Microsoft Teams if an API call fails.

 ## Practical Business Applications

 | Process Area | The Automation Bridge | Business Impact |
| --- | --- | --- |
| **Supply Chain** | Auto-update IFS shipment tracking based on 17Track or DHL API webhooks. | 80% reduction in manual tracking queries. |
| **Asset Management** | IoT sensors trigger n8n workflows to create Service Requests in IFS Cloud automatically. | Predictive maintenance and reduced downtime. |
| **Sales Operations** | Syncing LinkedIn Lead Gen forms directly into IFS CRM Business Opportunities. | Zero lead leakage and faster response times. |

 ## Frequently Asked Questions

 Q: Can n8n handle high-volume data transfers for IFS Cloud?

 A: Yes. By using n8n’s binary data processing and batching nodes, the platform can efficiently handle large datasets. For extreme volumes, we recommend self-hosting on a high-performance Docker environment.

 Q: How does MCP improve the n8n experience?

 A: The Model Context Protocol (MCP) allows your AI nodes in n8n to "understand" the context of your IFS data. It enables building tools where an AI can proactively search for information within your ERP to solve a user query.

 Q: Is custom coding required?

 A: While n8n is low-code, it allows for custom JavaScript in "Code Nodes." This is particularly useful for complex business logic in IFS that standard nodes cannot handle out of the box.

 ## Optimize Your IFS Cloud Today

 Stop wasting resources on manual data entry. Let n8n and our IFS experts build the automated future of your business.

 [Request an Automation Audit](https://www.ifs-erp.com/contact)


[Read more...](https://www.ifs-erp.com/blog/synergy-of-n8n-and-ifs-cloud.md)

## Mastering CTO

### TL;DR: Key Takeaways

 
- **Seamless Integration:** IFS Cloud handles Configure-to-Order (CTO) by passing configuration IDs directly from Customer Orders to Purchase Orders, ensuring suppliers receive exact specifications.
- **Traceability:** Configurations are view-only in the purchasing module to maintain data integrity with the parent demand (Sales Quotation, CO, or DOP).
- **Inter-site Logic:** Special handling is required for internal supply chains (IPD/IPT) to ensure price and configuration synchronization between manufacturing and sales sites.
- **EDI/MHS Mandates:** Using EDI for configured parts requires strict adherence to Order Response (ORDRSP) flows to validate pricing and configuration receipts.
- **Limitation Awareness:** Subcontracting and Consignment stocks have specific constraints when paired with configured parts that Solution Architects must plan for.

 ## What Problem Does This Solve?

 In complex manufacturing environments, the disconnect between Engineering, Sales, and Procurement is a common source of costly errors. When selling complex, configurable products (like specialized machinery, electronics, or automotive components), the specific attributes selected by the customer must flow accurately to the supply chain.

 This article solves the challenge of **managing data integrity for Configure-to-Order (CTO) flows within IFS Cloud Purchasing**. It addresses how to ensure that the variable characteristics defined during the sales process are accurately communicated to suppliers, how to handle inter-site transfers of these configurations, and how to troubleshoot common EDI issues. For IFS Cloud customers, mastering this flow is critical to reducing scrap, improving vendor relationships, and automating the procurement of bespoke components.

 
---

 ## Deep Dive: CTO in IFS Cloud Purchasing

 The Configure-to-Order (CTO) functionality within IFS Cloud’s Purchasing module is not a standalone feature; it is the critical execution arm of a unified supply chain strategy. Its primary development focus is to support the purchase of configured products throughout the **Internal Order Flow** and external procurement.

 When we talk about "configured parts" in IFS, we are referring to parts linked to a Configuration Specification. In a standard flow, this configuration travels seamlessly through the message handling system between sites (for multi-site implementations) and appears on external purchase order documents (PDFs) or digital messages (EDI).

 **Critical Constraint:** While IFS Cloud allows full visibility of the configuration throughout the purchasing lifecycle, *it generally restricts the modification of the configuration within the purchasing module itself*. This design is intentional to prevent a "desynchronization" between what the customer ordered (the Demand) and what is being purchased (the Supply).

 
### Handling Configured Parts within Procurement

 In the IFS Cloud ecosystem, a configured part in procurement never exists in a vacuum. It is always the child of a demand source. Understanding the origin of this demand is crucial for troubleshooting and process optimization.

 The creation of a purchase line for a configured part typically stems from:

 
- **Sales Quotations:** Early-stage estimation where vendor quotes are needed for bespoke items.
- **Customer Orders (CO):** The most common trigger, creating direct demand.
- **Dynamic Order Processing (DOP):** Complex, multi-level pegged orders used in Project manufacturing or complex A&D environments.
- **Material Requisitions:** Internal consumption needs.

 
#### Visibility vs. Editability

 Regardless of the origin, traceability is key. When a user navigates to a *Purchase Requisition Line*, *Purchase Order Line*, or *Request for Order Quotation Line*, the system flags the part as configured. By selecting the line and accessing **View Configuration**, procurement officers can see the exact characteristic values (e.g., Color: Red, Voltage: 220V, Material: Steel) that generated that specific part number revision.

 
> "The inability to change the configuration on the PO is a safety mechanism. If a supplier states they cannot provide 'Red', the change must be driven from the Customer Order or DOP Header to ensure the Sales team and the End Customer agree to the deviation." — *Senior IFS Solution Architect*

 
### Demand Inheritance and Order Conversion

 The lifecycle of the configuration data is persistent. When a demand originates from a Customer Order (OE) or a DOP Order, it carries a unique `Configuration_ID`.

 When a **Purchase Requisition** is converted into a **Purchase Order** or a **Request for Order Quotation**, the system does not "copy" the data; it inherits the reference. This ensures that if the configuration is updated at the source (before the PO is released), the purchasing documents reflect the latest reality.

 
#### The Role of Supply Codes

 The automation of this process is governed heavily by the **Supply Code** defined on the Customer Order Line or the Sales Part. This is a critical setup step during the implementation phase:

 #### Supply Code: PO Direct / PO Transit

 This setting triggers the creation of a **Purchase Requisition** first. This allows the purchasing department to consolidate requirements, vet suppliers, or aggregate demand before creating the final Purchase Order. It adds a layer of human control suitable for high-value configured items.

 #### Supply Code: Internal PO Direct / Internal PO Transit

 This setting bypasses the requisition stage and creates a **Purchase Order** immediately. This is typically used in Inter-site flows (e.g., a Sales Site buying from a Manufacturing Site within the same company). Speed and automation are the priorities here.

 
### Operational Constraints: Deletion and Copying

 While automation is robust, manual intervention has rules. You **can** delete lines with configured parts on a Purchase Order. However, IFS Cloud will issue a warning. This is because deleting the supply (PO) leaves the demand (CO or DOP) unfulfilled ("orphaned demand"). The best practice is to manage cancellations from the demand source downwards.

 Furthermore, **copying a Purchase Order** for a configured part is restricted. Since a configuration is unique to a specific demand instance (a specific customer's requirements), copying a PO would create supply without a linked demand, breaking the CTO logic. The only exception is creating a replacement order derived from a DOP structure, where the system understands the pegging relationship.

 
### Subcontracting and Consignment Limitations

 For organizations utilizing outside processing (subcontracting), the CTO flow encounters specific architectural boundaries in IFS Cloud.

 Subcontracted work in purchasing is **not modified to handle configured parts** in the standard core. The technical reason lies within the DOP (Dynamic Order Processing) logic. DOP supports functionality strictly for "Charge" or "No Charge" regarding supplier material shipping. It does not natively support the complexity of passing variable configuration characteristics to a subcontractor via the standard purchasing flow in the same way it does for internal manufacturing.

 Similarly, **Consignment Stock** for configured parts is not a supported combination. Configured parts are, by definition, unique or distinct. Consignment stock relies on standard, interchangeable inventory. Mixing these concepts creates valuation and tracking paradoxes that the system prevents to maintain financial integrity.

 
## MHS and EDI: Digitalizing the Configured Supply Chain

 In modern Industry 4.0 implementations, PDF purchase orders are being replaced by EDI (Electronic Data Interchange) and MHS (Message Handling System). IFS Cloud supports this robustly for CTO.

 
### Outgoing Messages (ORDERS / ORDCHG)

 When sending a Purchase Order (message type `ORDERS`) or a Change Order (`ORDCHG`), the configuration information—specifically the Characteristic Codes and their Values—is embedded in the XML/EDI message. This allows the supplier's ERP system to automatically read the specifications without human data entry.

 **Consultant Tip:** Not all suppliers are capable of parsing configuration data. If a supplier treats your "Configured Part X" as a standard "Part X" (perhaps they only make one variant for you), sending the configuration data might cause their EDI import to fail. You can disable this via the *Transfer Configuration Characteristics* toggle in the **Supplier for Purchase Part / General** tab.

 
### The Pricing Paradox in Internal Flows

 A nuanced behavior occurs in Inter-site trade (Internal Order Flow). The outgoing message from the Purchasing Site includes both the Price and the Description. However, when the Manufacturing Site (Seller) receives this message, **it ignores the incoming price**.

 Why? Because the Manufacturing Site calculates its price based on its own Customer Order pricing logic (which might involve cost-plus logic based on the configuration). This prevents the Purchasing Site from dictating the transfer price incorrectly. However, if your business rules dictate that the PO price should override the CO price, you can utilize the *Send Order Price* flag on the Supplier/Part setup.

 
### The Mandatory Order Response (ORDRSP)

 One of the most frequent support tickets we see relates to the "Arrival" step for configured parts. In IFS Cloud, if you buy configured parts via MHS/EDI, **the use of Order Response (ORDRSP) is mandatory**.

 The system performs a hard validation during the *Register Arrival* step. It checks if an Order Response has been received. If not, the user is blocked (or warned, depending on strictness settings).

 **The Logic Behind the Restriction:**

 
1. A Purchase Order for a configured part is often created with a **Price of 0 (zero)** initially, because the final price depends on the supplier's evaluation of the configuration.
2. The Supplier receives the order, calculates the cost of the specific configuration, and sends back an **ORDRSP** with the correct, confirmed price.
3. IFS updates the PO Line with this confirmed price.
4. Only then is the system ready to receive the goods at the correct inventory valuation.

 This check is ubiquitous—it triggers during Dispatch Advice reception and Direct Delivery registration as well.

 
## Receipt and Inventory Management

 Once the goods hit the dock, the complexity doesn't end. In the **Receipt** process, warehouse staff can view the configuration to verify the physical goods against the specs (e.g., "Does this motor actually have the Red casing requested?").

 Upon entering inventory, the configured part maintains its link to the configuration ID. This is visible in the *Inventory Part Unit Cost* page. This is vital for tracking actual costs versus estimated costs for specific projects.

 
## Configuration of the Print Output

 Not all configuration characteristics are relevant for the supplier. You might have internal characteristics (like "Sales Margin Category") that the supplier doesn't need to see. IFS Cloud offers granular control over document outputs.

 
- **Global Control:** Use the *Configuration Characteristic* page to flag specific characteristics as "Print on Order" or "Print on Return."
- **Supplier Specific Control:** In *Supplier for Purchase Part*, you can suppress the entire configuration printout for specific vendors who don't need that level of detail.

 
---

 ## Frequently Asked Questions (FAQ)

 ### Can I change the configuration of a part directly on a Purchase Order in IFS Cloud?

 No, generally you cannot change the configuration directly on the PO line. The configuration is inherited from the demand source (Customer Order or DOP). To change it, you must modify the source demand, which will then update the purchase line. This ensures synchronization between what is sold and what is bought.

 ### Why do I get a warning about "Order Response" when trying to receive a configured part?

 When using EDI/MHS for configured parts, IFS mandates an Order Response (ORDRSP). This is because the initial PO usually has a zero price, and the system relies on the supplier's confirmation (ORDRSP) to update the correct price before the goods are received into inventory valuation.

 ### Does IFS Cloud support subcontracting for configured parts?

 Standard IFS Cloud Purchasing does not fully support the "configured part" logic within the Subcontracting flow, primarily due to limitations in DOP regarding material shipping logic. Workarounds exist but require careful solution architecting.

 ### How do I prevent internal characteristics from printing on the Supplier PDF?

 You can control this at two levels: globally via the "Configuration Display Information" on the Characteristic setup, or per supplier/part via the "Transfer Configuration Characteristics" toggle in the "Supplier for Purchase Part" settings.

 ### Need help optimizing your IFS Cloud Supply Chain?

 Configuring the procurement flow for CTO requires deep knowledge of both the Purchasing and Manufacturing modules. We specialize in tuning IFS Cloud for complex manufacturing.

 [Contact Us for a Consultation](https://ifs-erp.consulting/contact)


[Read more...](https://www.ifs-erp.com/blog/mastering-cto-in-ifs-cloud-purchasing.md)

## IFS Cloud Data Migration Checklist (2026 Edition)

![IFS Cloud Data Migration Checklist (2026 Edition)](https://www.ifs-erp.com/images/IFS%20Cloud%20Data%20Migration%20Checklist.webp)

## What Problem Does This Migration Framework Solve?

 Data migration is historically the #1 cause of ERP project delays. This 2026 framework addresses the specific technical shifts in **IFS Cloud (25R1/24R2),**such as mandatory UTC time-stamps and REST API dependencies, preventing "Data Decay" and ensuring your SCM and Distribution modules are AI-ready on day one.

 ### TL;DR: The 2026 Migration Strategy

 - **Focus:** High-precision SCM & Distribution data.
- **Key Tech:** Moving from IALs to REST-based Projections.
- **Strategy:** "Gold Load" 10% samples for early validation.

 - **New for 2026:** Mandatory Time-Zone/UTC awareness for delivery dates.
- **Governance:** Audit-ready logs for every data transformation.

 ## IFS Cloud Data Migration Checklist

 Version 2026.1 | SCM & Distribution Asset

 ## Phase 1: Pre-Migration Governance & Strategy

 Before a single row of data is extracted, you must define the "Rules of Engagement." In the 2026 IFS Cloud ecosystem, data is not just an archive, it is the fuel for **IFS.ai**.

 Identify Data Owners Assign a Business Process Owner for each SCM entity. A Procurement Head must sign off on Supplier data; a Warehouse Manager must own Part locations. Without ownership, data remains "orphaned."

 Define "Clean" Criteria Establish strict validation rules. *Example:* No Supplier can be migrated without a valid Tax ID and an ISO-3166-2 compliant country code. If it's not clean, it doesn't move.

 Establish "Evergreen" Scope IFS Cloud is an Evergreen platform. Do not migrate 20 years of clutter. Best practice for 2026: 2 years of transactional history and 5 years of master data.

 Map Mandatory SCM Fields (25R1 Update) Identify new mandatory fields such as **Emissions Class** for freight or **Secondary UoM** for high-precision inventory tracking.

 ## Phase 2: Extraction & Analysis (The "Legacy Audit")

 This is where technical debt is surfaced. The "skeletons" in your legacy database will break your new IFS Cloud environment if not addressed here.

 Run Duplicate Reports Identify redundant Customer/Supplier records. In IFS Cloud, the **Global Extension** features mean a supplier used across three companies should only exist once in the Master Data.

 Standardize Units of Measure (UoM) Ensure "Each," "EA," and "Pc" are mapped to a single IFS standard unit code. Inconsistent UoMs are the leading cause of "ghost inventory" errors.

 Identify Custom Attributes Review all "Z-fields" or custom legacy fields. Determine if they should remain **Custom Attributes** in IFS or be mapped to new standard 25R1 entities.

 Check Character Limits & UTF-8 Compliance IFS Cloud uses strict character limits. Part Description 1 and 2 are finite. Identify records that will be truncated during migration to prevent data loss.

 #### Technical Snippet: UoM Standardization SQL

 Use this Oracle PL/SQL logic to find UoM inconsistencies before migration:

 
```
SELECT unit_code, COUNT(*) 
FROM legacy_inventory_parts 
GROUP BY unit_code 
HAVING COUNT(*) > 0;```

 ## Phase 3: Data Mapping & Technical Modeling

 Phase 3 bridges the gap between your old system and the **Aurena UI / OData** architecture of IFS Cloud.

 Map Legacy to IFS Projections Don't map to tables; map to **Projections** (e.g., `PurchOrder` → `PurchaseOrderProjection`). This ensures business logic is triggered during the load.

 Address Time-Zone Sensitivity In 2026, global SCM demands UTC precision. All "Wanted Delivery Dates" must be converted from Date-only to `YYYY-MM-DD-HH24.MI.SS` formats.

 Validate Site-Specific Logic Ensure Parts are correctly mapped to their specific **Sites** and **Inventory Locations**. An inventory part without a site link is invisible to the planning engine.

 ## Phase 4: The Loading & Validation Loop

 Success in Phase 4 is measured by "Zero-Error" reconciliation. This is the "trial by fire" for your data modeling.

 Perform "Gold Load" (Trial 1) Do not migrate everything at once. Migrate a 10% representative sample into the TEST environment to identify "edge case" mapping errors.

 Reconcile Financial Balances The "Total Inventory Value" in legacy must match the post-load value in IFS Cloud. If they differ, check your **Part Costing** migration logic.

 Check Permission Sets & Row-Level Security Verify that governance works. A migrated user in the "Purchasing" role should not be able to see "Executive Payroll" data fields within the same projection.

 ## Phase 5: Post-Go-Live Governance

 Migration doesn't end at Go-Live. It shifts from "Data Moving" to "Data Defending."

 Decommission Legacy Access Move legacy SCM data to a read-only archive. This prevents users from returning to old habits and ensures IFS Cloud is the **Single Version of the Truth**.

 Activate History Logs Turn on **History Logs** for sensitive SCM attributes (e.g., Supplier Price Lists). This creates a permanent audit trail for governance compliance.

 Schedule Monthly AI Audits Use IFS Lobbies and AI-driven alerts to monitor for "Dirty Data" trends, such as parts repeatedly entered without lead times.

 ## Frequently Asked Questions

 ## 

 IFS Cloud logic will not allow lead times < 0. During migration, use an SQL transformation to set a default minimum of 1 day for any null or negative values to prevent MRP calculation failures.

 ## 

 While IALs still exist, it is highly recommended to use **Migration Jobs** based on **OData Projections**. This ensures that the data respects the "Business Logic" of the latest IFS Cloud release, which IALs often bypass.

 ## 

 An Evergreen strategy means your data must be constantly maintained. Unlike older ERPs, you cannot wait 10 years to "clean up." You must implement Phase 5 (Governance) as a continuous monthly process to prevent the system from slowing down during bi-annual updates.

 **Final Thought:** Data migration is a bridge, not a destination. When built with a focus on governance, it becomes the foundation for every AI decision your business makes in the next decade.

 Prepared by the IFS ERP SCM Implementation Team | Jan 2026


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-data-migration-checklist-2026-edition.md)

## Designing Audit-Ready Permission Sets in IFS Cloud

![Designing Audit-Ready Permission Sets in IFS Cloud](https://www.ifs-erp.com/images/Permission_sets_audit.webp)

## TL;DR (Too Long; Didn't Read)

 
- **The Problem:** Routine IFS Cloud implementations suffer from "Permission Bloat" because over-privileged users and cloned sets fail ISO/SOC audits.
- **The Solution:** Implementing a Granular Access Control matrix based on functional roles rather than legacy user habits.
- **Key Outcome:** Audit-ready security that enables the "Moment of Service" for mobile users without exposing core financial or HR data.
- **Service Focus:** Permission Sets Mastery & SoD Matrix Design.

 {toc}

 ## What Problem Does This Article Solve?

 Many organizations treat ERP security as a technical afterthought. This leads to **Security Debt**: a state where the system is so cluttered with "cloned" permission sets and administrative overrides that it becomes impossible to pass a modern compliance audit (ISO 27001, SOC2). This article provides the blueprint for transitioning from "Permissive Security" to "Enabled Security," ensuring your IFS Cloud environment is a business asset rather than a liability.

 ## 1. Common Security Pitfalls in IFS Cloud Environments

 In the transition from legacy versions like IFS Applications 9 or 10 to **IFS Cloud**, many technical teams take the path of least resistance. This path is littered with vulnerabilities.

 
### The Danger of "Cloned" Permission Sets

 The "Clone" button is the most dangerous tool in an administrator’s arsenal. When a new user needs access similar to an existing one, admins often clone a massive permission set. Over time, this creates a "Snowball Effect" where privileges are inherited but never revoked. In an Evergreen environment like IFS Cloud, legacy clones may not support new security checkpoints in R1/R2 releases, leading to system instability or hidden backdoors.

 
> "Cloned permission sets are the technical debt of the security world. They provide a quick fix today but create a forensic nightmare for auditors tomorrow."

 
### Over-Privileged Users and "God Mode"

 Nearly 20% of users typically hold full system access because it simplifies their daily tasks. These over-privileged users represent a primary target for credential harvesting. IFS Cloud exposes the OData provider along with REST APIs. Excessive permissions create risks for the user interface. They threaten the entire database layer.

 ## 2. Designing a Granular Access Control Matrix for ISO Compliance

 To satisfy an ISO 27001 or internal auditor, you must prove **The Principle of Least Privilege**. This requires a shift to a robust Role-Based Access Control (RBAC) model.

 ### Step 1: Functional Mapping

 Do not map permissions to people; map them to business processes. Identify the "Functional Roles" (e.g., Accounts Payable Clerk, Warehouse Supervisor, Maintenance Technician). Each role should have a dedicated permission set that only includes the Projections, Pages, and Actions required for that specific process.

 ### Step 2: Defining the Base Profile

 Every user should inherit a "Global Base" set. This includes non-sensitive access: viewing the employee lobby, basic document management, and personal time reporting. By separating the Base from the Role, you simplify the audit trail.

 
### Segregation of Duties (SoD) in IFS Cloud

 A critical component of your matrix is the **SoD Matrix**. In IFS Cloud, you must ensure that the user who creates a Supplier cannot also Authorize a Payment. We utilize the IFS Cloud Security Dashboard to monitor these conflicts in real-time. Our *Permission Sets Mastery* service includes the pre-configuration of these SoD rules to ensure you are "Secure by Design."

 | Requirement | Implementation in IFS Cloud | Audit Evidence |
| --- | --- | --- |
| Identification | Identity Management (IAM) Integration | SAML/Azure AD Logs |
| Authorization | Projection-Based Permission Sets | Security Grant Reports |
| Accountability | History Log Configuration | Audit Trail of Record Changes |

 ## 3. Security and the "Moment of Service": The Mobile Frontier

 IFS Cloud supports the **Moment of Service**. This describes the point where a technician or consultant interacts with a customer. These interactions frequently take place on a mobile device such as IFS Service Drive or Scan It.

 
### Balanced Mobile Security

 The challenge is providing enough access for a field technician to complete a work order without giving them access to the company's financial balance sheets. We solve this by designing "Mobile-First" permission sets. These sets focus on **Offline Data Sync** security. You must control which data is cached on the device and ensure that when a technician leaves the company, their access is revoked globally via the IAM (Identity and Access Management).

 
### The Connection Between UI and API

 In IFS Cloud, the Page Designer allows us to hide fields, but **Hiding is not Securing**. True security happens at the Projection level. Even if a field is hidden on a mobile screen, a savvy user could theoretically access it via an OData call if the underlying projection is not secured. Our methodology ensures that the back-end API access matches the front-end user experience.

 ## 4. Why CIOs and CISOs Choose Permission Sets Mastery

 Security is often seen as a "No" department. Our goal is to turn it into an "Enable" department. By having clean, audit-ready permission sets, the business can move faster. New employees are onboarded in minutes, not days. Software updates (the Evergreen cycle) become predictable because we know exactly which roles are impacted by new features.

 
- **Reduced Risk:** Eliminate unauthorized data exports.
- **Audit Readiness:** Go into your annual audit with confidence and documented proof of SoD.
- **Lower Maintenance:** Fewer, higher-quality permission sets mean less work for your IT team.

 ## Stop Guessing Your Security Status

 Don't let "Permission Bloat" compromise your IFS Cloud implementation. Secure your data, satisfy your auditors, and empower your mobile workforce.

 [Book an IFS Cloud Security Audit](https://www.ifs-erp.com/contact)

 ## Frequently Asked Questions

 ### 

 IFS Cloud uses a Projection-based security model tied to the OData provider. Unlike Apps 10, which relied heavily on SQL-level access, Cloud focuses on securing the API layer, which is essential for its "Evergreen" update model.

 ### 

 Yes. IFS Cloud’s IAM (Identity and Access Management) integrates directly with Azure AD. While user authentication happens in Azure, the granular "Permission Sets" are still managed within IFS to control specific functional actions.

 ### 

 It is the practice of limiting user access to the minimal level that allows them to perform their job functions. This reduces the "Attack Surface" and prevents accidental data deletion or fraud.

 ### 

 Depending on the number of users and complexity of modules, a standard "Mastery" project takes between 4 to 8 weeks, including process mapping, set construction, and UAT (User Acceptance Testing).


[Read more...](https://www.ifs-erp.com/blog/permission-sets-in-ifs-cloud.md)

## Integrated Compliance

![Integrated Compliance](https://www.ifs-erp.com/images/iso_ifs_cloud.webp)

## Executive Summary (TL;DR)

 **For CIOs, IT Directors, and Quality Managers:**

 Transitioning to modern Cloud ERP environments like IFS Cloud™ presents a unique opportunity to dismantle the silos between your operational data and your compliance requirements. Traditionally, ISO 9001 (Quality), ISO 14001 (Environment), and ISO 45001 (Health & Safety) have been managed via disparate spreadsheets, third-party software, or physical paper trails. This fragmented approach increases risk, duplicates data entry, and fails to provide real-time insights.

 This guide demonstrates how to utilize native ERP capabilities as a single, digital "Source of Truth" for your Integrated Management System (IMS). By embedding compliance controls directly into the ERP transactional flow—such as blocking a receipt from an unapproved vendor or preventing a work order assignment to an uncertified technician—you move from "compliance by inspection" to "compliance by design."

 
---

 
##### Core Takeaways:

 
- **Unified Data Model:** A single audit trail links a customer complaint (ISO 9001) to a root cause analysis, or a chemical spill (ISO 14001) to the specific inventory batch and storage location.
- **Audit Velocity:** Reduce external audit preparation time by up to 40% using "Lobby" dashboards that present real-time evidence to auditors without manual report compilation.
- **Active Risk Management:** Replace static risk registers with dynamic controls. Use the system to physically stop processes (e.g., shipping, production) when compliance criteria are not met.

 ## ISO 9001:2015 – Quality Management Systems

 The standard for Quality Management is not just about product quality; it is about process consistency and customer satisfaction. Native ERP architecture covers this primarily through the **Quality Management (QM)** and **Document Management (DocMan)** modules.

 ### Clause 7.5: Documented Information

 ISO 9001 demands strict control over documents. In legacy systems, "Work Instructions" often drift out of sync with the actual process.

 Implementation Strategy:

 
- **Integrated Document Management (IDM):** Configure your `Doc Class` structure to separate Policies, SOPs, and Forms.
- **Access Control:** Use "Access Templates" to ensure that Obsolete documents are automatically hidden from the "Shop Floor Workbench" users.
- **Visual Work Instructions:** Attach media (PDFs, Videos) directly to the *Routing Operation*. When a shop floor operator opens a shop order operation, the latest approved instruction opens automatically.

 ### Clause 8.4: Control of External Processes

 You must ensure your suppliers meet your requirements. This goes beyond a one-time check.

 Implementation Strategy:

 
- **Supplier for Purchase Part (SFPP):** Configure "Inspection Codes" to force mandatory incoming inspections for new vendors.
- **Vendor Rating:** Utilize the automatic *Supplier Reliability* calculation (delivery on time) and link it to quality stats.
- **Solution:** Set up a "Lobby" element that flags any Purchase Order creation for a supplier with an expired ISO 9001 certificate (tracked in `Supplier_Info_Address`).

 #### Addressing Clause 10.2: Non-conformity and Corrective Action

 Do not manage NCRs in a separate "Quality" software. Use the integrated **Non-Conformance Report (NCR)** object. Configure the *Corrective Action* tab to be mandatory before the NCR status can move to "Closed". This enforces the "Check" and "Act" phases of the PDCA cycle directly in the transactional workflow.

 ## ISO 14001:2015 – Environmental Management

 This standard focuses on environmental performance and the "Lifecycle Perspective." Advanced ERP platforms support this via **Eco-Footprint Management** and **Chemical Safety**.

 | ISO Requirement | Relevant Capability | Implementation Strategy |
| --- | --- | --- |
| 6.1.2 Environmental Aspects | Eco-Footprint Management | Enable the Eco-Footprint component. Map emission factors (CO2, Water, Energy) to your *Work Centers* and *Purchase Parts*. This allows the system to calculate the environmental impact of a finished good based on its BOM and Routing, satisfying the "Lifecycle Perspective." |
| 6.1.3 Compliance Obligations | Document Management | *Gap Note:* ERPs do not natively stream global regulations.   
**Action:** Create a Document Class "REG" for your Legal Register (Permits, Laws). Set "Review Intervals" in DocMan to trigger reminders 90 days before a permit expires. |
| 8.1 Operational Planning | Maintenance (Asset Mgmt) | Identify environmentally critical equipment (e.g., Scrubbers, Waste Water Treatment). Create **Preventive Maintenance (PM) Actions** with a specific "CRITICALITY" flag. Use IoT connectors to trigger a PM if a sensor detects an emission breach. |
| 8.2 Emergency Preparedness | Incident Management | Configure **Incident Class** = "ENVIRONMENTAL". Train staff to log spills via the Mobile app immediately. This logs the time, location, and immediate containment actions, serving as vital evidence for auditors. |

 ## ISO 45001:2018 – Occupational Health & Safety

 Preventing work-related injury is paramount. Robust ERP systems integrate OHS directly into **Human Capital Management (HCM)** and **Work Orders**.

 #### Clause 7.2: Competence

 "Ensure that workers are competent on the basis of appropriate education, training, or experience."

 #### The "Hard Stop" Configuration

 One of the most powerful features is the ability to link **Qualifications** to **Resource Management** to prevent uncertified work.

 1 Define a "License" in HCM for high-risk tasks (e.g., "Forklift Operation", "Confined Space Entry").

 2 Assign this License to the specific Employee Profile with a valid-to date.

 3 **Critical Step:** In the *Maintenance Scheduling Optimization (MSO)* or *Service Dispatch*, enable the constraint that checks for valid licenses.

 4 **Result:** The system will *fail* to assign a work order to a technician if their safety certification has expired. This is irrefutable evidence of compliance.

 #### Clause 5.4: Consultation and Participation of Workers

 ISO 45001 requires non-managerial workers to participate. Use the **Survey** module to send out monthly "Safety Culture" surveys to shop floor users. The results can be aggregated anonymously and displayed in a Safety Lobby, demonstrating active worker engagement.

  ## Source Data Prerequisites

 Your system is only as compliant as the data within it. Before you enter the "Construct" phase, ensure the following datasets are cleansed and ready.

 ##### Quality Data

 
- **Inspection Codes:** Standardize your defect reasons (e.g., "Scratch", "Dimension", "Color").
- **Variable Data:** Define min/max tolerances for all critical attributes.
- **Tool Calibration:** List of all gauges, serial numbers, and last calibration dates.

 ##### Environmental

 
- **Emission Factors:** CO2e per kWh, Water usage per hour per work center.
- **Waste Streams:** List of EWC (European Waste Catalogue) codes you utilize.
- **Hazardous Materials:** CAS numbers and REACH status for all raw materials.

 ##### Safety Data

 
- **Risk Library:** Standard list of workplace hazards (Slip/Trip, Electrical, Noise).
- **PPE Matrix:** Which Personal Protective Equipment is required for which Job Role?
- **Employee Certs:** Scans of physical licenses and their expiry dates.

 ## Frequently Asked Questions

  Do we need to buy a separate QMS software package?  No. A robust ERP includes a fully embedded Quality Management System. Using third-party "bolt-on" software often leads to data silos where quality data (NCRs) is disconnected from inventory and production data. An integrated approach is superior for ISO 9001 compliance.

    How can external auditors access our records?  We recommend configuring a restricted "Auditor" user role. This role should have "Read Only" access to specific Lobbies (Dashboards) and the Document Management system. This allows auditors to self-serve evidence without accessing sensitive commercial or HR salary data.

    Can the ERP handle the 'Legal Register' for ISO 14001?  Core ERP systems are transactional systems, not legal content providers. While it cannot automatically "know" that a local environmental law has changed, you can manage the *compliance tasks* within it. We recommend subscribing to a legal update service and manually updating your "Legal Register" document, using "Review Tasks" to prompt periodic checks.

    How do we handle 'Change Management' (ISO 9001 Clause 6.3)?  For product changes, use the **Engineering Change Management (ECM)** module. For process or organizational changes, many clients configure a "Change Request" case in the **Call Center/Case Management** module to track the approval, risk assessment, and implementation steps of a change project.

    Is mobile capability required for ISO 45001?  While not strictly "required" by the standard, it is highly recommended for **Incident Reporting**. The easier you make it for workers to report "Near Misses" (via a mobile app on the shop floor), the more data you will capture, leading to better risk prevention and demonstrable "Worker Participation."


[Read more...](https://www.ifs-erp.com/blog/iso-standards-in-ifs-cloud.md)

## Mastering Distribution Orders in IFS Cloud: The Complete Guide

![Mastering Distribution Orders in IFS Cloud: The Complete Guide](https://www.ifs-erp.com/images/Distribution_Orders.webp)

A comprehensive deep dive into multi-site inventory movements, configuration strategies, and automated logistics flows.

 
---

 #### TL;DR: Executive Summary

 **Distribution Orders (DO)** are the backbone of internal supply chains in IFS Cloud, bridging the gap between two sites (Supply and Demand). Unlike simple inventory moves, DOs formalize the process by automatically generating a linked **Customer Order (on the Supply Site)** and **Purchase Order (on the Demand Site)**.

 
---

 
- **Best For:** Formal inter-site transfers requiring documentation (delivery notes, invoices) or cross-company moves.
- **Key Benefit:** Full visibility of demand and supply on both sites instantly.
- **Automation:** Can be triggered automatically by MRP, Master Scheduling, or DOP.
- **Prerequisite:** Requires "Internal Supplier" and "Internal Customer" setup between sites.

 ## What Problem Does This Solve?

 In complex organizations with multiple geographically dispersed sites (e.g., a central manufacturing plant in Poland and distribution centers in Germany and France), moving stock is not as simple as physically transporting it. You face several challenges:

 ##### The Logistics Challenge

 How do you ensure the receiving site knows what is coming and when? How does the shipping site reserve stock so it isn't sold to an external customer by mistake?

 ##### The Financial Challenge

 If sites belong to different legal entities (companies), how do you handle the financial transaction? You need an inter-company invoice and a purchase match.

 **Distribution Orders solve these problems** by wrapping a simple "move" request into a formal structure. They act as a container that spawns the necessary legal and logistical documents (CO and PO) while keeping the user interface simple for the planner. They ensure that *Site A* sees a firm demand and *Site B* sees a firm supply, synchronizing the entire supply chain.

 ## 1. The Core Concept of Distribution Orders

 A **Distribution Order** in IFS Cloud is a specialized supply object used strictly for moving inventory parts between two sites. While it might seem similar to a Requisition or a Transport Task, it is significantly more powerful because it integrates the **Procurement** and **Sales** modules seamlessly.

 When a planner at the Demand Site (e.g., a warehouse running low on stock) raises a need, they create a planned Distribution Order. At this stage, it is merely a signal—a "soft" request. However, once this order is **Released**, the system performs a massive orchestration task:

 
- It checks the **Internal Customer** definition to see who the Demand Site "is" from the perspective of the Supply Site.
- It checks the **Internal Supplier** definition to see who the Supply Site "is" from the perspective of the Demand Site.
- It automatically creates a **Customer Order (CO)** on the Supply Site.
- It automatically creates a **Purchase Order (PO)** on the Demand Site.
- It hard-links these two orders together.

 This "Triad" of records (DO, CO, PO) remains synchronized. If you change the quantity on the Distribution Order, the CO and PO update (subject to status restrictions). This eliminates the need for phone calls or emails between site planners to adjust quantities or dates.

 
## 2. Prerequisites and Configuration

 Distribution Orders will not function "out of the box" without specific master data setup. This is often where implementations fail. The following hierarchy of data must exist:

 Demand Site Requirements

 - **Inventory Part:** The part must exist in the inventory registry.
- **Purchase Part:** Since this site is "buying" the goods (even internally), a Purchase Part record is required.
- **Supplier for Purchase Part:** You must link the part to a Supplier. **Crucially**, this Supplier must be flagged as an "Internal Supplier" linking to the Supply Site.

 Supply Site Requirements

 - **Inventory Part:** The part must exist and have stock (or a way to source it).
- **Sales Part:** Since this site is "selling" the goods, a Sales Part record is required.
- **Internal Customer:** The Demand Site must be defined as a Customer in this site, and that Customer record must be linked to the Demand Site ID.

 
### The "Quick Registered Part" Feature

 Setting up thousands of parts for distribution can be tedious. IFS Cloud includes a feature to ease this. If the *Inventory Part* exists on both sites, but the Purchase or Sales parts are missing, the system can attempt to create them automatically upon the release of the Distribution Order. These automatically created records are flagged as **Quick Registered Parts**. While helpful for testing or low-volume scenarios, it is best practice to fully configure your parts to ensure correct tax codes, delivery terms, and pricing are applied.

 
## 3. Sourcing and Automation

 The true power of Distribution Orders lies in their ability to be generated automatically by planning engines. A planner rarely needs to manually enter a DO unless it is for an emergency spot-buy.

 
#### Material Requirements Planning (MRP)

 When MRP runs on the Demand Site, it sees a shortage. It looks at the *Supplier for Purchase Part* record. If the primary supplier is an Internal Supplier and the **Multi-site Planned Part** checkbox is enabled, MRP will generate a **Planned Distribution Order** instead of a Purchase Requisition.

 This is a critical distinction. A Purchase Requisition requires a conversion step to become a PO. A Planned Distribution Order is already one step closer to execution. It appears in the "Distribution Orders" window with a status of *Planned*.

 
#### Distribution Allocations

 For "Push" scenarios (where a central warehouse wants to push stock out to branches regardless of their current demand), **Distribution Allocations** are used. You define a template (e.g., "Send 10% of stock to London, 20% to Paris"). When you execute this allocation, the system spawns multiple Distribution Orders.

 
#### Dynamic Order Processing (DOP)

 In complex Make-to-Order environments, DOP uses Distribution Orders to move pegged material. If a Top Level Part is being built in Site A, but a sub-assembly is built in Site B, the DOP structure's "Capability Check" will generate a Distribution Order to move that sub-assembly. These orders are often released automatically to preserve the tight timeline of the DOP structure.

 
## 4. The Lifecycle and Execution Flow

 Understanding the status flow is essential for troubleshooting.

 | Status | Description | Actions Available |
| --- | --- | --- |
| Planned | The need is identified. No logistics or financial documents exist yet. | Can be deleted, changed freely. MRP can delete and recreate this. |
| Stopped | The order tried to release but failed validation (e.g., missing part setup, credit block). | Must be fixed manually via "Release Stopped Distribution Orders". |
| Released | The "Point of No Return". CO and PO are created. Inventory on Supply Site is visible as "Demand". | Reservations can be made. Pick Lists can be printed. |
| Reserved | Stock on the Supply Site is hard-allocated to this order. | Ready for picking. |
| In Transit | Goods have left the Supply Site (delivered/shipped) but not yet arrived at Demand Site. | Supply Site work is done. Demand Site awaits arrival. |
| Closed | Goods received at Demand Site. | Transaction is complete. History is preserved. |

 
### The "Stop" Mechanism

 A unique feature of Distribution Orders is the **Stopped** status. Unlike a PO that might just fail to save, a DO will save itself but enter a "Stopped" state if it encounters errors during the auto-release process (common in MRP runs).

 This often happens due to **Coordinators**. If a user manualy enters a DO, their coordinator ID is used. If MRP creates it, the system looks for a default coordinator on the Supplier record. If none is found, or if the resulting CO/PO fails validation (e.g., Customer is Credit Blocked), the DO stops.

 *Administrator Tip:* Regularly check the "Release Stopped Distribution Orders" window. It is the "graveyard" of failed internal supply chain movements.

 
## 5. Strategic Advantages vs. Other Methods

 Why use Distribution Orders instead of standard Purchase Orders or the newer "Shipment Orders"?

 ## 

 **Instant Visibility.** With a standard PO, the supplier (even if internal) has to manually enter a Customer Order to match it. Until they do, there is no visibility on the supply side. With a DO, the CO is created *instantly* and automatically. The supply site planner sees the demand immediately upon release.

 ## 

 **Complexity & Finance.** Shipment Orders are a lighter object designed for logistics-only moves (e.g., moving goods between two warehouses in the same company where no invoice is needed). They do not create a CO/PO. Distribution Orders are heavier but necessary for **Inter-Company** moves where a financial invoice is legally required. If you are moving goods between entities (e.g., Germany GmbH to France SAS), you *must* use Distribution Orders.

 
## 6. Advanced Configuration: Automatic Receipt

 Efficiency is key. You can configure the system to **Automatically Receive** goods on the Demand Site the moment they are shipped from the Supply Site.

 This is dangerous if physical transit time is long (e.g., sea freight), as your system will show stock available in the receiving warehouse while it is still on a boat. However, for "Virtual" moves or immediate transfers between adjacent buildings, this setting saves a massive amount of data entry.

 To enable this, check the **Automatic Receipt** parameter on the *Internal Supplier* setup. When the Supply Site executes "Deliver Customer Order," the Demand Site's "Register Arrival" is performed instantly in the background.

 
## 7. Troubleshooting & Best Practices

 **The "Coordinator Group" Error:**   
A common error is "Coordinator not allowed for user". Distribution Orders rely heavily on Coordinator Groups to determine DO numbers and prefixes. Ensure every planner belongs to a valid Coordinator Group and that the default coordinators on your Supplier/Customer records are active users.

 **Re-Planning Flexibility:**   
Planned DOs are flexible. Released DOs are rigid. Establish a "Release Horizon" policy. For example, only release DOs that are due within the next 5 days. Leave the rest as "Planned". This allows MRP to delete and recreate them if the forecast changes, keeping your plan responsive. Once you release a DO, you "freeze" that decision.

 ### Frequently Asked Questions

 ## 

 **Yes.** This is one of the main use cases. Because a DO creates a linked Customer Order and Purchase Order, it supports the full financial inter-company invoicing flow (sending an invoice from Supply Company and matching it in Demand Company).

 ## 

 Common reasons include: 
- Missing Purchase Part or Sales Part setup.
- The Internal Customer is "Credit Blocked" on the Supply Site.
- Missing Default Coordinator on the Supplier for Purchase Part.
- Inventory Part does not exist on one of the sites.

 Check the "Release Stopped Distribution Orders" window for the specific error message.

 ## 

 Yes. You can manually process the "Deliver" step on the Distribution Order line itself. However, using the **Shipment** functionality is recommended if you are consolidating multiple orders onto one truck or need formal shipping documents (Bill of Lading, Packing List).

 ## 

 "Release for Planning" is a status on the *Customer Order* side that allows the supply site to see the demand but prevents shipping. For Distribution Orders, we generally talk about the main "Planned" to "Released" transition. When a DO is released, the created CO is usually set to "Released" automatically, making it immediately actionable.

 ## 

 **Absolutely.** On the Demand Site, a Planned DO is a supply. On the Supply Site, a Released DO (via its CO) is a demand. Note that *Planned* DOs do not create visible demand on the Supply Site until they are released (unless you use specific MS/MRP inter-site visibility settings, but standard DO logic requires release for firm demand visibility).

  

 Learn more about the logistics execution connected to these orders in this [Shipment Invoice functionality in IFS Cloud](https://www.youtube.com/watch?v=qlNzjwnmr6s) tutorial.


[Read more...](https://www.ifs-erp.com/blog/distribution-orders-in-ifs-cloud.md)

## The True Cost of Customization in IFS Cloud

![The True Cost of Customization in IFS Cloud](https://www.ifs-erp.com/images/Cost%20of%20Customization%20in%20IFS%20Cloud.webp)

A critical analysis of Total Cost of Ownership (TCO). Why the sticker price of development is only the tip of the iceberg in an Evergreen ERP environment.

 Category: ERP Strategy Focus: TCO & ROI

 
---

 ### The "Perfect Fit" Paradox

 In the legacy ERP era, customizing the system to match business processes 1:1 was the standard. In the **IFS Cloud** era, this mindset is the single largest driver of inflated TCO. The cost of customization is no longer just about the initial development fee; it is about the "interest" you pay on that technical debt during every bi-annual release (25R1, 25R2, etc.).

 ## Deconstructing the Price Tag

 The financial impact of modifying IFS Cloud varies wildly based on complexity, but it typically falls into three distinct buckets. Understanding these allows you to predict your implementation budget more accurately.

  

 
#### 1. Complexity & Scale

 **Low Cost:** Simple configurations using Page Designer or Custom Fields.   
  
**High Cost:** Developing entirely new logical units (LUs), complex integrations via Dell Boomi/REST APIs, or modifying core logic.

 Impact: Exponential

  

 
#### 2. Partner Selection

 Hourly rates differ significantly between global System Integrators (SIs) and boutique consultancies. However, "cheaper" rates often lead to higher costs later if the code isn't optimized for the IFS Cloud update cadence.

 Impact: Variable

  

 
#### 3. Internal Resources

 Often overlooked: The cost of your own team. Requirement gathering, User Acceptance Testing (UAT), and re-training your staff on custom workflows constitute a massive portion of the investment.

 Impact: Hidden

 ### Configuration vs. Development: A Cost Comparison

 | Method | Examples | Initial Cost | Maintenance (TCO) |
| --- | --- | --- | --- |
| Configuration | Page Designer layouts, Custom Fields, BPA (Business Process Automation), Lobbies. | Low | Very Low (Upgrade Safe) |
| CRIM (Modification) | PL/SQL logic changes, New API endpoints, Custom Events modifying data. | Medium | Medium (Requires Regression Testing) |
| Full Customization | Building new Modules, Heavy Integration layers, changing core architecture. | High | High (Risk of Upgrade Conflicts) |

 ### How to Manage Costs Effectively

 IFS offers "Composable" capabilities to reduce the need for code.

 To minimize TCO over a 5-year lifecycle, organizations must adopt a **"Standard First"** approach. Leverage the existing capabilities of IFS Cloud (Service Management, EAM, Manufacturing) before authorizing custom development.

 
- Use **BPA** (Business Process Automation) instead of triggers.
- Use **Page Designer** to hide complexity rather than rewriting forms.
- Challenge every requirement: "Is this a business differentiator, or just a habit?"

 ##### Need a Modification Assessment?

 Don't build technical debt. Let us validate your CRIMs.

 [Contact IFS-ERP.com](https://www.ifs-erp.com/contact)

 ### Frequently Asked Questions (FAQ)

 ## 

 **Configuration** uses built-in IFS tools (like Page Designer or Custom Fields) to adapt existing features. It is generally upgrade-safe and low cost. **Customization** (or Modification) involves writing new code to create functionality that does not exist. This is more expensive and requires maintenance during upgrades.

 ## 

 Yes. IFS Cloud releases updates twice a year (R1 and R2). If you have heavy customizations, you must validate (regression test) them against every new release to ensure they don't break. High customization levels increase the time and cost of these mandatory updates.

 ## 

 Costs are typically calculated by: **(Estimated Developer Hours × Partner Hourly Rate) + Testing Time + Project Management**. However, the true cost must also include the **Lifecycle Maintenance** cost (re-testing and fixing) over the next 5-7 years.

 ## 

 Often, yes. IFS Lobbies provide real-time dashboards that can replace static PDF reports. Lobbies are considered "Configuration" and are much cheaper to maintain than developing custom Crystal Reports or SQL Quick Reports.


[Read more...](https://www.ifs-erp.com/blog/the-true-cost-of-customization-in-ifs-cloud.md)

## IFS Cloud functionality and Workflows

The "Workflow First" Philosophy

 At IFS-ERP.com, we advocate for a **"Workflow First"** mindset. Before authorizing a developer to write custom code, the solution architect should always ask: *Can this be achieved via Workflow?*

 ### Configuration vs. Customization

  

 Implementation

 **Old Way:** Requires Developer (C#/PLSQL)  
  
**New Way:** Requires Functional Consultant

  

 Visibility

 **Old Way:** Hidden in code files  
  
**New Way:** Visual Flowchart (BPMN)

  

 Maintenance

 **Old Way:** High (Code reviews, compile times)  
  
**New Way:** Low (Adjust and Publish)

  

 Upgrade Risk

 **Old Way:** High (Breakage likely)  
  
**New Way:** Low (Forward compatible)

 ### When Customization Is Still Necessary

 While Workflows are powerful, they are not a silver bullet. There are specific thresholds where configuration ends and "Extensibility" begins.

  

 1. Deep System Integrations

 For complex encrypted bank files or high-frequency machine interfaces, standard workflows may fall short.  
  
Verdict: Use custom projections or integration middleware.

  

 2. Performance-Heavy Logic

 Looping through 50,000 records to perform a nightly calculation via workflow is significantly slower than PL/SQL.  
  
Verdict: Use heavy server-side logic for bulk data processing.

  

 3. Unique Complex Algorithms

 If a business rule results in a BPMN "spaghetti diagram," it becomes impossible to maintain.  
  
Verdict: Encapsulate the complex logic in code, and call it from a workflow.

 Frequently Asked Questions

 #### Optimizing for the Evergreen Era

 Understanding the distinction between **Configuration** and **Customization** is vital for maintaining a healthy IFS Cloud environment.

 Utilizing the native **Workflow Engine** ensures your business logic remains intact during bi-annual releases, reducing the "Technical Debt" that traditionally plagues ERP upgrades.

 What is the difference between IFS Configuration and Customization?

 **Configuration** uses native tools like the Workflow Manager to alter system behavior without code changes, ensuring upgrade safety. **Customization** involves modifying the core source code (PL/SQL, C#), which carries higher maintenance costs and upgrade risks.

 Do I need a developer to create IFS Workflows?

 **No.** IFS Workflows utilize BPMN (Business Process Modeling Notation), a visual low-code standard. This allows Functional Consultants and Business Analysts to design and implement complex processes visually, without writing traditional code.

 Are IFS Workflows safe for upgrades (Evergreen)?

 **Yes.** Workflows are stored as configuration data (XML models) separate from the core codebase. This makes them inherently "Evergreen" compliant, meaning they automatically migrate during IFS Cloud updates with minimal risk of breakage.

 Can Workflows replace all customizations?

 **Not all.** While they handle internal logic, data validation, and user interaction excellently, high-performance tasks (like bulk data processing) or complex external integrations (heavy bank files) are still better suited for specialized Customizations or IFS Connect.

 Summary

 IFS Workflows represent the maturation of the ERP landscape. They empower organizations to own their business processes without incurring the "technical debt" associated with traditional customization.

 **By adopting a "Workflow First" strategy, you adapt your ERP to your business, rather than adapting your business to your ERP.**


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-functionality-and-workflows.md)

##  Purchase Order Approval Workflow

![ Purchase Order Approval Workflow](https://www.ifs-erp.com/images/PurchaseApproval.webp)

An example of how IFS Cloud Workflows bridge the gap between user input and system automation without complex coding.

  

 1. Draft & Enrich

 **User Action:** Technician enters a PO.  
**Workflow:** Intercepts the "Save" event to auto-fill the "Site ID" and "Department" based on the user's profile, reducing manual entry errors.

  

 2. Budget Check

 **System Logic:** The Workflow Engine evaluates the total amount.  
*Condition:* If Total > $5,000, verify "Project Budget" availability. If exceeded, block the process with a custom error message.

  

 3. Manager Review

 **BPA Task:** A "User Form" pops up for the Approver.  
**Interaction:** The Manager clicks "Approve" or "Reject" directly from the notification. No navigation to complex screens required.

  

 4. Release & Send

 **Final Automation:** Upon approval, the workflow automatically changes the status to "Released" and triggers the PDF generation to email the supplier.


[Read more...](https://www.ifs-erp.com/blog/purchase-order-approval-workflow.md)

## The Golden Record in IFS Cloud

![The Golden Record in IFS Cloud](https://www.ifs-erp.com/images/GoldenRecordSmall.png)

## The Golden Record in IFS Cloud: Architecting Truth in Enterprise Data

 How to transform fragmented information into a single, authoritative asset that drives automation, accurate reporting, and strategic decision making.

 #### Table of Contents

 
- [1. Introduction: The Cost of Chaos](#introduction)
- [2. Defining the Golden Record in IFS Cloud](#what-is-golden-record)
- [3. The Architecture of Truth: How It Works](#architecture)
- [4. Core Processes: Ingestion, Matching, and Survivorship](#core-processes)
- [5. The Business Impact: Why It Matters](#business-impact)
- [6. Implementation Guide: Building Your Golden Record](#implementation-guide)
- [7. Future Trends in MDM](#future-trends)
- [8. Frequently Asked Questions (FAQ)](#faq)

 ## 1. Introduction: The Cost of Chaos

 In the modern enterprise, data is rarely scarce. It is overwhelming. Organizations utilizing robust ERP systems like IFS Cloud generate massive volumes of data daily. However, volume does not equal value. The true challenge lies in validity.

 Consider a manufacturing scenario. The sales department knows a customer as "Acme Corp" located in London. The logistics team sees "Acme Corporation Ltd" with a shipping address in Manchester. The finance team bills "Acme Intl" in New York. Who is right? Without a unified strategy, they all are, and yet none of them are.

 This fragmentation creates data silos. These silos are not merely an IT nuisance. They are operational hazards that bleed revenue through missed cross-selling opportunities, shipping errors, and compliance failures. The solution to this fragmentation is not just better software but a fundamental shift in how we treat data entities. The solution is the **Golden Record**.

 ### 2. Defining the Golden Record in IFS Cloud

 A "Golden Record" in the context of IFS Cloud Master Data Management (MDM) is the definitive, authoritative, and trusted version of a key business entity. It represents the "Single Source of Truth."

 It is not necessarily a single row in a database that has existed forever. Rather, it is a composite view created by consolidating, cleansing, and merging data from multiple sources. These sources might include the IFS Cloud Core, external CRM systems like Salesforce, legacy databases, or third-party data providers like Dun & Bradstreet.

 #### Key Characteristics

 
- **Authoritative:** It overrides conflicting data from subordinate systems.
- **Composite:** It may pull a phone number from CRM and a credit limit from Finance.
- **Persistent:** It maintains a unique identifier (UUID) that survives system updates.
- **Governed:** It is actively managed by data stewards and automated rules.

 ## 3. The Architecture of Truth: How It Works

 Creating a Golden Record within the IFS ecosystem requires a sophisticated architecture that sits between your data sources and your data consumers. In IFS Cloud, this is often managed through the native Master Data Management capabilities or via integration with specialized MDM hubs linked through IFS Connect or Boomi.

 ##### The Sources (The Input)

 Data enters the ecosystem from various "Local" sources. These are the systems of entry where users interact daily. In IFS Cloud, this could be the Supply Chain module, while a separate HR system feeds employee data. Each source contributes fragments of the truth.

 ##### The MDM Hub (The Processor)

 This is the engine room. Data is standardized here. "St." becomes "Street" and formatting is aligned. This central hub holds the rules for matching and merging. It is where the Golden Record is minted and stored.

 ##### The Subscribers (The Output)

 Once the Golden Record is established, it must be syndicated back to the operational systems. IFS Cloud consumes this record to ensure that when an invoice is generated, it uses the Golden address, not a fragmented local copy.

 ## 4. Core Processes: The Lifecycle of a Golden Record

 The creation of a Golden Record is not a one-time event. It is a continuous lifecycle. Understanding the mechanics of this lifecycle is critical for IFS consultants and business stakeholders alike.

 
### Phase 1: Ingestion and Standardization

 Data is ingested from source systems. Before any matching can occur, the data must be standardized. This involves parsing fields to ensure consistency. For example, phone numbers are formatted to E.164 standards, and country codes are aligned to ISO values. Without standardization, matching algorithms fail.

 
### Phase 2: Matching (Identity Resolution)

 This is the heart of MDM. The system asks a critical question: *"Are these two records actually the same person or company?"*

 Matching relies on two main approaches:

 
- **Deterministic Matching:** Exact matches on unique identifiers like Tax IDs, Email Addresses, or DUNS numbers. If the Tax ID matches, it is the same entity.
- **Probabilistic (Fuzzy) Matching:** This uses algorithms to calculate a likelihood score. If the name matches 90% and the address matches 80%, the system assigns a "Match Score." If the score exceeds a defined threshold, the records are linked as a candidate pair.

 
### Phase 3: Merging and Survivorship

 Once matches are identified, the system must decide which data points to keep. This is determined by **Survivorship Rules**. These rules dictate the hierarchy of trust.

 
| Rule Type | Description | Example |
| --- | --- | --- |
| **Recency** | Prioritize the most recently updated data. | "Use the address updated yesterday over the one from last year." |
| **Source System Trust** | Trust specific systems for specific data domains. | "Always trust CRM for phone numbers, but trust Finance for credit limits." |
| **Completeness** | Prioritize the record with the most populated fields. | "Keep the record that includes the postal code." |
| **Frequency** | Select the value that appears most often across sources. | "If 3 out of 4 systems say the name is 'Acme', use 'Acme'." |

 
### Phase 4: Data Stewardship

 Not all matches are clear. Some fall into a "grey area" where the match score is ambiguous. These exceptions are routed to a Data Steward. A Data Steward is a human expert who manually reviews the conflict within the IFS interface and makes the final decision to merge or separate the records.

 ## 5. The Business Impact: Why It Matters in IFS Cloud

 Implementing a Golden Record strategy is an investment. Why should an organization undertake this effort? The return on investment is realized through specific operational improvements.

 #### Unified 360-Degree View

 When you look at a customer in IFS Cloud, you see their entire history. Sales, support tickets, invoices, and projects are linked to one entity. This enables better customer service and targeted marketing.

 #### Operational Efficiency

 Duplicate records slow down processes. Warehouse staff waste time figuring out which "Vendor A" to receive goods against. A Golden Record streamlines these workflows, reducing manual intervention.

 #### Accurate Analytics

 Reporting is only as good as the underlying data. If you have five records for one supplier, your spend analysis will be fragmented. Golden Records ensure that Business Intelligence (BI) dashboards reflect reality.

 #### Compliance and Risk Management

 Regulatory frameworks like GDPR require you to know exactly what data you hold on an individual. If that data is scattered across duplicates, compliance is impossible. A Golden Record simplifies the "Right to be Forgotten" and data portability.

 ## 6. Implementation Guide: Building Your Golden Record

 Deploying this in IFS Cloud involves a structured approach. Follow these steps to ensure success.

 01 **Profile Your Data**  
Before fixing data, you must understand it. Use data profiling tools to analyze the quality of your current records. Identify common errors, duplication rates, and empty fields.

 02 **Define Governance Rules**  
Gather stakeholders from Finance, Sales, and Operations. Agree on what constitutes a "Golden" record. Decide which systems are trusted for which data attributes.

 03 **Configure Survivorship Logic**  
Program these rules into your MDM solution. Start with simple rules (e.g., Recency) and evolve to complex logic as you learn how the data behaves.

 04 **Initial Load and Cleanse**  
Run your initial batch process. This will likely generate a large number of stewardship tasks. This initial hump is normal. Clear the backlog to establish your baseline.

 05 **Enable Real-Time Synchronization**  
Once the baseline is set, switch to real-time. As new records enter IFS Cloud or connected apps, they should be instantly checked against the Golden Record to prevent new duplicates from forming.

 ## 7. Future Trends: AI and the Golden Record

 The future of MDM in IFS Cloud is intelligent. Generative AI and Machine Learning are beginning to play a massive role in Golden Record management.

 **Auto-Classification:** AI can look at unstructured data (like emails or PDFs) and automatically extract attributes to enrich the Golden Record.

 **Predictive Matching:** Machine Learning models can learn from the decisions made by human Data Stewards. Over time, the AI learns that "IBM" and "Intl Business Machines" are the same, reducing the need for manual review.

 ## 8. Frequently Asked Questions (FAQ)

 ##### What is the difference between a Golden Record and a Data Warehouse?

 A Data Warehouse is designed for analytics and reporting, often storing historical data. A Golden Record is an operational asset used for real-time transaction processing and master data management. The Golden Record feeds the Data Warehouse.

 ##### Does IFS Cloud have built-in MDM capabilities?

 Yes, IFS Cloud offers native capabilities for managing master data, including data migration tools and entity management. For complex, multi-system environments, it pairs effectively with dedicated MDM solutions via IFS Connect.

 ##### What happens if the Golden Record is wrong?

 If a Golden Record is incorrect, the error propagates to all subscribing systems. This is why Data Stewardship and "Unmerge" capabilities are essential features. You must be able to revert a merge if it was done in error.

 ##### How often should Golden Records be updated?

 Ideally, updates should happen in near real-time. As soon as a source system captures a change (e.g., a customer moves), the MDM hub should process this update and refresh the Golden Record.

 ### Ready to Trust Your Data?

 Data fragmentation is a choice. Choose clarity. Our team of IFS Cloud experts can help you design a Master Data Management strategy that builds a robust Golden Record foundation.

 [Start Your MDM Journey](https://www.ifs-erp.com/contact-us)


[Read more...](https://www.ifs-erp.com/blog/the-golden-record-in-ifs-cloud.md)

## Mastering Centralized Purchasing

![Mastering Centralized Purchasing](https://www.ifs-erp.com/images/Mastering%20Centralized%20Purchasing.webp)

## Mastering Centralized Purchasing

 Consolidate demand, decentralize delivery, and eliminate redundant inventory transactions in IFS Cloud.

 
---

 True centralized purchasing goes beyond just negotiating group discounts. It fundamentally separates the **transactional flow** (who orders) from the **physical flow** (where it arrives), allowing a central entity to buy on behalf of distributed sites without creating logistical nightmares.

 ## The Core Concept: Decoupling Flows

 In a standard setup, Site A buys and receives, then ships to Site B. In an optimized IFS Cloud Centralized model, this changes drastically:

 📄 **Transactional Flow** Local requisitions are consolidated into a single Purchase Order by the Central Purchasing Site. One vendor faces one buyer.

 🚚 **Physical Flow** The supplier delivers goods directly to the Demand Site. Receipt occurs locally. **No internal transit inventory is needed.**

 
## Strategic Prerequisites

 This model fails without strict data governance. Before flipping the switch in IFS Cloud, ensure the following prerequisites are met across all participating sites:

 ##### 1. Part Standardization (Crucial)

 If Site A and Site B order the same bolt, they **must** use identical Part Numbers and Units of Measure (UoM). The central catalog must align perfectly with local demand demands. Divergence here breaks the automation chain.

 ##### 2. Site Basic Data & Pricing Logic

 Configure site-level rules to define validity periods for default purchasing sites. Strategically, determine if pricing is fetched from the **Purchasing Site** (PO Header) or the **Demand Site** (PO Line). Using "Demand Site" pricing often simplifies administration.

 
## Operational Workflow

 ①

 **Requisition:** Demand site creates local requisition. If basic data aligns, "Central Order" is automatically enabled.

 ②

 **Consolidation:** Central buyer converts requisitions into a unified PO issued to the supplier.

 ③

 **Receipt:** Goods arrive at the demand site. Arrival registration is handled locally, inventory is updated instantly.

 ### Key Benefit

 Zero Internal Friction

 By having the supplier deliver directly to the demand site, you eliminate internal transport tasks, reduce handling damage risks, and remove the need for complex multi-leg inventory tracking.

 #### The Data Consistency Risk

 If part numbers or UoMs do not match between central and local sites, centralized orders will fail or create errors. **Mitigation Strategy:** Implement a Data Mesh architecture to ensure real-time synchronization of master data across decentralized locations.

 Success KPIs

 
- Reduction in total Purchase Orders issued (%).
- Decrease in internal logistics costs.
- Improved supplier terms via bulk volume.

 ## Frequently Asked Questions

 ## 

 No. This is the primary operational benefit. Receipt and arrival registration occur directly at the demand site, eliminating the need for internal moves between the central site and the final destination.

 ## 

 It depends on your configuration. A centralized order can retrieve price-related information from either the Purchasing Site (PO Header) OR the Demand Site (PO Line). This choice should be part of your strategic setup.

 ## 

 The "Central Order" option will not enable automatically. The system defaults to safety. However, buyers can intervene manually to select the option and specify necessary details, though this indicates a gap in your data governance.


[Read more...](https://www.ifs-erp.com/blog/mastering-centralized-purchasing.md)

## The Pallet in the Corner

![The Pallet in the Corner](https://www.ifs-erp.com/images/Warehouse_Pallet.webp)

# The Pallet in the Corner

 Why invisible inventory kills working capital and how to resolve it in IFS Cloud.

 
---

 Every warehouse manager knows it. It sits in the darkest aisle, typically on the top rack, gathering dust. The shrink wrap is yellowing. The label is faded. It is the "Pallet in the Corner."

 [See Remediation Strategies](#strategies)

 ## The Invisible Liability

 In the physical world, that pallet is just taking up space. In the financial reality of your ERP, it is an active asset inflating your balance sheet. This discrepancy is dangerous. It masks the true health of your supply chain and creates a false sense of security regarding your inventory levels.

 The "Pallet in the Corner" typically represents one of three things:

 
- **1. Engineering Ghosts:** Parts left over from a product revision (like Revision A) after Engineering released Revision B without a "use-up" plan.
- **2. The "Just in Case" Buy:** Bulk material purchased to secure a volume discount that exceeded the annual consumption rate.
- **3. Returns Limbo:** Customer returns (RMA) that were physically received but never processed into a disposition status.

 
## IFS Cloud Remediation Strategies

 To remove the pallet in the corner, you must move from passive monitoring to active disposition. IFS Cloud offers specific tools to automate this process.

 ##### 1. The Slow Moving Part Report

 Do not rely solely on stock aging. Configure the *Slow Moving Part* analysis to flag items where the **Turnover Rate** is close to zero. Set an event to trigger a "Block for Procurement" on these parts to stop the buying robot from adding to the pile.

 ##### 2. Automated Write-Downs

 Finance often fears the hit to the P&L. However, taking the hit is necessary. Use *Inventory Value* logic to automatically provision 100% of the value for stock aged over 360 days. This aligns the financial ledger with operational reality.

 ##### 3. The Golden Zone Rule

 Physically move the pallet. If it is not moving out the door, it should not be in the "Golden Zone" (waist-to-shoulder height near the docks). Move it to the upper racks or an off-site overflow location to free up premium space for high-velocity SKUs.

 ### Impact Analysis

 When you ignore the pallet in the corner, you pay for it three times:

 
1. **Carrying Cost:** Rent, insurance, and utilities (typically 25% of value/year).
2. **Opportunity Cost:** Cash trapped in dead stock cannot be used for R&D.
3. **Obsolescence:** The eventual write-off when the item becomes unusable.

 #### Quick Tip

 Run the *Inventory Part In Stock* report filtering for "Last Activity Date" < (Today - 365). You might be surprised by how many pallets are hiding in plain sight.

 ## Frequently Asked Questions

 ## 

 You must use the *Phase In / Phase Out* dates on the Inventory Part record. When releasing a new revision (Revision B), strictly set the "Phase Out" date for Revision A components or use the "Consume" logic in the structure to force the system to use up old stock before switching.

 ## 

 No. Before scrapping, consider "Cannibalization" (disassembling the finished good to recover valuable raw materials) or "Return to Vendor" (RTV) if the supplier accepts buybacks. You can also offer it to customers at a liquidation discount using a specific *Sales Price List*.

 ## 

 Yes. You should configure a specific *Cycle Count Analysis* for ABC classes C and D. These items do not need to be counted as frequently as your A-class items. Counting them once a year (or even less frequently if value is low) is often sufficient to maintain accuracy without wasting labor.


[Read more...](https://www.ifs-erp.com/blog/the-pallet-in-the-corner.md)

## How to Define Procurement Clause Phrases

![How to Define Procurement Clause Phrases](https://www.ifs-erp.com/images/article_p.png)

## Procurement Clause Phrases

 Standardize compliance, mitigate legal risk, and automate supplier communication in IFS Cloud.

 
---

 Leaving terms and conditions to "freestyle text" notes on a Purchase Order is a compliance nightmare. **Procurement Clause Phrases** allow you to centralize, version-control, and automate the specific legal and technical instructions printed on your purchasing documents.

 ## The "Freestyle Text" Problem

 In many organizations, buyers manually type instructions like *"Goods must be delivered on EUR-pallets"* or *"Certificate of Analysis required"* into the internal notes of a PO Line. This approach fails because:

 🚫 **No Standardization** Different buyers use different wording for the same requirement.

 🌍 **Language Barriers** Manual notes rarely handle multi-language outputs automatically.

 ⚖️ **Outdated Rules** Old regulations persist because notes are copied from previous orders.

 
## The Solution: Clause Architecture

 IFS Cloud solves this with a structured **Procurement Clause Library**. Instead of typing text, you configure "Phrases" that can be linked to parts, suppliers, or projects.

 ##### 1. Version Controlled Revisions

 Clauses are time-bound. You can define a "Mercury Content" clause that sets the limit to **8% for 2025** and automatically switches to **5% for 2026**. The system selects the correct text based on the PO's *Promised Delivery Date*.

 ##### 2. Automated "Push" Logic

 Stop relying on buyer memory. You can connect a clause to a specific **Part Group** (e.g., "Chemicals") or **Supplier**. When a buyer adds that part to a PO, the relevant safety or compliance text is attached automatically.

 ##### 3. Multi-Language Support

 Define the clause once in English, German, and Polish. If the Supplier's language code is set to "German," IFS Cloud prints the German version of the clause on the PDF, ensuring clear communication.

 ### Best Practice

 Don't clutter your library. Use **Procurement Clause Types** to categorize your phrases (e.g., "Logistics," "Quality," "Legal"). This makes it easier for buyers to find the right clause during manual entry.

 Implementation Checklist

 
- Define Clause Types (e.g., HAZMAT, PACKAGING).
- Create Phrase Text & Translations.
- Set Active/Inactive dates for Revisions.
- Connect to Parts or Suppliers (Optional).
- Test PDF Output on a Purchase Order.

 ## Frequently Asked Questions

 ## 

 **Document Text** is a general tool for adding notes to almost any object (Customer, Part, Order). **Procurement Clauses** are specialized for purchasing; they support strict revision control (valid-from/valid-to dates) and are better suited for legal compliance or technical specifications that change over time.

 ## 

 Yes. You can connect a clause to a generic "Company" level or specific "Supplier Group." However, be careful not to overload your POs with generic text. It is often better to use "Document Text" on the Company Header for generic T&Cs and "Procurement Clauses" for specific line-level requirements.

 ## 

 Yes. You can configure the system so that adding or removing a specific Clause Type (e.g., "Legal Deviation") triggers a new authorization rule, forcing the PO to go back for approval.


[Read more...](https://www.ifs-erp.com/blog/procurement-clause-phrases-in-ifs-cloud.md)

## Understanding Consolidated Shipments

![Understanding Consolidated Shipments](https://www.ifs-erp.com/images/Consolidate_Shipments.webp)

Logistics Optimization 
## Consolidated Shipments in IFS Cloud

 Stop shipping air. Combine multiple orders into a single logistics unit to reduce freight costs and simplify documentation.

 
---

 In high-volume distribution, treating every Customer Order as a separate shipment is a recipe for inefficiency. IFS Cloud’s **Consolidated Shipment** functionality allows you to decouple the "Sales" transaction from the "Logistics" execution, merging multiple orders into a single physical dispatch.

 ## The Logic: Decoupling Sales from Shipping

 Traditionally, 1 Order equals 1 Delivery. With Consolidated Shipments, the hierarchy changes. You gather multiple orders going to the same delivery address and process them as a single work package.

 
### The Operational Workflow

 1

 
##### Connect to Shipment

 Instead of releasing an order to "Pick," you connect multiple Customer Order Lines to a single **Shipment ID**.

 2

 
##### Consolidated Pick

 The warehouse receives a single Pick List (aggregated by location) rather than five separate lists for five orders.

 3

 
##### Pack into Structure

 Using **Handling Units** (HUs), you pack items from different orders onto the same Pallet (Parent HU).

 4

 
##### Single Dispatch

 You execute the "Complete" command once. This triggers the printing of one Bill of Lading (BoL) and one Consolidated Delivery Note.

 
## Handling Units: The Enabler

 Consolidation is impossible to manage effectively without **Handling Units**. In IFS Cloud, HUs allow you to define the physical structure (e.g., Box A and Box B go onto Pallet X).

 **Pro Tip:** Use "Automatic Packing" rules in IFS to let the system propose how to pack consolidated items based on volume and weight constraints.

 ### Why Consolidate?

 
- **Lower Freight Costs:** Pay for one LTL shipment instead of 5 small parcels.
- **Less Paperwork:** Single Bill of Lading and CMR.
- **Dock Efficiency:** One truck, one loading time.

 Configuration Check

 Before starting, ensure:

 
- Shipment Management enabled in Site settings.
- Handling Unit Types defined (Pallet, Euro-Pallet, Box).
- "Shipment Creation" set to Optional or Automatic on Customer record.

 ## Consolidation FAQs

 ## 

 Generally, a **Shipment** in IFS Cloud is tied to a single delivery address (one customer). To group goods for *different* customers onto one truck, you should use the **"Consolidated Load"** (Load Management) functionality, which sits a layer above the Shipment.

 ## 

 You have a choice. You can either print a separate Delivery Note for each Customer Order contained in the shipment, or configure a **Consolidated Delivery Note** that lists all items from all orders on a single document.

 ## 

 Yes, as long as the Shipment Status is not yet "Completed" or "Closed." You can connect a new order line, pick it, and add it to the existing Handling Unit structure before final dispatch.


[Read more...](https://www.ifs-erp.com/blog/consolidated-shipments-in-ifs-cloud.md)

## A Data-First Approach to IFS Cloud Implementation

![A Data-First Approach to IFS Cloud Implementation](https://www.ifs-erp.com/images/ApproachSmall.png)

Implementation Strategy & Methodology

 
## Data-First Implementation Strategy

 > "ERP doesn't fix broken processes; it exposes them."
> 
>  Category: Digital Transformation | Methodology

 This maxim is the reality for every Project Manager and CIO approaching a Go-Live. When you migrate to a modern, integrated platform like **IFS Cloud**, you are not just upgrading software; you are turning on a massive spotlight.

 Every inconsistent workflow, every "tribal" workaround, and every gap in your master data will suddenly become visible and operational. To ensure this exposure leads to optimization rather than paralysis, organizations must adopt a **Data-First Implementation Strategy**.

  ## The Solution Blueprint

  ### 1. Scoping: Define the "Active" Reality

 ##### The Trap

 Migrating 15 years of historical data "just in case" ensures that obsolete parts and inactive suppliers clog up your search results.

 ##### The Fix

 **Strict Data Segregation.** Use the IFS Data Migration Manager to profile your source data early. Define strict rules for "Active" data (e.g., 24-month activity) to reduce system noise.

  ### 2. Sanitation: The Pre-Migration Cleanse

 ##### The Trap

 "We will clean the data after we load it into IFS Cloud." This delay pushes critical process decisions into the high-risk UAT phase.

 ##### The Fix

 **Source-Level Standardization.** Data gaps are process gaps in disguise. Force the business to fill missing IDs and terms *before* extraction occurs.

  ### 3. Alignment: Harmonizing Process with Logic

 ##### The Trap

 Customizing IFS Cloud to mimic legacy bad habits or relying on "Tribal Knowledge" (e.g., "Bob knows to check the label manually").

 ##### The Fix

 **Adopt Standard IFS Logic.** Map tribal knowledge to IFS Basic Data. Convert informal human dependencies into robust system configurations.

  ### 4. Validation: The "Mock" Reality Check

 ##### The Trap

 Testing with "Perfect" hand-picked sample data. This proves the software works, but fails to prove the business can actually run.

 ##### The Fix

 **Iterative Full-Volume Loads.** Test with the messy reality of actual volume. Run E2E flows on migrated data to identify tax code or posting mismatches early.

  ### 5. Discipline: The Cutover Mindset

 Treating Go-Live as the finish line is a mistake. When the system goes live, the "Spotlight" is permanent. Establish a Master Data Management (MDM) board to prevent process entropy from returning.

  ## Frequently Asked Questions

 Why shouldn't we migrate all historical data to IFS Cloud? Migrating deep history (e.g., 10 years of closed orders) clutters the production environment, slows down system performance, and complicates future upgrades. The best practice is to migrate "Open Balances" (active data) and archive historical data in a low-cost Data Lake or BI repository.

    What is the biggest risk during data migration? The biggest risk is "Data Validation Latency"—finding out data is bad only *after* it has been loaded. If a Part Class is missing, the system may block thousands of transactions at once. This is why pre-migration cleansing in the source system is critical.

    Should we customize IFS Cloud to match our old process? Generally, no. Your old process was likely designed around the limitations of your old system. It is almost always better to adapt your business process to the standard logic of IFS Cloud ("Adopt vs. Adapt") to lower long-term maintenance costs and ensure seamless "Evergreen" updates.


[Read more...](https://www.ifs-erp.com/blog/the-process-honesty-check.md)

## New Purchasing Functionality in IFS Cloud 25R2

![New Purchasing Functionality in IFS Cloud 25R2](https://www.ifs-erp.com/images/article_p.png)

Release Analysis | IFS Cloud 25R2 
## IFS Cloud 25R2: Stop Transactional Buying or Get Left Behind

 The 25R2 update isn't just a patch; it's a declaration of war on manual procurement. If you are still clicking "Approve" on routine POs, you are wasting company capital.

 ## The Problem This Article Solves

 Procurement departments are drowning in administrative noise, failing CSRD (Corporate Sustainability Reporting Directive) audits, and breaking their ERP during updates due to heavy modifications. This guide details how to use 25R2 to automate the mundane, satisfy regulators, and maintain a **Clean Core**.

 
---

 ### TL;DR: The Meat

 
- • **Dark Purchasing:** Zero-touch PO processing for routine stock.
- • **ESG Enforcement:** Hard-blocking non-compliant suppliers at the PO line level.
- • **Clean Core:** Replacing PL/SQL hacks with Command Extensions and OData.

 {toc} ## Dark Purchasing: The End of Manual Requisitioning

 Most procurement teams spend 80% of their time on 20% of the value. IFS Cloud 25R2 aims to kill this inefficiency. The concept of "Dark Purchasing" isn't about lack of transparency; it's about the system operating autonomously in the background.

 
> "If your buyers are manually reviewing every low-value requisition in 2026, your ERP implementation has failed. 25R2 is the correction."

 
### Predictive Requisitioning vs. Legacy Min/Max

 Min/Max is a 1980s solution for a 2026 supply chain. In 25R2, Demand Sensing analyzes consumption velocity and lead-time volatility. It doesn't wait for a stockout; it calculates the **Risk of Stockout**.

 The system now generates **Proposed Purchase Orders** based on probabilistic outcomes. This means the system "senses" a strike at a port or a seasonal spike and adjusts the requisition before the buyer even opens their Lobby.

 ![IFS Cloud 25R2 Procurement Lobby displaying predictive demand sensing and automated PO status](https://www.ifs-erp.com/images/blog/ifs-cloud-25r2-procurement-lobby.webp)

 
## ESG and CSRD: No Longer a "Nice to Have"

 The EU’s Corporate Sustainability Reporting Directive is a legal minefield. In previous versions, sustainability was a custom field or a note. In 25R2, it is a hard constraint.

 You can now define Green Procurement parameters. If a supplier’s carbon footprint exceeds the threshold or their ESG certificate is expired, the system doesn't just "warn"—it **blocks** the transaction. This is true compliance: moving the check from the audit report to the point of purchase.

 
## The Integrator's Reality: Decoupling the Mess

 Stop modifying the base code. Every time you touch `Purchase_Order_API`, you create a technical debt that will haunt you during the next "Evergreen" update.

 
### Command Extensions over PL/SQL

 25R2 introduces more robust **Command Extensions** within the Page Designer. If you need to validate a PO against an external legal database, do not write a trigger. Use an OData call to trigger a workflow in **n8n** or another middleware. This keeps your core "Clean" and your updates painless.

 #### Why "Clean Core" is Mandatory for 25R2

 The update window for 25R2 is aggressive. Organizations with heavy **CRIMs** (Configurations, Reports, Integrations, Modifications) will find themselves stuck on legacy versions, missing out on AI demand sensing features. Migration is no longer a project; it is a continuous state of readiness.

 ### 25R2 Audit Checklist

 
- Audit all custom PL/SQL events on `PURCHASE_ORDER_TAB`.
- Verify **Sustainability Manager** permission sets.
- Check "Lobby" data sources for deprecated views (v1 vs v2).
- Map existing Supplier Categories to new ESG criteria.

 Strategic Entities

 **CRIMS:** Configuration, Report, Integration, Modification, Extension. The enemy of the 25R2 update.

 **Aurena:** The native web interface where all new 25R2 features reside. Legacy IEE users will miss 100% of these updates.

 #### Expert Tip

 Enable **Supplier Self-Service**. Stop acting as a data entry clerk for your suppliers. Let them upload their own ESG certificates into the portal and let the system validate them.

 ## Procurement Excellence in 25R2: FAQ

 ### 

 It provides a centralized governance framework to track Scope 3 emissions. By integrating this directly into the Procurement module, IFS Cloud 25R2 allows for real-time blocking of non-compliant vendors, ensuring you meet CSRD legal requirements before the transaction occurs.

 ### 

 No. It shifts the oversight from the "transaction" to the "exception." Humans define the rules and thresholds. The system executes the routine. If a PO exceeds a budget or falls outside of a contract, it is flagged for manual intervention. This is strategic resource allocation.

 ### 

 You must perform a **CRIM analysis**. Any modification that directly touches base tables should be evaluated for replacement with "Command Extensions" or "Workflow Designer" automation. This ensures your system remains "Update-Safe" in the Evergreen lifecycle.

  

 {semanticux}


[Read more...](https://www.ifs-erp.com/blog/new-purchasing-functionality-in-ifs-cloud-25r2.md)

## The Silent Killers of IFS Cloud Data Migration

![The Silent Killers of IFS Cloud Data Migration](https://www.ifs-erp.com/images/article_m.png)

## IFS Cloud Data Migration Strategy

 Secure, compliant, and efficient transition from legacy systems to the Evergreen cloud.

 
---

 Data migration is frequently the highest-risk workstream in any ERP project. Moving to IFS Cloud is not merely a technical "lift and shift" of files; it is a complex surgical operation requiring precise mapping, rigorous cleansing, and strict adherence to regulatory standards. A successful migration is the foundation of a stable go-live.

 ## The Core Challenge: "Garbage In, Disaster Out"

 The primary cause of migration failure isn't technical connectivity; it's **data quality**. Legacy systems, often running for decades, contain duplicates, obsolete SKUs, and incomplete customer records. Migrating this "noise" into IFS Cloud cripples the new system's efficiency and corrupts AI/ML forecasting models from day one.

 
### Strategic Migration Pillars

  

 
#### 1. The Layered Methodology (ETL)

 We never migrate everything at once. We utilize a phased Extraction, Transformation, and Loading (ETL) strategy:

 
- **Layer 1 - Master Data (Static):** Customers, Suppliers, Parts, Accounts. (High validation requirement).
- **Layer 2 - Open Balances (Dynamic):** Inventory on-hand, open AP/AR, open orders. (Time-critical).
- **Layer 3 - History (Optional):** Closed transactions for reporting. Often best archived in a Data Lake rather than the live ERP.

  

 
#### 2. Regional Compliance & Data Residency

 Migration is a compliance event. For businesses operating in the EEA, handling Personally Identifiable Information (PII) during transition requires strict adherence to **GDPR**. We ensure that data staging areas respect regional data residency laws and that obsolete personal data is purged, not migrated.

 ### The "Clean Slate" Opportunity

 Do not recreate legacy mistakes in a modern tool. Use migration as the catalyst to standardize Units of Measure, rationalize the Chart of Accounts, and clean up your supplier vendor master. This proves higher ROI than simply moving existing chaos faster.

 #### The Cutover Weekend Risk

 The "Go-Live" window is finite. If the dynamic data load (Layer 2) takes 48 hours but the business only has a 24-hour weekend window, the project fails. We conduct multiple "mock migrations" to accurately time the loading process and optimize scripts for speed.

 Readiness Checklist

 
- Data Owners assigned per business area.
- Cleansing rules defined and signed off.
- Legacy system freeze date established.
- Staging environment secured (GDPR compliant).

 [IFS Cloud Data Migration Checklist (2026 Edition)](https://www.ifs-erp.com/index.php?option=com_content&view=article&id=28&catid=15&lang=en-GB)

 ## Data Migration FAQs

 ## 

 Generally, no. Migrating deep transactional history into the live production environment is expensive, slows down system performance, and complicates future upgrades. Best practice is usually to migrate "Open Balances" (active data) and archive historical data in a separate, lower-cost Data Lake or reporting repository accessible via BI tools.

 ## 

 We utilize a combination of tools depending on complexity. The primary native tool is the **IFS Migration Cockpit** (Data Migration Manager) for standardized loads. For complex transformations from non-IFS legacy systems, we often use intermediary staging databases (SQL Server/Oracle) and ETL scripts before injecting clean data into IFS Cloud via REST APIs or migration jobs.

 ## 

 Security during migration is paramount, especially regarding local regulations like GDPR in Europe. We ensure staging environments are as secure as production, access is restricted on a need-to-know basis, and sensitive PII data is often anonymized or masked during testing phases until the final production cutover.


[Read more...](https://www.ifs-erp.com/blog/ifs-cloud-data-migration.md)