qtraca.com

A forecast run projects expected demand for every product that has a stock policy, across a horizon of weeks. It is the expected side of a demand plan — the other side is what customers have actually ordered. It is also step 1 of the planning cycle: everything after it is planned from this number.

Where to find it: Forecasts in the Demand Planning section of the main menu, or step 1 of the Planning Cycle.

The words used here

Quick start

1. Check you are working in the right site. A run covers the site you are in and nothing else.
2. Open Forecasts and press Run Forecast.
3. Wait a few seconds and reload. The run moves from Running to Completed.
4. Open the run. Read the chart and the results table, and filter to a product if a number looks wrong.
5. Press Generate Demand Plan on the card at the top of the run.

Running a forecast

Press Run Forecast. The run is created straight away and the calculation happens in the background, so the screen comes back immediately with the run showing as Running. Reload to see it finish.

There is nothing to fill in first. The horizon, the history and the forecasting method all come from each product's stock policy, and the account-wide starting values for those live in Forecast Settings.

The run joins this week's planning cycle, opening one if the site has none. A forecast started from the Forecasts screen is not a new week — it is a refreshed number for the week already open. Once it completes it becomes the run in force, and the cycle asks you to generate the demand plan again from it.

Only products with an active stock policy are forecast. A product with no policy, or an inactive one, is skipped entirely, and so is a product whose history holds nothing to project from.

What a product learns from

A product is either sold or consumed, never both, and which it is decides what its forecast is built on:

• Consumed — a raw material or packaging item that a batch at this site has ever recorded consuming. Its forecast is built from that consumption, which is what actually happens to it.
• Sold — everything else. Its forecast is built from dispatches, falling back to confirmed sales orders for a week with no dispatches, exactly as before.

“Ever” is the whole of that test, and it is deliberate. The question is decided on the product’s entire history, not on the window the run happens to be looking at. A material sold last year and only recently taken into batches used to answer “sold” one week and “consumed” the next as the window slid over the changeover, so two runs a week apart trained on different signals for a reason nobody could see in the numbers. The window now decides only which weeks of that signal the forecast learns from, never which signal. The site scope stays: a material consumed at another plant is not consumed at this one.

A consumption forecast never feeds the demand plan. The production plan already works out how much of a material the finished goods will consume, by exploding their recipes; taking the consumption forecast as demand as well would plan the same usage twice. The forecast is still produced, and is still what safety stock and accuracy are measured on — it simply is not demand.

Why a consumed material is missing from the demand plan

This is the question the classification raises most often, so it is worth stating outright: a material a batch has ever consumed has a forecast, but no line of its own on the demand plan. Open the forecast run and it is there, with its own Forecast Qty, Confidence and Method. Open the demand plan generated from that run and it is not, unless a customer order or a sales contract puts it there.

That absence is the design, not a missing row. The material is planned one step later instead: the production plan explodes the recipes of the finished goods that use it, and the quantity that comes out of that explosion is what procurement buys. Planning it twice — once as its own forecast demand, once as the usage its parents explode into — would order roughly double.

Two consequences follow, and both surprise people the first time:

• An adjustment on a consumed material does nothing to the demand plan either. An adjustment cannot be a second way in for demand the explosion already covers. The one exception is a material that also has confirmed orders or a sales contract: that demand is independent, the product is on the plan for that reason, and the adjustment belongs to it.
• To change how much of it is bought, change the finished goods’ forecast or the recipe, not the material’s own figure. Its requirement is derived, and a derived figure cannot be overridden where it is displayed.

A product is skipped, and counted as skipped on the run, when every week of its history is zero: a statistical projection needs something to project from, and a zero forecast would read as a real prediction of nothing. A consumed product whose consumption is held entirely in a unit with no conversion to its stock unit is refused and named, with the reason on the run — it is never quietly forecast from its dispatches instead.

How one unusual week is handled

Before the projection runs, each week of history is held to a band drawn around a typical week, so a single freak order cannot set the number for every week that follows. A week above the band is counted as the top of the band, a week below it as the bottom (never below zero), and the week is flagged as an outlier on the run. The statistics reported for the run — mean, standard deviation, median and deviation — describe the history as it arrived, before any capping, so you can still see the spike that was held.

The band is now measured from the typical week, not the average. It is drawn from the median week and the median absolute deviation — the typical distance from that typical week — rather than from the mean and standard deviation. The old measure had the fault the cap exists to correct: a big enough spike dragged the average towards itself and widened the band by more than the spike stood out, so the one week worth capping was the very week that widened the band past itself. A spike cannot widen the new measure: it moves one distance, not the middle one. On an ordinary series the two agree, and three of the new deviations still means what three standard deviations always meant.

Six weeks of history is now enough for the cap to work. It used to need eleven. Not because eleven was chosen, but because a single week can never be more than a certain distance from the average of a short series — below eleven weeks nothing could reach the threshold and the cap never fired at all, leaving exactly the short series a one-off order distorts most completely uncapped. Below six weeks the cap still stays out of it: with five weeks or fewer an unusual week is a fifth of the evidence, the typical week follows it, and the band would be drawn around the very week it is meant to hold.

A series with no spread at all — a product that ships exactly the same amount every week — is left alone. That is an ordinary product, not a degenerate one, and a band of zero width would flag and flatten every week that differed at all.

Intermittent demand is left exactly as it arrived

A product that sells in more weeks than it does not is a steady series with the occasional odd week in it. A product with more empty weeks than selling weeks is not. It is intermittent demand — something ordered now and then — and the weeks it does sell in are the demand, not departures from a typical week.

Where the typical week is zero, no band is drawn and no week is capped. Holding those selling weeks to a band centred on zero would erase the history rather than tidy it, which is what used to happen: every real order was treated as an outlier and flattened, and the product was forecast as though it barely sold.

What will look different on your first run after this update

This change moves figures, and it moves them in both directions. Compare a run from before the update with the first run after it and you will see this:

It is a one-off step at this release, not a drift. Forecast Accuracy shows the same step at the same point. Compare runs from after the update with each other, not with runs from before it.

The run list

Run status

Reading the results

Open a run to see the Forecast Run Detail header (Run Date, Type, Status, Horizon Start, Horizon End), then the Forecast Chart, then the Forecast Results table with one row per product per period.

The chart shows one line per product, highest volume first, with a legend naming each by product code. At most eight products are drawn; when there are more, a caption under the chart reads "Showing the 8 highest-volume products; N more are in the table below. Filter by product to chart one of them."

Filter by Product narrows the table to one item and redraws the chart for that product alone. Only then does the chart add the confidence range as a shaded band, and an Actual line where actuals exist — several overlapping bands obscure more than they reveal. A run with no results at all shows "No forecast results for this run" in place of the chart, and "No forecast results available" in the table.

Adjusting the forecast

The forecast only knows what has sold before. When you know something it cannot — a promotion, a new product, a customer who has told you they are cutting back — add an adjustment in the Forecast adjustments panel on a forecast run. The panel covers the weeks that run covers, and reads “No adjustments for these weeks.” until there is one.

Add adjustment opens a short form, under the line “Adjustments are added to the forecast the next time a demand plan is generated. Plans already generated are not changed.”

Saved adjustments are listed underneath with Product, Week starting, Adjustment (signed, with the unit), Reason and By — the person who last changed it — and an Edit and a Remove button on each row.

An adjustment belongs to the site, the product and the week, not to one run. It carries into the next forecast, and it is used the next time a demand plan is generated. Plans already generated are not changed. On the demand plan, the Forecast Qty column stays the statistical forecast and the Adjustment column shows what was added, with a note on the line such as “Forecast adjusted +500 by planner: Easter promotion”.

The adjustment is applied where the forecast is read, before anything else uses it — so a call-off contract competes with the adjusted forecast, not the raw one. Total demand is still the greater of confirmed orders and the larger of forecast and call-off.

A reduction never takes the forecast below nothing: an adjustment of −150 against a forecast of 100 plans 0, and the line records −100 — the part of the reduction that actually landed — as the adjustment. Where there was no forecast at all to reduce, the line says so rather than printing a misleading “+0”: “Forecast adjustment of 150 by planner not applied: no forecast to reduce (Discontinued line)”.

There is one adjustment per product per week; to change it, edit it. Adding a second is refused with “FG-TART already has an adjustment for the week of 6 Oct 2026; change that one instead.” Remove asks first — “Remove the adjustment for FG-TART, week of 2026-10-06? Demand plans already generated keep it; the next one will not.” — and the removal itself is recorded, and kept, because taking an adjustment away moves the next plan by its whole amount.

Adding an adjustment and changing one are recorded too, for the same reason and more so: editing −100 to +500 moves the next plan by 600, where removing −100 moves it by 100, and the adjustment itself only ever shows the figure it now stands at. The record names the quantity and the reason, and for a change both the old value and the new. All three records are held against the adjustment rather than against a plan, so they outlive the row they describe — and so none of them is an entry on a plan’s Activity panel.

A removal that fails says so on its own line above the list — “The adjustment could not be removed.”, or the server’s own reason — and the list itself is left alone.

The panel asks for the weeks its run covers. A window longer than two years is refused with “Ask for at most 104 weeks of adjustments at a time.”

Generating a demand plan

A completed run changes nothing downstream by itself. The card at the top of the run detail is what turns it into a plan:

Generating always produces a draft. Nothing becomes active without somebody activating it, so a plan already in force is untouched until you activate the new draft — and a generation that fails leaves the plan in force exactly as it was. Activating the draft is what supersedes the site's other active plan. The same action is offered as Generate demand plan on step 2 of the Planning Cycle.

Double-clicking cannot make two plans. A second request while one is still running is refused with "A demand plan is already being generated for this run.", and a request against a run that has not finished with "The forecast run has not completed."

The demand plan itself carries an Export CSV button in its toolbar and an Activity panel at its foot, like the production and procurement plans — but with words of its own, because it has statuses of its own: Created, Activated, “Superseded when DP-… was activated” and Archived. The export carries one row per product per week, with Forecast and Adjustment in separate columns. Both are described under Exporting a plan, and its activity on the demand plan page.

What a run changes behind the scenes

Two things happen after every run, whether you started it or the schedule did:

• Accuracy is brought up to date first. Any forecast period that has closed since the last time is scored against what actually happened, which is what fills Actual Qty and Variance %. This happens even on a day when no forecast is due.
• Stock policies are recalculated after a completed run. Every active policy on the site whose Reorder Point Method is Dynamic or Forecast Based has its Safety Stock Qty and Reorder Point Qty worked out again, and stamps the date under Last calculated. Policies set to Fixed keep the numbers you typed. Because those figures are also the thresholds stock alerts use, a forecast can change which products alert the next night. See Stock Policies.

Neither can stop a forecast being produced: a failure in either is logged, and costs you a stale figure rather than the forecast itself.

Where AI insights and recommendations is switched on in Forecast Settings and AI credit remains, one analysis is run per planning cycle — not after each step. It runs after the production plan is generated, and reads the forecast and demand plan behind that plan as well, so it sees the whole cycle rather than one part of it. Its summary appears as AI Summary on the production plan and on its demand plan; anything it suggests turns up in AI Recommendations. A completed forecast run is no longer analysed on its own, so a run has no AI Summary of its own any more.

Running a forecast again

A forecast you ask for always runs. Pressing Run Forecast a second time on the same day is not refused and is not recorded as a failure — it replaces today's numbers with numbers built on whatever has changed since, which is the whole point of re-forecasting after a batch of new orders lands.

A new run means the plans below it are out of date. While the new run is still calculating, the last completed run stays in force and its demand, production and procurement plans stay on the Planning Cycle. The moment the new run completes it becomes the run in force, the cycle drops back to step 2 ("Generate demand plan") and every later step waits — even though the plans you approved still exist. Regenerate the demand plan from the new run and work forward again. Running your weekly planning cycle explains what to do with the older plans.

Runs that happen on a schedule

With Scheduled forecast runs ticked in Forecast Settings, QTRACA runs the forecast overnight, at 2am in your account's time zone, for every site, on the frequency and day set there. Those runs appear in the list with type scheduled. The settings screen says it plainly: "Runs the forecast overnight (2am your time) on the day below. You can always run a forecast yourself."

Scheduled runs only happen for accounts that hold Demand Planning. Accuracy scoring follows the same rule.

When a run fails

A product that cannot be forecast is logged and the run carries on with the rest, so one bad product does not cost you the whole forecast. A run is only marked Failed when nothing at all came out of it.

On the Planning Cycle the forecast card shows a warning triangle and the step reads one of:

• "N products could not be forecast:" followed by the first reason — usually a product whose history cannot be read, for example a quantity in a unit with no conversion to the product's stock unit.
• "The forecast run failed." when the run recorded no reason of its own.

Pressing Run forecast again is the fix for almost all of these, once whatever it named has been corrected. A failed run is left in the list as the record of what happened.

Availability and permissions

• Demand Planning is a module in its own right, and it needs Manufacturing and Orders as well. See Getting started with Demand Planning.
• Viewing forecast runs and their results is open to any user with a role.
• Run Forecast needs the admin or production manager role.
• Generate Demand Plan is governed by the permission to create a demand plan: admin, production manager or demand planner.
• Adjusting the forecast needs the admin, production manager or demand planner role. Anyone who can see demand plans can see the adjustments.
• A site is not a security boundary. The site selector decides which site’s figures you are looking at and working on, and it keeps another site’s runs, plans and stock out of your way. It is a working scope, not a wall: a user who can open this screen and change site can read that site’s figures. The real boundary is the account — nothing belonging to another account is reachable at all. Do not use sites to keep figures from a colleague; use roles.

Things to know

• Forecasting is per site. A run covers the site you are working in: the products it forecasts are the ones with an active stock policy at that site, and each product is forecast from its own history. Because a product record belongs to one site, that history is that site's. A product shared across sites — one with no site of its own — is forecast at every site that gives it a policy, and each of those runs reads the same whole-account history, so the same expectation appears at each site rather than being divided between them. Consumption history is always read for the site being forecast.
• A run is a snapshot. It reflects history as it stood at the time, which is what makes two runs comparable — and why changing a stock policy does not alter a run that has already finished.
• Runs cannot be edited or deleted. A completed run is the record behind any plan built on it, so the basis of a plan cannot change underneath it.
• Products with no history are skipped, not forecast as zero — a statistical projection needs something to project from, and a zero would read as a prediction. The run counts how many it skipped. Skipping the forecast does not remove the product from the plan: a product with confirmed orders or a sales contract is still planned from those, because they state the demand outright; see Demand planning: how demand is calculated.
• A quantity that cannot be converted is left out, never counted as zero. If a product's history is held in a unit with no conversion to its stock unit, that part of the history is excluded and named in the log rather than quietly read as the stock unit.
• A one-off order no longer sets the forecast. Each week of history is held to a band drawn around the typical week: a single order of 1,000 against a run of tens is counted as the cap, not as 1,000, and a week that low in the other direction is lifted to the floor (never below zero). Outliers were worked out and then ignored, so one unusual week could set the number for every week that followed. See How one unusual week is handled for what it now moves, in which direction, and for which products.
• Intermittent products are no longer flattened. A product with more empty weeks than selling weeks is left exactly as its history arrived, so its forecast rises at this release. It is the one change here that moves a figure upwards, and it will look like a jump. Nothing has been added to it: its real orders simply stopped being erased.
• A product cannot switch between consumption history and sales history from one run to the next. Which of the two it learns from is settled on its whole history, not on the window in view. A material any batch has ever consumed is forecast from consumption for good.
• Forecasts for trending products change with this release. Two faults in Seasonal Decomposition have been fixed: its trend was measured over one stretch of history and then read off at a different point, which over-forecast any product with a rising or falling trend by half a season (about two weeks on a monthly shape, twenty-six on an annual one); and its confidence range was worked out as a ratio and then printed as if it were a quantity, so the Confidence Lower and Confidence Upper figures were meaningless on that method. The first run after the release moves every trending product's numbers, usually downwards, and Forecast Accuracy shows a step change at the same point. That is the fix landing, not the forecast getting worse — compare runs from after the release with each other, not with runs from before it. The outlier capping above moves numbers at the same time, on a different set of products.
• Only four methods can be chosen — Moving Average, Weighted Moving Average, Exponential Smoothing and Seasonal Decomposition — and the choice is per product, on its stock policy.