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.
Available today · part of the same free check
Master data that is complete can still be wrong
A lead time of 30 days is present, numeric and valid. It passes every completeness rule ever written. It has also been wrong for two years. Neopiq checks your D365 planning master data three ways — is it filled in, do the records agree with each other, and is the value still true — and only the third one finds that item.
Three questions, and most tools stop after the first
Each layer costs more thinking than the one before it, and each one finds problems the previous one cannot see.
Do the records agree?
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.
Is it still true?
The field is filled in, internally consistent, and contradicted by your own transaction history. This is the layer that separates a data quality report from an explanation of why planning keeps going wrong.
What it finds in D365 planning master data today
These checks ship inside the same free browser check as the planning diagnosis — there is nothing extra to download or buy.
Nobody is accountable
Active items with no planner at all, and items whose planner code points at somebody who is no longer in the planner table. A finding with no owner is a finding nobody will fix, so we report the missing owner as a defect in its own right.
References that point at nothing
Coverage groups and reduction keys that were renamed, retired or never created. The item looks configured. Master planning treats it as unconfigured.
Records that contradict each other
Item lead time against vendor lead time. Purchased or manufactured status against the existence of a route. Two sources of truth, and planning only ever reads one of them.
Things you stopped selling, still being planned
Obsolete items carrying live forecast lines, and obsolete items sitting on hand. Both quietly consume demand, stock and attention long after the decision to discontinue was made.
Why this is not another data quality scorecard
A scorecard tells you the fields are populated
Which is true, comforting, and says nothing about whether the populated values are right. A completeness percentage goes up when somebody types anything into the box. Completeness is where we start — the first of three layers, not the product.
We tell you which value is wrong, and how we know
Named item. The configured value next to the observed one. The number of transactions behind the comparison. The business consequence. The owner. You can dismiss any finding in ten seconds because the reasoning is on the page, not behind an API.
Where this is heading
Stated in the future tense on purpose: none of this is built, and nothing below is available to buy or try.
Your own definitions, read and used
Today the checks know column names, not meaning. The intended next step is to read your process documents, KPI definitions and data dictionaries so the checks can tell a deliberate exception from a defect, quote your own policy back at you, and flag where two documents define the same term differently.
Status: designed, not built.
Process mining and supervised repair
Full process mining over event history, and correcting master data at volume instead of listing it, are intended to run inside your own Azure subscription under your own controls. Read-only diagnosis comes first, always; nothing writes to your system without a person approving it.
Status: a direction, not a product.
Who gets value out of it
- D365 functional consultants who need to know how bad the master data really is before promising a plan to fix it.
- Data and process owners who want a repeatable check they can re-run every quarter, not a one-off spreadsheet audit.
- Programme managers before a go-live who would rather find the contradictions now than during the first master planning run in production.
- IT leaders who need this answered without exporting business records to a third party.
Placeholder — owner input required
[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: supported D365 applications and versions, and the recommended way to produce the extracts — data entities, an export project, or a saved view.]
[PLACEHOLDER: screenshots or a short recording. None exist yet, so this page shows no product imagery.]
Find out how much of your master data is true, not just filled in
The check is free, runs in your browser, and transmits nothing. Start with the sample data if you want to see the output before you export anything.