Available today · free

Find the planning settings that are costing you service and stock

Master planning is not guessing. It is obeying lead times, safety stocks, order quantities and coverage groups that somebody set years ago and nobody has re-read since. Neopiq compares those settings against what your receipts, orders and shipments actually did, and reports every place the two have parted company.

The twenty-six questions it asks about your planning data

Grouped by the part of the planning setup they interrogate. Every one of them ends in a named item, the numbers behind the claim, and the change to make.

What the free check compares, area by area. 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”.

One item, five findings · sample data

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.

Open the check and try it on the sample data first

When people run this

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.

Who gets value out of it

  • 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 in the first week of an engagement.
  • 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.
  • Nothing is written back to D365. The output is a work list; every change is made by your people, in your system, on purpose.
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: what the planned Level 1 and Level 2 steps add for this family 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.