How to find the late purchase orders that matter in IFS
Purchase order lines tell you which orders are late. Inventory part in stock tells you whether that hurts. How to put the two together in IFS Cloud.
What IFS already gives you
In IFS Cloud, everything you need to judge a late purchase order already exists, spread across pages built for different jobs:
- Purchase order lines: each line carries a wanted receipt date and, when the supplier confirms, a planned receipt date.
- Inventory part in stock: on-hand and available quantities by part and site.
- Inventory transaction history: the issues and receipts that give you a usage history.
- Lobbies, queries and exports to Excel: the usual way to put these lists side by side.
Each one answers part of the question. None of them ranks your late orders by the stock risk behind them. A past-due purchase order list sorted by date tells you who is late, not who to call first.
The method, step by step
1. List the open lines past their receipt date
Export open purchase order lines with part, supplier, quantity still to receive, wanted receipt date and planned receipt date. Keep the lines whose planned date (or wanted date, when the supplier never confirmed) is before today, and flag the lines never confirmed.
2. Get stock and usage for each part
Take available quantity per part and site. For usage, sum issues over a fixed window, for example the last 12 weeks, from inventory transaction history: issues to shop orders and deliveries to customers. Use the same window for every part.
3. Compare days of cover with the real arrival date
Days of cover = available quantity / average daily usage. For each late line, take the date you now expect it, and check for another open line on the same part that arrives earlier. If cover runs out before any receipt, the line is a shortage risk.
4. Sort by days of cover, shortest first
Among the shortage risks, the part with the fewest days of cover goes to the top. That is your chase list for today. For each line, write down stock, usage, cover, the receipt dates and days late: when you call the supplier, you are discussing facts.
Illustrative example, not a customer result
Two lines from the same export:
- Line A, sheet metal blank: 10 days late. 4,000 available, usage of about 80 a day: 50 days of cover. Another line arrives next week.
- Line B, hydraulic cylinder: 2 days late, no planned receipt date. 12 available, usage of about 4 a day: 3 days of cover. No other open line.
Sorted by days late, line A comes first. Sorted by days of cover, line B does, and line B is the one that can stop production this week.
Where the manual method breaks
- It does not scale. Checking cover part by part works for ten late lines, not for two hundred every Monday.
- Usage needs care. New, seasonal or lumpy parts make a 12-week average misleading. Flag them rather than trusting the number.
- Dates are only as good as their maintenance. If supplier confirmations are not entered, the line still carries the wanted date.
- Days of cover tells you when a part runs out, not which shop order or customer order it affects. Linking the two still needs your planners and your product structures.
Questions people ask
Does this work in older IFS Applications versions?
Yes. Page names may differ, but every version holds purchase order lines with dates, stock by part and site, and transaction history, which is all the method needs.
Which date should I trust, wanted or planned?
The planned receipt date when the supplier confirmed one. A line with only the wanted date has no supplier commitment behind it.
How WERISCO does it
WERISCO automates the data work behind these steps: it reads every open line, computes days of cover for each part and flags late or undated orders by severity, with the evidence on each line. With IFS Cloud, it works from structured exports: available quantity by part and site, and open purchase order lines. There is no WERISCO IFS connector today; see the IFS integration page. The first supply chain audit needs only those two exports. WERISCO reads only; nothing is written back to IFS, and your team decides what to chase.
One supply-chain shock, decoded in numbers, and what a data-driven plant does about it.
