IFS Cloud Shipment Order: Move Stock Between Sites
Independent IFS Cloud practice · Supply Chain How a Shipment Order moves stock between sites and remote warehouses without a trade order An IFS Cloud shipment…
Read moreSelect your language
Select your language
Independent IFS Cloud practice · Supply Chain How a Shipment Order moves stock between sites and remote warehouses without a trade order An IFS Cloud shipment…
Read moreIndependent IFS Cloud practice · Customization Why IFS Cloud dialogs and assistants refuse a Custom Field, and what to build instead IFS Cloud custom fields on…
Read moreIndependent IFS Cloud practice · Security An IFS Cloud user access review that leaves an evidence trail an auditor can follow, and your team can repeat Key…
Read moreIndependent IFS Cloud practice · Sales The price that expires while orders keep asking for it Customer price agreements in IFS Cloud sit on dated lines: sales…
Read moreIndependent IFS Cloud practice · Supply Chain What your ERP consultant did not tell you: the process will drift Key takeaways Go-live delivers a documented,…
Read moreIndependent IFS Cloud practice · Supply Chain Three order states that should never sit unquestioned. One of them, nobody owns. Key takeaways Released without…
Read moreIndependent IFS Cloud practice · Supply Chain The single point of failure wearing a friendly face: how to make the check survive the person Key takeaways Most…
Read moreIndependent IFS Cloud practice · Supply Chain When IFS trusts you too much: the hidden cost of overrides without guardrails Key takeaways IFS will let you…
Read moreIndependent IFS Cloud practice · Supply Chain The cost of looking: what manual order monitoring really costs in IFS Cloud Key takeaways A buyer spending two…
Read more
Independent IFS Cloud practice · Supply Chain
An IFS Cloud shipment order moves goods between sites and remote warehouses of one company through the normal shipment and receipt process, with no sales parts, purchase parts or internal customers behind it. Use it when the move needs a hand-over, a transit step and a receipt; use a transport task when the goods stay inside the building.
Key takeaways
Moving stock from one site to another looks like one action, but IFS Cloud has three tools for it, and the wrong choice shows up later as missing material or as master data nobody wanted. The trade-based tool is covered in Mastering Distribution Orders in IFS Cloud. This article covers the other one, the shipment order, and the point where its goods can disappear: the gap between delivery and receipt. Every product statement below comes from IFS documentation pages or community threads that I opened, and I mark which is which.
A shipment order is an IFS Cloud order that requires and carries out an internal goods movement between sites and remote warehouses in the same company. The 25R2 documentation page About Shipment Order lists four scenarios: site to site, site to remote warehouse, remote warehouse to site and remote warehouse to remote warehouse. It also notes that a move involving a remote warehouse can be intra-site or inter-site.
Execution runs through the shipment and receipt processes. The page states that shipment orders are supported for inventory parts, no parts and non-inventory parts, and that manual creation of a non-inventory part is not handled. For no parts and non-inventory parts the move starts from the receipt, and the delivery and receipt record no inventory transactions. A community thread titled with 21R1 describes the shipment order as introduced in that release, so a system on an older release will not have it.
A remote warehouse is, per the 25R2 Remote Warehouse page, a warehouse that is not strictly related to the site geographically and has a different address from the central warehouse. Typical uses named there are a moving warehouse such as a service van, and a warehouse at another address that still belongs to the site. The same page adds that such a warehouse can be temporary and related to a customer or a specific project.
A shipment order has a header and lines, and both carry one of five statuses: Planned, Released, In Progress, Closed or Cancelled. The order starts as Planned, becomes Released when you release it for execution, turns In Progress while the shipment runs, and ends Closed once everything is received into stock.
The second way to start is from stock. The documentation describes initiating the move for parts or handling units that already sit in stock, which adds them to a new shipment order as reserved. This works for material in picking, arrival or QA locations. When the move starts from an arrival or QA location, the purchase order receipt is recorded on the line, the selected quantity leaves that receipt, and it returns to the receipt in the new location once the shipment order is received. That is useful when goods arrive at one address and the final receipt must happen at another.
A released shipment order connects to a new or existing shipment, and from then on the outbound process is the standard one: reserve, create pick list, pick, pack into handling units, deliver, print the delivery note and send dispatch advice. The connection happens automatically at release, through a command on the overview page, or by hand from the available lines on a shipment; the first two follow the rules of the shipment type. If you work with the outbound side regularly, see Advanced Picking Strategies in IFS Cloud and Understanding Consolidated Shipments.
For inventory parts, the material is under transportation at delivery and can be tracked. The documentation lists what is visible in transit: part number, lot or batch, serial and quantity, the sending and receiving site or remote warehouse, the handling units the parts are packed into, and the ownership type, owner and owner name. It adds that this is the same internal order transit handling used for multi-site orders.
On arrival the inbound receipt process takes over: register arrival, receive an incoming dispatch advice as parts or handling units, manage receipt in arrival or QA, and move into stock through putaway.
Delivery and receipt write paired inventory transactions. The 25R2 page names these:
SHIPODWHS- on delivery to a warehouse and SHIPODWHS+ on receipt from a warehouse.SHIPODSIT- on delivery and SHIPODSIT+ on receipt, plus an INTORDTR transaction at delivery.UND-SHPODW within a site, UND-SHPODS between sites, and UNINTORDTR in the inter-site case.Those codes come from the documentation page, not from a system I tested, so confirm them in your own release before you build a report or a filter on them.
One setting removes the gap altogether. If a shipment type has Automatic Receipt enabled, running Delivery on the shipment also triggers a receipt and closes the shipment order. For a remote warehouse this needs the Default Receive Case for the inventory part with a matching default location, and the message class DESADV set up at company level, because dispatch advice carries the transfer. The documentation gives a pickup for a remote warehouse van as the example.
A shipment order is a required goods movement, so planning treats it as both demand and supply. According to the documentation, the demand quantity is the order quantity minus the shipped quantity, due on the planned due date. The supply quantity is the order quantity minus the arrived quantity, due on the planned receipt date. Goods that arrived and wait in arrival or QA count as supply with the lead times in arrival or QA applied.
The same order can therefore appear as supply and as demand when it moves inside one site, with different dates because a lead time sits between them. These elements are considered in the inventory part availability planning tabs and in the availability check of a shipment order, as well as in order proposals, MRP and master scheduling. The documentation also notes that a shipment order can be a demand and supply before the stock exists, unlike a transport task.
A remote warehouse can be made not nettable by giving it a default part availability control ID that is not nettable. The material is then dedicated to that warehouse and is not supply or demand outside it. The documentation gives a service van with material dedicated to coming jobs as the example. For multi-site planning context, see Architecting Intelligent Distributed Fulfilment.
The three tools differ in whether a shipment and receipt step exists, whether stock must already be on hand, and what master data they need. The table below uses only statements from the 25R2 pages About Shipment Order, Distribution Orders and Create Transport Task.
| Question | Transport task | Shipment Order | Distribution Order |
|---|---|---|---|
| Intended use | Internal stock movement within the four walls of the building | Internal goods movement between sites and remote warehouses of one company | Internal trade between sites, with internal customers and suppliers |
| Shipment and receipt process | No hand-over, transit or receipt step | Yes, executed through the shipment and receipt processes | Yes, through the customer order and purchase order it creates at release |
| Stock must exist when you ask for the move | Yes, no way to require material in advance | No, it counts as supply and demand before the stock is there | No, a planned order shows as demand on one site and supply on the other |
| Remote warehouses | A move between sites and remote warehouses is possible, but the page recommends it for movement inside the building | Supported in all four directions | Cannot handle goods movement with remote warehouses |
| Master data for internal trade | Part and user must exist on the other site for a cross-site move | No sales parts, purchase parts, customers or suppliers needed | Internal customer and supplier, sales part and purchase part (created automatically at release if missing) |
| Between companies | Not covered on the page I read | No, one company only | Supply and demand site can be in the same or different companies |
The Shipment Order page also lists what it does not handle: consignment stock or supplier-owned parts, manual creation of non-inventory parts, and goods movement between companies. If you need the last one, the distribution order is the documented route. The mechanics of that route are in the sibling article on distribution orders.
Two IFS Community threads describe two set-up problems. They are single reports from specific releases, so treat them as a prompt to test, not as a permanent rule.
The fix in both cases sits in master data, not in the order. That is worth checking before go-live, because the symptom appears at the moment someone has a truck waiting.
Goods that were delivered on a shipment order and never received are an operational exception: they left the sending location, they are in the internal order transit, and they are available in no location. The documentation gives you the signals. The order stays In Progress until everything is received, the supply element carries a planned receipt date, and the transit view shows what is still under transportation with its sender and receiver.
A person can look at that view every morning. The same check can run as a scheduled read of those records against the planned receipt date, with the late ones sent to the people who can chase the carrier or the receiving dock. That is how exception monitoring works in general: the data already exists in IFS, and the job is to read it on a schedule and tell the right person before the planner notices the gap on a stock list. Which projection exposes the transit and shipment order records in your release is something to confirm before building any such check.
The SCM Automation Pack is built on that principle: a scheduled, read-only read of IFS data over OData that turns exceptions into alerts. I am not claiming a ready-made check for goods in transit; whether it fits your estate is a scoping question for a call. Nothing is installed in your IFS, so a release update leaves nothing of ours for you to retest; compatibility with a new release is checked on our side under the subscription.
Book a 30-min call See the SCM Automation Pack
For the wider view of working with sites, see Multi-Site IFS Cloud Implementation and Flexible Reservations on the consulting site.
A Shipment Order in IFS Cloud requires and carries out an internal goods movement between sites and remote warehouses of the same company. Use it when the move needs a shipment and a receipt, for example from a central warehouse to a service van, and you do not want to create sales parts, purchase parts, customers or suppliers just to represent an internal trade.
A transport task moves stock that is already available, mainly inside one building, with no shipment and receipt step. A Shipment Order moves goods between sites and remote warehouses of one company through the shipment and receipt processes. A distribution order handles internal trade between sites with internal customers and suppliers, and per the 25R2 documentation it cannot handle remote warehouses.
No. The 25R2 About Shipment Order page states that the shipment order does not support goods movement between companies. A distribution order, by contrast, can have the supply site and the demand site in the same or different companies, so it is the documented route for that case.
In a community thread tagged 23R2, the receipt list of values for a shipment order did not offer remote warehouses as a receiving location, and the reply marked as the best answer says the receiver of the shipment order, a site or a remote warehouse, is the address where the goods must be received. If the receiver on the order is the site, receive at the site. If the goods belong in a remote warehouse, make that remote warehouse the receiver on the order.
After a shipment order for inventory parts is delivered, the goods are visible in the internal order transit with part, lot or serial, quantity, sender, receiver and the handling units they are packed in. The shipment order stays In Progress until everything is received into stock, so lines delivered but not closed are the ones to review.
Yes. A shipment order counts as demand until it is shipped and as supply until it arrives, and the documentation names availability planning, the availability check, order proposals and MRP among the places that consider it. A remote warehouse with a not nettable default part availability control is the exception: its material is dedicated to that warehouse.
Documentation was read in the 25R2 edition. Behaviour can change between releases, so check the pages for the release you run. Community replies are individual users' answers, not IFS documentation.
Dariusz Myśliwiec: 18 years hands-on with IFS, today on 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 from my IFS work: 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.
Bring me the move you need to run and the sites or remote warehouses involved. On a 30-minute call I will tell you which of the three tools fits, which master data to check first, and how to watch for goods delivered but never received.
Independent IFS Cloud practice · Customization
IFS Cloud custom fields on a dialog or an assistant hit a framework limit. For assistants the Known Limitations page of the Tailoring guide states it in the 24R1 and 25R1 editions; for dialogs it comes from an IFS employee in a 2026 community thread, so the workaround depends on which of the two you face.
Key takeaways
In March 2026 a customer on IFS Cloud 25R1 asked on the IFS Community why the "Receive Shop Order Manually" view would not accept a custom field. The asker notes the view is implemented as a Dialog, and the question touches a recurring pattern: a business needs one more piece of information captured at exactly the step where users already work, and that step is a dialog or an assistant. This article separates what IFS documents from what one forum reply says, then gives a decision table you can use before anyone starts building.
The Known Limitations page in the IFS Cloud Tailoring guide contains a section called "Custom Attributes on Assistants". I opened it in the 24R1 and 25R1 documentation, and both versions carry the same text. The section contrasts ordinary application pages, where a user searches for data, updates or adds information and then explicitly saves, with assistants, which "provide flexible implementation to suit the task at hand". It concludes that "it is not currently possible to provide custom attributes on assistants."
The same page does not mention dialogs. That gap matters, because "Custom Field" in daily speech covers both the Custom Attributes framework and the fields users see on screen, and the documented statement is narrower than the problem people report. For dialogs, the evidence I could open is the community thread described below.
The Page Designer introduction in the 25R1 Tailoring guide adds one relevant point. It lists configuring steps in assistants among the things Page Designer does, and it notes that dialogs and assistants have limited configuration possibilities compared to regular pages. Neither statement promises a way to add a new field to them.
The thread "Missing CUSTOM Functions in Dialog and Assistant Views in IFS Cloud" has one question and two replies, all dated 12 to 17 March 2026, tagged to 25R1 and marked solved. Treat each reply for what it is: a person answering on a forum, not a documentation page.
A second thread supports the assistant side. In a March 2025 thread on 24R2, an IFS employee says most Page Designer configuration works in assistants, such as conditional visibility, editability and required status, and that only adding Custom Fields to an assistant is unsupported. Another IFS employee in the same thread says a BPA Workflow of the process enrichment type should be able to populate default values.
The thread and the documentation give six approaches. Numbers 1, 3 and 4 have a documented basis in the IFS Cloud Tailoring or Administration guides. Numbers 2, 5 and 6 rest on forum replies, and I label them that way.
?showInPageDesigner=true to the dialog address to open Page Designer on it, and adds that this will not create custom fields. I found that parameter only in the thread, so test it before you rely on it.I describe each of these as "a reply in the thread says" where that is the only source. Where the Tailoring or Administration guide covers it, I cite the guide.
The upkeep and update-risk columns are my own assessment from practice, not an IFS rating. Treat them as a starting point for a conversation about your estate.
| Your need | Workaround | Upkeep | Risk at a release update | Basis |
|---|---|---|---|---|
| Relabel, hide or make mandatory an existing field in the dialog or assistant | Page Designer configuration | Low | Low: re-check the configuration after each release | Documented for pages and assistant steps; the dialog address parameter is thread-only |
| Pre-fill a value in an assistant | Conditional Default Values or BPA process enrichment | Low to medium | Low to medium | Thread replies by IFS staff |
| Validate, alert or start a workflow after the dialog saves | Custom Defined Event on the entity | Medium | Medium: conditions depend on entity columns that can change | Feature documented (Administration guide); dialog use suggested by an IFS employee in the thread |
| Record extra data about the shop order, receipt or similar record | Custom Entity listed on the parent page | Medium | Low to medium | Documented (Tailoring guide) |
| Capture extra data in the same step the user performs today | Custom page on the extended entity, replacing the dialog | High | Medium: you now own the user flow and its authorisations | Thread suggestion by an IFS employee |
| Logic or fields that no configuration can express | Projection customization with fragments | High | High: code to retest at every release | Thread, customer opinion |
Work down the table from the top and stop at the first row that meets the need. The further down you go, the more of the solution is yours to maintain, which is the same reasoning behind choosing between Quick Reports, Custom Fields and Custom Events.
Clean Core means the standard IFS objects stay unchanged and every change lives in the Extensibility Framework, where a release update can carry it forward. The limit on dialogs and assistants pushes teams toward one of two bad habits: a modification of the standard view, or a pile of undocumented events nobody owns. Both are avoidable with the table above.
For the wider strategy on the consulting site, see The Clean Core and Strategic IFS Cloud Customization.
CRIMS stands for Configurations, Reports, Interfaces and Modifications: the customer-specific objects added on top of standard IFS Cloud. The marketplace on this site has a Modifications category, which states that its items are vetted for maintainability and "evergreen" compatibility with IFS Cloud updates. That is the category's own description, and it does not say how an individual item is tested.
Whether a ready-made CRIMS Modification fits your requirement, or the work is scoped as a build using the decision table, I check the proposed approach against the limits above before anything is configured, so you do not end up with a field that the framework cannot host.
No. The Known Limitations page of the IFS Cloud Tailoring guide, in the 24R1 and 25R1 documentation, states that it is not currently possible to provide custom attributes on assistants. Other Page Designer configuration, such as conditional visibility and required status, still applies to assistants.
An IFS employee reply in a March 2026 community thread on 25R1 says it is not possible with standard Custom Fields, because dialogs do not follow the patterns the Custom Attributes framework requires. The Known Limitations page I checked names assistants and does not mention dialogs, so verify the current position for your release before designing around it.
Keep the dialog untouched and put the data next to it. A Custom Entity listed on the parent standard page stores extra data, and a Custom Defined Event on the underlying entity can react when the dialog changes data. Both live in the Extensibility Framework, so the core stays unchanged and a release update has less to disturb.
No. A customer reply in the IFS Community thread says adding ?showInPageDesigner=true to a dialog address may open Page Designer so you can change the visibility or behaviour of existing fields, and states that it will not add custom fields. I found the parameter only in that thread and not in the IFS documentation, so test it in a non-production environment first.
A Custom Defined Event can react to data changes, but it cannot show a new input in the dialog. The 25R1 Administration guide describes events that fire when a row is created, updated or removed and run an action such as E-Mail, Task, Workflow or REST Call. Use an event for validation and follow-up, and a Custom Entity or custom page when users need to type something new.
Documentation was read in the editions named above. Limits can change between releases, so check the Known Limitations page for the release you run.
Dariusz Myśliwiec: 18 years hands-on with IFS, today on 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 from my IFS work: 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.
Bring me the dialog or assistant and the data you need to capture. On a 30-minute call I will tell you which row of the table fits, whether a CRIMS Modification already covers it, and what the rest would cost to build and keep.
Independent IFS Cloud practice · Security
Key takeaways
A user access review in IFS Cloud is a periodic comparison between the permission sets each user holds and the access that person’s job needs, confirmed by the owner of the role and recorded as evidence. Without that record, the same finding returns at every audit: someone left in March and could still post journals in June, and nobody can show who last looked.
One complete review covers preparation, five steps, the accounts people forget, the findings and the auditor’s evidence.
Access in IFS Cloud comes from permission sets granted to users, so a review is a check of those grants against current need. It answers one question per person: does this individual still require every set they hold?
Design decides which permission sets exist and which combinations are allowed. A review tests whether reality still matches that design. If your sets are badly cut, a review will only expose the damage, so fix the model first with permission set design in IFS Cloud and the conflict matrix in RBAC and Segregation of Duties in IFS Cloud. This article does not repeat either.
ISO/IEC 27001:2022 Annex A control 5.18, “Access rights”, covers the whole life of an access right: provision, review, modification and removal. The control requires that rights are reviewed, and it gives no number of days or months. The interval is your decision, written into your access policy and then followed. The standard itself is listed on the ISO catalogue page for ISO/IEC 27001.
A review stalls when one of its inputs is missing on the day the owners are asked to decide. Gather these first:
One review needs five steps in a fixed order, because each step produces the document the next one consumes.
| Step | Who | Evidence it leaves |
|---|---|---|
| Scope and snapshot | IT or security manager with the IFS administrator | Dated export of users and permission sets |
| Match to HR list | IT with HR | List of unmatched accounts with explanations |
| Owner decisions | Role owners | Keep, reduce or remove marked on each line |
| Execute changes | IT | Change tickets referenced in the file |
| Close | IT or security manager | Signed and dated summary filed with the above |
Asking IT to approve access it granted itself turns the review into a formality, which is why step 3 sits with the business and step 4 with IT.
A leaver keeps access until someone disables the account, and that someone is only told if HR and IT have a working hand-over. A mover is harder: the accountant who joins purchasing takes on new permission sets and keeps the old ones, since nobody is assigned to remove them. Joiners create the third gap. Say a manager asks for “the same access as Anna”: the new account inherits everything Anna has accumulated over the years, including sets she should have lost after her own move. Compare each new account with the role catalogue, not with a colleague.
A service account is a login used by software, so no person sits behind it to notice a surplus right. It needs a named owner, a written reason, and the smallest permission set the integration can work with. A monitoring or reporting integration should hold read access only, one account per integration, so that revoking one cannot break another. This is also how the read-only account for the OData monitoring approach is set up, and it is the account model behind the SCM Automation Pack, which reads IFS and writes nothing into it.
An administrator account can grant itself anything, so a mistake in its sets costs more than an error on a clerk’s login. Review these more often than ordinary users. Quarterly is a sensible working practice for privileged accounts against an annual cycle for everyone else, though that is a choice to write into your policy, not a requirement of the standard.
Every finding ends in one of three outcomes: the access is removed, reduced to a narrower permission set, or kept as a documented exception. Removal and reduction run through a change ticket so the action can be traced.
An exception is for the case where a conflict in duties cannot be removed. A small team may need one person to create suppliers and approve their invoices, for example. The exception then carries a compensating control, such as a second person approving those invoices, plus a named owner and a date on which it is looked at again. An exception with no review date is a permanent grant under a different name. Conflicts that appear repeatedly point at the role design, and the matrix in the RBAC and SoD article is where to resolve them.
An auditor wants proof that the review happened as your policy describes, and will sample it. The file should let them follow one user from the snapshot to the final outcome without asking anyone for help:
Whether the control meets a standard is for the auditor or certification body to judge. A consultant can prepare the role model and the procedure; the evidence comes from your own review.
The first review is slow because roles are undocumented and owners are unnamed. Once permission sets map to documented roles, each with an owner, the next review shrinks to confirming a list that is mostly unchanged. The effort moves from discovery to a short decision round.
A repeatable procedure also removes the dependency on whoever ran the last one. If the steps, templates and evidence format are written down, your own finance or IT team can run the review without outside help. That is the outcome of the IFS Cloud Security and SoD service: a role model plus an access review procedure your team repeats unaided.
Book a 30-minute technical call See the Security and SoD service
The interval is set by your own access policy, because ISO/IEC 27001:2022 control A.5.18 requires reviews but names no frequency. One workable arrangement is an annual review of ordinary users and a quarterly one for administrator and other privileged accounts, with an extra check whenever someone changes role.
The business owner of the role approves, and IT carries out the resulting changes. The owner knows what the job requires, whereas IT knows only what was requested. Separating the two also prevents the team that grants access from certifying its own work.
An IFS administrator exports the users with the permission sets granted to each, using the security administration features of your IFS Cloud release. Save the export with its date as the review snapshot. The screen names differ between releases, so confirm the route on your own version before the first review.
An auditor expects the access policy, the scope, the dated list of users and permission sets, the owner’s decision for each line with name and date, and the change ticket for every removal. Documented exceptions with compensating controls and review dates complete the file.
Yes, an IFS access review includes service and integration accounts, since software logins hold permission sets like any user. Each needs a named owner, a recorded reason and the smallest permission set that works. An integration that only reads data should hold read-only access.
Dariusz Myśliwiec: 18 years hands-on with 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 the role model, not a sales layer.
Selected clients across my IFS work: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
If you have been asked to review user access in IFS Cloud and are unsure where the scope should end, bring your current permission sets to a 30-minute technical call. There is no sales pitch; you talk to the consultant who writes the procedure.
Independent IFS Cloud practice · Supply Chain
Key takeaways
Every distributor has one. The buyer who checks unconfirmed purchase orders every Monday morning before the rest of the team is at their desk. The planner who knows, without checking a report, which two suppliers go quiet after they accept an order. The person who can glance at an open-order list and tell you which lines are fine and which ones are quietly not moving. None of that is written down anywhere. It lives in their head, in a personal spreadsheet, in a habit built over years of getting burned. Then they take two weeks of leave, or move teams, or leave the company outright, and the check simply stops happening. Nobody decided to stop it. Nobody was told to cover it. It just was not there, and the first sign is a stalled line, not a missed task. Here is why the check ends up owned by one person, what that exposure actually costs, how to spot it before it bites, and how to make the coverage survive the person who invented it.
It never gets assigned on purpose. Someone gets burned by a supplier who went quiet after accepting an order, so they start checking every Monday. It works, so it becomes their habit, then their reputation, then the thing everyone assumes is handled because “that’s just what they do.” Nobody writes a procedure for it, because there was never a moment that needed one. It grew organically, out of one competent person closing a gap the system itself does not close.
The trouble is that competence looks identical to resilience until the person is not there. A habit is not documentation. A personal spreadsheet is not a system of record. And a check performed from memory has exactly one point of failure: the memory. The same pattern shows up wherever a system leaves a gap between a record changing and someone noticing it: unconfirmed orders, silent suppliers, stock drifting toward a shortage. One person quietly plugs the gap, and the organisation never has to think about it again, until the day that person is unavailable.
The cost does not show up as a line item labelled “coverage gap.” It shows up two or three weeks later, wearing a different name entirely:
The real cost is not the two weeks of leave. It is that the organisation never finds out how exposed it was until the exact week it could least afford to.
Start by asking a blunt question about any recurring check that matters: if the person who does it were unreachable for two weeks starting tomorrow, would anyone else know it needed doing, know how to do it, and know who to tell? For most supply chain teams, the honest answer is no for at least one check: usually unconfirmed purchase orders, sometimes supplier confirmation lead time, sometimes stock trending toward a shortage.
IFS Cloud already holds the data behind every one of those checks in its projections: order state, order age, confirmation status, stock position. What it does not hold is a record of who is supposed to be looking, or what happens if they are not. That is the gap worth mapping first. Not by asking who is busy, but by asking which checks exist only because one named person remembers to run them, and what the blast radius looks like if that stops for a fortnight.
The fix is not asking the buyer to write a longer handover note before their next holiday. A handover note is still a person, just a slower one. The fix is moving the check itself, the same logic that already lives in someone’s head, into something that runs on a schedule regardless of who is at their desk. That is exactly what a Custom Event does with the same unconfirmed-order logic covered here, applied more broadly to any check currently owned by one person’s habit.
| Memory-based check | Systematic check | |
|---|---|---|
| Runs when | The one person is present | Every day, on schedule |
| Survives leave | No | Yes |
| Survives turnover | No, leaves with the person | Yes, belongs to the system |
| Coverage | Whatever one person can hold in mind | Every order, every site |
| Handover cost | Weeks of tacit knowledge to transfer | None, the rule already knows |
None of this is a criticism of the person doing the check today. They built something valuable out of nothing, because the system did not do it for them. The point is simply that valuable and durable are different properties, and only one of them survives a two-week absence.
The person who owns the check today is your best source, not an obstacle. Start by asking them to describe exactly what they look for and why, then encode it.
This is built inside the IFS Extensibility Framework, using standard Custom Events, Workflows and PL/SQL, so it is update-safe. There is no core modification for the next release to break, so the coverage you build today keeps working after every upgrade, not just until the next one.
It is any recurring check or judgment call that only happens because one specific person remembers to do it, with no documented process or system behind it. If that person is unavailable, the check silently stops, and there is no error message telling anyone it stopped.
Documentation helps, but it is still a person executing a manual step, just a different one. A handover note does not run itself while everyone is in a meeting or the named backup is also out. Moving the logic into a scheduled rule removes the dependency on any specific person being available at all.
In practice, the opposite. Their judgment becomes the rule, they stop losing Monday mornings to a manual scan, and they are the first to get credit when the escalation catches something on the one week they are out. The interview step exists specifically so their expertise is what gets encoded.
Ask each person on the team what would not get checked if they were out for two weeks starting tomorrow. The honest answers name the exposure directly, and they usually cluster around the same two or three checks: unconfirmed orders and supplier follow-up are the most common.
Dariusz Myśliwiec has spent 25+ years in ERP and supply chain, 17+ of them on IFS (Apps 7.5-10 and IFS Cloud). He is an IFS Certified Associate Consultant and PRINCE2® 7 certified. His practice is based in Krakow and works remotely across Europe and beyond. You talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
If your supply chain runs on one person’s Monday-morning habit, the exposure is invisible right up until the week you can least afford it. A 30-minute call is enough to map which checks in your team are single points of failure and what encoding them would take. Fixed price, dry-run before anything goes live.
Independent IFS Cloud practice · Sales
Customer price agreements in IFS Cloud sit on dated lines: sales price list lines and customer agreement lines each have a date they stop 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 another price list or to the sales part price. Sales keeps quoting the old terms while the system has quietly stopped honouring them, so the price changes without anyone deciding to change it.
Key takeaways
Pricing in IFS Cloud is not a single number on a part. It is a set of sales price lists and customer agreements, and their lines carry a Valid From and a Valid To date. Valid To can be empty: such a line stays valid until a newer line with a later Valid From replaces it. When a date is set, it is a switch. On one side of it, an order line prices from the agreement. On the other side, that line no longer applies and the order line prices from whatever is next in the order of precedence.
IFS documents that order as a ladder of price sources, in About Pricing. A price typed by hand on the order line always wins. After that come a manually chosen agreement flagged Exclude from Auto Pricing, a sales campaign, the customer agreement fetched automatically, and a sales price list. The last rung is the price from the sales part. Sales Part Base Price, described on the same page, is something else: it is the basis for building price lists and agreements, not a price that lands on an order.
The switch flips by the calendar, not by an action anyone takes. There is no click, no approval, no message. The agreement line that was correct on Friday is simply not selected on Monday, and the order picks a different price without comment. The record still exists; only its validity window has passed.
Validity is checked against the price effective date of the order line, and the pricing method set per site and customer decides which date that is. With delivery-date pricing, a line entered before the expiry but delivered after it no longer takes the agreement price. Lines already entered are not repriced by the passing of time.
That makes this different from the pricing failures you already watch. A line with no price is loud, because the order cannot proceed cleanly. An expired agreement line is quiet, because the order prices fine, at a number nobody chose. It can even slip a line below cost if the fallback price is lower than the deal you meant to honour.
A naming note: the IFS screens are called Customer Agreement and Sales Price List. “Customer price agreement” is not an IFS term, but it is the phrase people search for, so it stays in the title of this article.
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 line 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 the sales part price. By then the orders are placed, and the only fix left is a credit note.
A second silent boundary exists from release 25R1: a customer agreement also stops being valid once it passes its Maximum Cumulative Amount, and, for a single part, once that part passes its Maximum Cumulative Quantity. The date can be perfectly fine and the agreement still drops out of pricing. This switch has nothing to do with the calendar, so a list of agreements expiring by date will not catch it.
Valid From and Valid To are stored on the price list and agreement lines, and a monitor can read them through OData without touching a record. The IFS documentation covers price list line validity and the price effective date on the order line. Detection is a matter of looking forward at the dates rather than backward at the damage:
Because this is a read-only monitoring pattern (how it works), 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 scheduled before the Valid To date rather than handled after an order is mispriced.
The problem is that the price is no longer the one that was agreed. When a customer agreement line expires, the order line prices from the next source in the IFS price source order, which might be another sales price list or, finally, the sales part price. The order looks priced and moves ahead, but the number can be higher or lower than the deal the customer expects, which shows up later as a margin miss or a dispute.
An off-agreement price is an order line that did not use the customer agreement it should have, while the agreement is still valid. An expired agreement is one step earlier: the agreement line has passed its Valid To date, so it is no longer available to any new order line. One is a line that missed a live agreement; this is an agreement that is no longer live.
No. What a price should be, and for how long, is a commercial decision that belongs with the account owner. The monitor reads validity dates through OData and lists what is about to expire or has already lapsed, then leaves the renewal to a person. Nothing is written back to IFS.
The monitor can rank expiries by pairing each one with recent order activity. An agreement lapsing on a customer who orders every week is urgent, while one on a dormant account can wait. Ranking expiries by how active the account is keeps the list short and focused on the agreements that are about to misprice real orders.
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud) in ERP and supply chain. IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Tell me how your team manages customer price lists and agreements. On a 30-minute fit call I’ll show you how a read-only monitor, built the same way as the SCM Automation Pack, would list every agreement line expiring in your chosen window, ranked by which accounts are still ordering, with a dry-run week so the renewals are planned before an order prices from the wrong source.
Independent IFS Cloud practice · Upgrades & Extensibility
Key takeaways
A custom PL/SQL package built five years ago checks order states every morning and emails purchasing when something needs attention. It survives two IFS Cloud upgrades without a single change. On the third, an upgrade alters a view the package quietly depends on. The package does not throw an error. It runs on schedule, queries successfully, and returns zero rows. For six months, nobody notices, because zero rows looks exactly like a quiet month in purchasing, and a quiet month is not a support ticket. This is the failure mode that testing plans built around “does it still run” miss completely, and it is a more common story on real IFS Cloud estates than most upgrade retrospectives admit.
Most regression testing after an upgrade asks one question: does the custom code still execute without throwing an error? That question has an honest, comfortable answer almost every time, because IFS Cloud upgrades are designed to be graceful. A renamed column, a restructured view, or a changed join rarely crashes a package outright. It just changes what the query returns, and a query that used to match forty rows a day can start matching zero without any exception being raised at all.
The people who could catch it are not looking for it, because there is nothing prompting them to look. An upgrade project tracks the things that visibly break: failed jobs, error logs, user complaints. A rule that goes quiet produces none of those. It produces the absence of a thing that was never guaranteed in the first place, and absence is the hardest failure mode to schedule a test for.
The cost is not the broken package. It is everything the package was put there to prevent, arriving unannounced during the exact months it was quietly offline.
Custom code that fails loudly is a nuisance you fix in an afternoon. Custom code that fails quietly is a risk you carry into every release without knowing it.
The fix is not more error handling inside the check itself. The check was never throwing an error to begin with. The fix is watching the check from the outside: a heartbeat that compares how many rows a rule returned this run against its own recent history, and flags a rule that has gone quiet the same way it would flag one that suddenly went noisy.
A rule that has averaged five to ten hits a week for a year and then returns zero for three consecutive runs is worth a look, regardless of whether “zero is plausible” on its face. This is the same logic used to keep upgrade readiness checks honest: verifying a control still behaves the way it always has, not just that it still exists in the codebase.
Both are useful. Only one of them would have caught the six-month gap.
| Runs without error | Verified live (heartbeat) | |
|---|---|---|
| What it confirms | The package executes and completes | The package’s output still matches expected behaviour |
| Catches a broken dependency | Only if it throws an exception | Yes, even if the query still runs cleanly |
| Catches zero-row drift | No | Yes |
| When it is checked | Once, at upgrade testing | Continuously, every run |
| Effort to maintain | None after go-live | Light: one baseline comparison per rule |
Upgrade testing that stops at “it still runs” is necessary and not sufficient. The heartbeat is what turns a one-time test into an ongoing guarantee that survives the upgrade after the one everyone tested for.
The heartbeat should be quieter than the rule it is watching, not louder.
Built as standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, both the original rule and its heartbeat stay update-safe and avoid the upgrade tax. That is the same discipline that keeps Custom Events maintainable release after release.
Most regression testing confirms a package still executes without an error. It rarely confirms the package’s output still matches its historical pattern, which is exactly the gap a zero-row failure exploits.
Any scheduled custom check whose failure mode is silence rather than an error is a candidate: typically anything built as a PL/SQL job or Custom Event that queries and emails without a human reviewing the query result itself.
Only if it is tuned poorly. Routed to IT rather than to the business audience, and fired only on a genuine deviation from baseline, a heartbeat alert should be rare enough to always be worth opening.
Yes. Both the original rule and the heartbeat that watches it are built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework. There is no core modification, so there is nothing here for the next R1/R2 release to quietly break.
Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. You talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
A short audit of your scheduled custom checks against their own history will show you, in a day, whether any of them have been silently returning zero since your last upgrade. Fixed price, no changes go live without a review.
Independent IFS Cloud practice · Supply Chain
Key takeaways
A report tells you twelve purchase orders are unconfirmed. A decision tells you which three need a phone call today. Most supply chain reporting confuses the two. It delivers volume (forty pages, eighty line items, a dashboard with six charts), and the recipient scans it, notes that nothing is obviously on fire, and moves on. The value was never in the forty pages. It was in the three lines that needed action. But those three lines were buried among thirty-seven that did not, and the person who could have acted on them never saw them at all. Good exception handling does not report. It routes. It puts the right three lines in front of the right person at the right time, and it does not ask them to hunt. This article looks at why reporting defaults to volume, what interpreting a report actually costs, and how to route exceptions in IFS Cloud instead of reporting them.
Reports are easy to build comprehensively and hard to build selectively. Comprehensiveness is a query: pull every open order, every line, every field. Selectivity requires someone to decide, in advance, which combination of conditions actually matters, and that decision feels like a risk, because leaving something out looks like a mistake later, while leaving everything in never does. So the safe choice, repeated across every dashboard and every export, is to include everything and let the human sort it out.
The human, of course, is usually the same person the report was meant to save time for. They open it between two other tasks, scroll for a pattern, and either catch the three lines that matter through sheer familiarity with the data, or miss them because today was a busy day. The report did its job: it reported. Nobody decided anything, because nobody was asked a specific question.
Handing someone a report instead of a decision does not save work. It moves the work, unpaid and unscheduled, onto whoever opens the report next.
A report that requires interpretation is a task you have given to someone who did not ask for it.
The test is simple: does the output name a person and a next action, or does it name a data set? A Quick Report that lists every open purchase order is a data set, which is useful but still a report. A rule that filters that same data set to the handful of orders past a defined threshold, and sends only those to the buyer responsible, is a decision arriving pre-qualified. The mechanics of both are covered in Quick Reports, Custom Fields and Custom Events compared, and the trigger-and-action pattern behind routing specifically is the backbone of the SCM automations for IFS Cloud.
Most instances already have the report. What is usually missing is the second step: a Custom Event that reads the same underlying data, applies the threshold that defines “matters today”, and sends the result to one named recipient instead of publishing it for everyone to interpret.
The two are built from the same data. The difference is entirely in what happens between the data and the person who has to act on it.
| Reporting | Routing | |
|---|---|---|
| Output | Every row that matches the query | Only the rows past the threshold |
| Recipient | A distribution list | The named person who can act |
| Interpretation needed | Yes, every time it is opened | None: the filter already did it |
| Timing | Fixed schedule, regardless of urgency | As soon as the threshold is crossed |
| Fails when | The reader is busy or fatigued | Never sleeps |
Keeping the report is often still worth it, because it is the audit trail and the occasional deep dive. Routing does not replace it; it removes the requirement that a human read the whole thing to find the part that matters.
Start from a report you already trust, not from a blank page.
The routing layer is built inside the IFS Extensibility Framework (standard Custom Events, Workflows and PL/SQL), so it sits alongside your existing reports without modifying them or the core, and survives the next upgrade untouched.
A report lists everything that matches a query and leaves interpretation to whoever reads it. Routing applies the interpretation in advance (a threshold, a filter, a named recipient), so what arrives is already a decision, not a data set to search through.
No. Reports remain valuable as an audit trail and for the occasional deep dive. The change is to stop relying on a report as the primary mechanism for surfacing something urgent, and to route the urgent cases separately.
Watch what an experienced person actually flags from the full report over a few cycles, then turn that pattern into an explicit threshold. The dry-run period exists precisely to test that the filter matches what a human would have chosen.
Yes. Routing is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, sitting alongside existing reports rather than modifying the core, so nothing here is at risk from the next R1/R2 release.
Dariusz Myśliwiec: 18 years hands-on with 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, where you talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Pick the report your team dreads opening and I will show you, on a dry-run, what routing it would actually send, and to whom. On a 30-minute call we will map the first threshold together (fixed price, dry-run before anything sends).
Independent IFS Cloud practice · Procurement
Key takeaways
She knows every supplier by name. She can tell you which orders need chasing without opening IFS. She has done this for eight years, and she is the reason nothing falls through the cracks on her desk. She is also the reason everything could. If she won a competitor’s offer tomorrow, her replacement would inherit a supplier list and a login, not the eight years of pattern recognition that made her effective. This is not a story about one buyer being irreplaceable. It is a property of any role where expertise lives in a person instead of a process: the organisation only feels safe because nobody has priced what leaves with her. This article looks at why that concentration builds up unnoticed, what it costs the day it is tested, and how to move the judgment (not just the task) into something IFS Cloud can carry.
Nobody sits down and decides to make the procurement function dependent on a single buyer. It happens one competent decision at a time. A supplier misses a delivery once, she notices the pattern before it repeats, and the organisation quietly starts trusting her judgment over the system’s default rules. Three years later she is not running a documented process with occasional exceptions: she is the process, and the documented version in the training folder describes a simpler world that stopped being true a long time ago.
The reason nobody intervenes is the reason it is dangerous: she is good at her job. A struggling buyer gets coached, escalated, and eventually supported by a second pair of eyes. A buyer who never drops a ball gets left alone, because there is nothing visibly wrong to fix. The gap between what she knows and what the organisation has captured about what she knows grows every year she keeps performing, and it is invisible for exactly as long as she stays.
The cost does not show up while she is at her desk. It shows up the day she is not, and by then it is too late to build the thing that would have prevented it.
The measure of a healthy procurement function is not how well it runs when the best buyer is in the room. It is how well it runs on the Tuesday she is not.
The concentration itself does not show up as a red flag anywhere in IFS Cloud, because it is the absence of something, not the presence of an error. What you can see are its shadows: a small number of buyer codes attached to a disproportionate share of purchase orders that were escalated, chased or rescued outside the standard workflow; suppliers whose confirmation delays never trigger the same generic threshold rule twice, because the buyer intervenes before it fires; and a training folder or SOP that has not been updated since a point release everyone has forgotten the number of.
None of that is visible from a summary dashboard. It becomes visible only when someone asks a specific question: for this buyer’s supplier portfolio, what percentage of exceptions were caught by a system rule versus caught by her noticing first? If the honest answer is “mostly her,” the concentration is already real, whether or not anyone has named it yet.
The goal is not to replace her judgment but to stop the organisation’s exposure being entirely proportional to her presence.
| Tacit judgment | Documented system rule | |
|---|---|---|
| Where it lives | One person’s memory | IFS Cloud, applied consistently |
| Survives absence | No | Yes |
| Transfers to a new hire | Only through years of exposure | Immediately, on day one |
| Auditable | No trace of why a call was made | Logged rule, logged trigger |
| Improves with review | Only if she reflects on it herself | Tunable by anyone with visibility |
None of this argues she should stop exercising judgment on the cases that genuinely need it. It argues that the routine ninety percent of what she does by pattern (which supplier is drifting, which order needs a call today) belongs in a rule the system enforces, freeing her judgment for the harder ten percent only she can actually add value to.
This only works if it is framed, honestly, as protecting the function, not auditing the person. Done the wrong way, it reads as a performance review. Done the right way, it reads as building her a backup.
Built this way, with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, the rules stay update-safe and avoid the upgrade tax, the same discipline behind a supplier behaviour-change signal or an unconfirmed-PO escalation. Clear ownership of who can see and change each rule follows the same logic as segregation of duties in IFS Cloud.
Documentation captures what the process is supposed to be. It rarely captures the exceptions an experienced buyer makes by instinct, and it does not act on its own. The goal here is a rule IFS Cloud enforces automatically, not a page someone has to remember to read.
A departure is one moment you can at least plan a handover around. Concentration risk exists every single day she is simply out sick, on leave, or in back-to-back meetings, long before anyone has thought about a resignation.
Only if it is introduced as one. Framed and sequenced correctly (interview first, give her the resulting alerts first, extend coverage only once she trusts the rules), it reads as removing her busywork, not her judgment.
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no core modification, so there is nothing here for the next R1/R2 release to quietly break.
Dariusz Myśliwiec: 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally, where you talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
If your best buyer’s judgment is currently your only safety net, a dry-run month will show you exactly which of her instincts can become a system rule today. Fixed price, nothing goes live until she has seen it work.
Calculate your return on investment