Getting started with BDP ForecastQ
Business Central's planning engine reads a reorder point and a demand forecast beautifully. It has no built-in way to compute either at the warehouse level. ForecastQ reads your own posted item ledger, computes both, and writes them into the native fields Business Central's own planning engine already reads — which stays the only engine that nets demand against supply and proposes orders.
1. What ForecastQ does
ForecastQ reads Item Ledger Entry — the same append-only table Business Central posts every sale and consumption into — and turns it into monthly demand per item, location and variant. It classifies each series (how much it's worth, how predictable it is), forecasts it with classical statistical methods, converts the forecast into stocking policy, and writes that policy into the fields Business Central's Material Requirements Planning already reads: Safety Stock Quantity, Reorder Point and Reorder Quantity on the item or Stockkeeping Unit, and forecast quantities into the native Demand Forecast.
Business Central's planning engine stays the only netting engine. ForecastQ never nets demand against supply, never creates a purchase, transfer or production order, and never runs its own version of Calculate Plan. Everything it produces lands in fields a planner already knows how to read, and Calculate Plan in the Requisition or Planning Worksheet runs exactly as it always has.
ForecastQ is one input to planning, not a replacement for it. It computes numbers a human used to have to guess, type once, and forget to revisit — it does not decide what to buy or build.
2. Installing and running your first forecast
New to ForecastQ? Work through these in order.
Install and open ForecastQ Setup
Install ForecastQ from AppSource, then search for ForecastQ Setup. It opens on a single record — there's nothing to create first.
Set the Forecasting fields
Forecast Horizon Months — how many buckets ahead the engine projects. Bucket Type — Month or Week; Month is what the engine is built and tested around. Default Forecast Name — the native Production Forecast Name ForecastQ publishes under. Forecast Per Variant — whether each item variant is forecast as its own series. Demand is always stored per variant regardless of this switch; leave it off unless you genuinely plan at variant level, because variant series are thinner and more of them will read Insufficient Data (see §4) the finer you slice.
Set the Execution fields
Chunk Size — how many scopes one Job Queue invocation processes before re-enqueuing itself, so a full-catalogue run never depends on one long-running session. Recommend Run Scope — whether a recommendation run covers All Classified Items (a full pass, sized by Chunk Size) or Items With Findings Only (faster, but a healthy item then gets no recommendation at all).
Try it on demo data first (sandbox only)
Install Demo Data, on the Setup page, creates a demo item with real, posted item-ledger history so ForecastQ has genuine demand to classify and forecast before you point it at your own catalogue. It only runs in a Sandbox environment.
Run your first aggregation and classification
From Setup, choose Run Full Aggregation (Job Queue), then Run Full Classification (Job Queue) — or run both together later from the Role Center's Run Demand Aggregation & Classification action. Both enqueue chunked, resumable Job Queue entries and return immediately; progress is visible on Run Checkpoints.
3. The daily loop: Role Center to approval
The ForecastQ Role Center is where a planner's day starts. It leads with a headline and cue tiles, then a dollar-ranked exception cockpit directly below — the things that need attention today, and the place to act on them, on the same landing page.
Readiness Findings
Items Business Central's planning engine will silently skip or handle badly — graded Info, Degraded or Blocked — each with a plain-language message, a suggested fix, and sometimes a one-click guided fix a human still has to choose to run (Create Missing SKUs, for example).
Exceptions
Requisition Worksheet lines re-read and ranked by Dollar Exposure (|Quantity| × Direct Unit Cost) multiplied by an Urgency Weight, so the worksheet's most consequential lines surface instead of a flat list. Rank Exceptions Now recomputes it on demand; Open Worksheet Line jumps straight to the source line.
Recommendations
Every proposed Safety Stock, Reorder Point or Reorder Quantity change, with the current native value beside the recommended one, the method used, and a plain-language Rationale. This is the only place a value moves toward Business Central (see §5).
Everything else, organized
The Role Center's Sections groups reach every other page: Classification & Demand (Workbench, Item Profiles, Demand Buckets), Readiness & Forecasting (Lead Time Stats, Vendor Lead Times, Forecast Versions, Forecast Accuracy), Replenishment (Recommendations, Publish Log), Diagnostics & Audit (Audit Events, Run Checkpoints), and Setup (Setup, Threshold Setup, Service Levels).
A typical day: open the Role Center, work down the exception cockpit and Readiness Findings, open Recommendations and approve (or reject) what's Proposed, then choose Publish Approved to Business Central. Nothing runs automatically in the background beyond the scheduled aggregation and classification passes — every write to a native field is a deliberate action a person takes.
4. Understanding the numbers
ABC × XYZ classification
ABC ranks items by annual usage value (how much money moves through them). XYZ ranks them by demand predictability — the coefficient of variation of the demand series. Crossing them sets the target service level ForecastQ sizes safety stock against, on the Service Levels page.
Insufficient Data is a real state
A brand-new item with one or two months of history is not classified as predictable by default — it needs a minimum number of demand buckets first. Until then it reads Insufficient Data, deliberately, rather than being scored with false confidence from too little evidence.
Forecast methods, and a floor under all of them
A panel of classical statistical methods is fitted and back-tested per series, and the one with the best measured accuracy is selected — every figure ForecastQ produces is deterministic, reproducible arithmetic: the same inputs give the same numbers, every time, never a machine-learning output. Accuracy and bias are reported per item, visible to you, not hidden inside the tool. If nothing in the panel beats a plain baseline on a series' own back-test, the baseline ships instead: ForecastQ's forecast is never allowed to be worse than doing the simplest thing — a provable floor, not a promise.
Safety stock and reorder point
Sized from the distribution of demand actually observed over the item's lead time, at the service level its ABC×XYZ cell targets — not a single formula assumed to fit every item. Lead time itself is measured from posted purchase receipts where enough exist; Lead Time Stats and Vendor Lead Times show which source was used for a given item.
Reading a Recommendation row
Current Value is what Business Central holds today; Recommended Value is the final number after every applicable clamp — the one you're being asked to approve. Was Clamped flags when a reorder quantity was rounded to the item's order multiple or held within its minimum/maximum order quantity rather than left as raw arithmetic. Method Code shows whether the figure came from the empirical distribution, a parametric cross-check, or an EOQ calculation, and Divergence % shows how far the empirical and parametric estimates disagreed when both were available. Rationale spells the whole thing out in a sentence.
5. Approve-first: nothing changes without you
Every recommendation is created as Proposed. Nothing reaches a native Business Central field until a person opens Recommendations and chooses Approve — or Unapprove, to send an approved row back to Proposed before a publish run picks it up.
Publish Approved to Business Central writes every currently Approved row to its resolved Item or Stockkeeping Unit field, then independently re-reads that field to confirm the value actually landed before marking the row Written. A row that doesn't verify is marked Failed with the real error, rather than reported as a success it wasn't. Rows left as Proposed or routed to Needs Review — for example when the empirical and parametric safety-stock estimates disagree sharply — are never touched by a publish run.
Every write is logged to Publish Log, reachable both from the Role Center and directly beside Publish Approved to Business Central — which rows were written, which failed, and why.
6. Troubleshooting
An item shows Insufficient Data
Expected for a genuinely new item or a thin series — it needs more posted demand history before ForecastQ will classify or forecast it with any confidence. It is not an error and nothing is wrong with the item; wait for more ledger history, or reduce how finely you're slicing it (see Forecast Per Variant in §2).
An item is being discontinued — what happens to its demand history?
Search Business Central for Item Supersessions and choose New Link to connect the discontinued item (the predecessor) to its replacement (the successor). ForecastQ splices the predecessor's full demand history onto the successor immediately — chain-flattened across multiple supersessions if there are several, every inherited bucket flagged with which item it truly originated from, and any stockout censoring carried through unchanged. This is what turns an Insufficient Data read on a brand-new replacement item into a real forecast from day one, instead of a cold start. A link is always an explicit action a person takes — nothing is copied silently — and Unlink removes exactly what that one link introduced, without touching any other link in the chain.
A Blocked item gets no recommendation
That's by design. Open the item on Readiness Findings to see why it's Blocked and what to fix; running Generate Recommendations against a Blocked item correctly generates nothing rather than a number built on a known gap, and says so.
A forecast isn't appearing at the location or variant I expect
Business Central's own native Inventory Setup toggles control whether Demand Forecast is evaluated by location and by variant at all. If those toggles are off, Business Central's planning engine reads the item-level forecast regardless of what ForecastQ wrote at a finer grain — check Inventory Setup first before assuming ForecastQ computed the wrong number.
What a Degraded readiness finding means
Degraded sits between Info and Blocked: planning will still run, but on a compromise — for example, an item with demand at several locations but no Stockkeeping Unit at one of them, so a per-location value has nowhere native to land and ForecastQ falls back to the item-level field for that scope. Read the finding's Message for the specific reason, and its Suggested Fix for the remedy; a Has Guided Fix of Yes means a one-click fix exists, run by a person, never applied automatically.
Getting help
Email us for product support. Include your Business Central version and the page you were on where relevant — it usually saves a round trip. For what ForecastQ reads, computes and stores, see the privacy policy.