“We order too late, so we expedite”
Purchasing knows the supplier takes ten weeks. The item master still says four. Master planning believes the item master, so every order starts late and finishes expensive.
Pillar 2 · the free check is available today
Your planning system is doing exactly what you configured. That is the problem.
Lead times, safety stock, minimum order quantities and coverage groups were set once — before the supplier changed, before the volumes moved, before the product went end-of-life. Master planning is not guessing; it is obeying. Neopiq finds the settings and the master data that no longer match what actually happens, quotes the numbers that prove it, and names the change to make.
It runs inside your browser. No account, no install, nothing uploaded — you can disconnect from the network first and it still works. Why that is true.
Example finding · sample data
Configured 30 days. Received in 70. No safety stock.
- Item ITM-X123, vendor VEN-045
- Lead time in the item master: 30 days
- Actual receipts: 69.88 days on average, over 8 purchase receipts
- Safety stock: zero
- Owner on record: planner PLN-02
Master planning proposes supply too late by design, and there is no buffer between the gap and the customer. It looks like a supplier problem. It started as a parameter.
This is the worked example in the synthetic sample data that ships with the free check. It is not a customer. Open the tool and the same finding appears in one click.
You have heard these sentences in your own meetings
Each one has the same shape: the system is blamed for a decision that a setting made years ago.
“Full of the wrong stock, out of the right stock”
A minimum order quantity set for a product that used to sell ten times faster. A forecast that keeps consuming demand for an item you stopped selling. The stock is the symptom; the parameter is the cause.
“The planners override the system”
When planned orders stop making sense, people plan in a spreadsheet and key the answer back in. Every manual override is a vote of no confidence in a setting somebody should have changed.
Three questions, and most tools stop after the first
This is one check, not two products. It asks about the master data underneath your planning setup and about the planning behaviour on top of it, because separating them is how the interesting failures get missed.
1. Is it filled in?
Active planning items with no lead time, no supplier, no planner, no site, no item group, no coverage group. Cheap to find, cheap to fix, and still the reason a surprising number of planned orders look strange. Directly observed, so there is nothing to argue with — only to fix.
2. Do the records agree with each other?
The item says four weeks, the vendor record says ten. The item points at a coverage group or reduction key that no longer exists. A purchased item carries a production route; a manufactured one has none. An obsolete item is still being forecast and is still holding stock.
3. Is the value still true?
The field is filled in, internally consistent, and contradicted by your own transaction history. A lead time of 30 days is present, numeric and valid — it passes every completeness rule ever written, and it has been wrong for two years. This is the layer where the money is.
Why this is not a data quality scorecard
A completeness percentage goes up when somebody types anything into the box. It is true, comforting, and says nothing about whether the populated value is right. Completeness is the first of the three layers above, not the product. What comes back here is a named item, the configured value next to the observed one, the number of transactions behind the comparison, the business consequence and the owner — so you can dismiss any finding in ten seconds, because the reasoning is on the page rather than behind an API.
The twenty-six questions it asks about your D365 data
Grouped by the part of the setup they interrogate. Every one of them ends in a named item, the numbers behind the claim, and the change to make. These are the checks that exist and run today.
| Area | The question it asks | What it compares |
|---|---|---|
| Lead time vs reality | Are we planning to a lead time the supply chain has not delivered in years? | Configured purchase lead time against the actual order-to-receipt time on your own receipt history — and flags it harder when safety stock is zero |
| Lead time drift | Has this item quietly got slower, without anyone updating it? | Recent receipt behaviour against the same item's earlier behaviour |
| Lead time outliers | Which lead times look nothing like their peers? | Each item's configured lead time against the spread of the whole item population |
| Vendor agreement | Does the item say one thing and the vendor record another? | Item lead time against the vendor's lead time for the same item |
| Production lead time | Do our production orders finish when the routing says they will? | Configured production lead time against actual production order completion |
| Safety stock | Is the buffer big enough for how volatile this demand actually is? | Configured safety stock against demand variability, replenishment time and the service level you are targeting |
| Order quantities | Is a minimum order quantity buying years of demand in one go? | MOQ and lot size against real consumption from sales order history |
| Excess cover | Where is working capital sitting still? | On-hand quantity against real demand rate — per item and per site, so an item that is healthy in one plant and drowning in another is not averaged into looking fine |
| Forecast quality | Are we planning to demand that is not arriving? | Forecast quantities against actual order intake for the same item |
| Forecast consumption | Will this forecast ever be consumed, or will it double the demand? | Forecast lines against the reduction key that is supposed to consume them, including lines with no reduction key at all |
| Obsolete items | Are we still planning and stocking things we no longer sell? | Item status against live forecast lines and against on-hand inventory |
| Planning policy | Does every active item have a coverage group, and does it point at a real one? | Item coverage group and reduction key against the coverage group and reduction key tables |
| Sourcing consistency | Does the sourcing setup contradict itself? | Purchased items carrying a production route, manufactured items with no route, active items with no supplier |
| Supplier reliability | Are the confirmed dates we plan on worth anything? | Confirmed delivery dates against actual receipt dates |
| Service outcome | Which items are failing customers, and which are getting worse? | On-time delivery against your target, and this period's performance against the previous one |
| Accountability | If this item breaks, whose name is on it? | Planner, site and item group on active items — including planner codes pointing at people who no longer exist |
The point is not one bad field. It is the pattern across an item.
Anything can tell you a cell is empty. What matters is the same item turning up from several different directions at once, because that is the difference between “a field is wrong” and “here is why this item keeps failing”.
How a single item builds a case against itself
- Its lead time says 30 days; its receipts average 69.88 days over 8 deliveries
- Its safety stock is zero, so there is no buffer for that gap
- Its supplier's confirmed dates do not survive contact with the actual receipts
- Its on-time delivery is below target
- And its on-time delivery is falling, not recovering
Read one of those and you have a data quality ticket. Read all five together and you have a sourcing decision, a parameter change and a conversation with a supplier.
From the synthetic sample data shipped with the check — not a customer. It is there so you can see the shape of the output before you export anything.
What you need to run it
CSV extracts from D365. The shipped rule library reads eleven of them: items, vendors, purchase receipts, sales order lines, on-hand inventory, production orders, production routes, forecast lines, coverage groups, reduction keys and planners.
You do not need all eleven to get an answer. Bring what you have; every check that cannot run is reported with the reason and the columns it was missing. Finding out which of these questions your standard export cannot answer is useful on its own.
No install, no account, no upload. The check runs in the browser and the files never leave your machine.
The security conversation is a short one
The free check is a web page that reads your CSV files locally. There is no upload, no account, no login, no cookie, no analytics and no server to send anything to. Nothing is stored either — closing the tab is the delete button.
You do not have to take that on trust. Open your browser's network tab while it runs, or pull the network cable first. Your item master and your vendor lead times are commercially sensitive; that is exactly why the first useful answer should not require a data-processing agreement.
No procurement step. No security review. No integration project. One person and one export.
What this is not
- Not a chatbot. This pillar has no prompt and no model guessing at your business. The same export produces the same findings, in the same order, every time. (The admin agent is the conversational one, and it is a different product on a different pillar.)
- Not another dashboard. A report shows you the shortage. This names the setting that caused it — including the ones nobody thought to build a report for.
- Not a data quality score. A lead time of 30 days is present, numeric and valid. It passes every completeness check ever written. It is still wrong.
- Not a robot in your ERP. Nothing is written back. Every finding is a hypothesis with the evidence attached, and a person decides.
When people run this, and who gets value out of it
Before a go-live or a migration
Parameters are about to be carried into a new environment or onto Planning Optimization. This is the cheapest possible moment to find out which of them stopped being true.
Before an inventory reduction programme
Before anyone sets a stock target, find the MOQs, safety stocks and forecast settings that are manufacturing the excess. Cutting stock without changing them just re-creates it.
When the same shortages keep coming back
If the monthly service meeting keeps discussing the same items, the cause is usually structural. This finds the structure.
- Supply chain and planning managers who want the exception list before the monthly review, not as its outcome.
- Master planners and buyers who already suspect which parameters are wrong and need the evidence to get them changed.
- D365 functional consultants who need a fast, defensible read on a client's planning setup and master data in the first week of an engagement.
- Data and process owners who want a repeatable check they can re-run every quarter, not a one-off spreadsheet audit.
- Operations and IT leaders who will not ship item, vendor and order history to an external service to find out whether there is a problem.
What we will not pretend
- The thresholds are defaults. They are sensible starting points written in plain rule files, not facts about your business, and they have not been tuned on your data. Expect to argue with a few and change them.
- Findings are hypotheses for a person. The check does not know that one coverage group is deliberately unusual. It shows its evidence so you can dismiss it fast.
- Trends are simple comparisons of one period against another, not seasonal models. A supplier who is always slower in the summer will look like drift.
- The thresholds have never been tuned against a real customer tenant, and the sample data that demonstrates the checks is synthetic.
- Nothing is written back to D365. The output is a work list; every change is made by your people, in your system, on purpose.
Where this pillar is heading
Stated in the future tense on purpose: neither of the steps below is built, and nothing in them is available to buy or try.
Findings explained, written up, and read against your own definitions
The reading and the rule work would stay local. A cloud service would take the results — summary numbers and risk signals, never your records — and turn them into a prioritised written report. Alongside it, reading your own process documents and KPI definitions so a deliberate exception can be told apart from a defect.
Status: designed, not built.
Optimisation, simulation, process mining and supervised repair
The heavy work at full data volume, intended to run inside your own Azure subscription under your own controls. Read-only diagnosis comes first, always; nothing would write to your system without a person approving it — the same approval discipline the admin agent already runs on.
Status: a direction, not a product. For D365 no part of it is built.
Placeholder — owner input required
[PLACEHOLDER: supported scope in D365 terms — which Supply Chain Management versions and modules, whether Planning Optimization or the built-in master planning engine is assumed, and the recommended way to produce the eleven extracts (data entities, export project, or a saved view).]
[PLACEHOLDER: scope beyond planning master data. Today's checks cover the planning-critical objects — items, vendors, planners, coverage groups, reduction keys, routes, forecast. Whether customer, finance or product-structure master data is in scope, and in what order, is a product decision that has not been made.]
[PLACEHOLDER: what the Level 1 and Level 2 steps add for this pillar specifically — demand pattern work, scenario simulation and optimisation are named in the internal architecture with no detail behind them, and neither step is built.]
[PLACEHOLDER: screenshots or a short recording of the check running. None exist yet, so this page shows no product imagery rather than a mock-up that could be mistaken for a real screen.]
Judge it on your own items, not on our claims
The check is free, it runs in your browser, and nothing you load into it is transmitted anywhere. If the findings are wrong, you will know immediately — every one of them shows its numbers.