Stock Alerts is the list of places where stock has moved outside the rules set on a product's stock policy — below its safety level, past its reorder point, heading for a stockout, over its ceiling, nearing expiry, or being wasted faster than you allow.
Where to find it: Stock Alerts in the Demand Planning section of the main menu. The Open stock alerts figure under Site health on the Planning Cycle links straight here.
The list
One row per alert, ordered by product code to begin with. Any sortable column header re-sorts the list, the search box narrows it to one product, and the filter panel offers Alert Type (the six types that are raised), Severity, Status, Message, Acknowledged By and the three dates. Sorting, filtering and paging all ask the server, so a match on page four is still found.
| Column | Meaning |
|---|---|
| Product | The product the alert is about. |
| Alert Type | Which rule was breached — see the table below. The filter offers the six types that are raised. |
| Severity | How urgent it is: critical, warning or info. It moves both ways as the position changes — see Severity. |
| Status | Where the alert stands: Open, Acknowledged or Resolved — see The three statuses. The filter also offers Unresolved, which is open and acknowledged together: everything still true. |
| Message | The condition in words, naming the product and the figures involved. On an expiry alert it also names the batch, which has no column of its own. The column is readable in full — the whole sentence is shown, not a clipped first few words, because on several types the message is the only place the detail appears. |
| Current | What was measured when the alert was raised. On the four types that compare quantities it is stock on hand, in the product’s stock unit. On the two that do not, the cell says which measure it is rather than leaving you to guess — see Not every alert measures a quantity. |
| Threshold | The figure from the stock policy that was crossed. Blank on an approaching expiry alert, on purpose — see below. |
| Acknowledged By / Acknowledged At | Who marked it as seen — a person’s name, not an internal reference — and when. Blank until somebody does. The word System here means nobody did: see “System” in Acknowledged By. |
| Resolved | When the condition stopped being true. Blank while it is still true. Nobody sets this by hand; the nightly sweep does it — see Alerts resolve themselves. |
| Created | When it was first raised. An alert that is still unresolved is refreshed in place rather than repeated, so this is the date the condition started. |
The two headings say “Current” and “Threshold”, not “Current Qty” and “Threshold Qty”. Only four of the six alert types compare quantities, so a heading with “Qty” in it described a number of days as a quantity — which is simply the wrong number under the wrong name. The row now says which measure it carries, and the heading no longer has to describe every type at once. Sorting and the number filter still work on the underlying figure.
Not every alert measures a quantity
| Alert type | Current holds | How the row reads |
|---|---|---|
| below reorder, below safety, excess stock, stockout risk | A quantity | The number on its own, in the product’s stock unit, with the policy figure it crossed under Threshold. There is no unit on the row to print beside it, so none is shown. |
| approaching expiry | Days | The row says so in words: “14 days left”, “1 day left”, “expires today”, or “expired 3 days ago” once the date has passed. Threshold is deliberately blank. There is no quantity to compare with: the policy figure behind this alert is the product’s shelf life, and the warning fires at 20% of it, so printing that under “Threshold” would name a number nothing was compared against. The days left are the whole of what this alert measures, and the message carries the batch. |
| high waste | A percentage | Shown with its % sign, against the Waste Threshold % from the stock policy. |
“System” in Acknowledged By
“System” means the alert was closed by a data clean-up, not by a person. An older sweep could leave several open alerts behind for the same condition; a clean-up closed the duplicates, deliberately recording no name because nobody had read them.
That leaves an Acknowledged At timestamp with no name beside it, which reads as a person whose name failed to load. It says System instead, so the row states which it was. Anywhere a real person acknowledged an alert, their name is there — that is the only other way the column is ever filled in.
Alert types
Six types are raised. Each needs the relevant field set on the product's stock policy — a blank or zero field means that rule is switched off for that product.
| Type | Raised when | What to do |
|---|---|---|
| below reorder | On hand has reached or fallen below Reorder Point Qty. Critical at zero or less, otherwise warning. | Replenish: raise a purchase order for a bought item, or a batch for one you make. This is the alert that is supposed to fire in normal running — it is the signal to order, not a fault. |
| below safety | On hand has reached or fallen below Safety Stock Qty. Always critical. | Treat as urgent: the cushion itself is being consumed, so the next surprise has nothing to absorb it. Chase what is already on order before ordering more. |
| stockout risk | On hand, plus what is already on order and due inside Lead Time Days, minus the forecast demand over those days, comes out below the safety stock. Critical when it comes out below zero, otherwise warning. | The message names the day it happens and the next delivery: "projected to run out around 30 Sep; next delivery 2 Oct", or "next delivery none on order". Order now, pull a delivery forward, or move the stock in from another site. |
| approaching expiry | A batch's use-by date — or its best-before, where there is no use-by — falls within the last 20% of Shelf Life Days. One alert per batch, and only for a batch that still holds stock at this site. Critical once the date has passed, otherwise warning. | Sell it, use it in production, or dispose of it. Check FEFO is being followed: an expiring batch beside newer stock usually means something was picked out of order. |
| excess stock | On hand is above Max Stock Qty. Always info. | Cash tied up, and for short-life products a waste risk coming. Stop or reduce the next order, or check whether the ceiling is simply set too low for how the product now sells. |
| high waste | The share of the last 90 days' intake — what was received and what was produced — that has been disposed of is above Waste Threshold %. Always warning. The message reads, for example, "7.4% of stock wasted in the last 90 days (limit 5.0%)". | Look at the product's disposals for the period, and at whether the forecast is running high for it — over-forecasting a short-life product shows up here first. See Forecast Accuracy. |
A single product commonly raises two at once — below reorder and below safety — because breaking through the reorder point on the way down usually means breaking the safety level too. They are separate alerts because they call for different urgency.
The three statuses
An alert has a life, and the Status column says where in it this one is.
| Status | Means |
|---|---|
| Open | Still true, and nobody has said they have seen it. This is what an alert is raised as. |
| Acknowledged | Still true, and somebody has seen it. Acknowledging is a note that you know, not a fix. |
| Resolved | No longer true. The condition has cleared, and the Resolved column says when. A resolved alert asks nothing of anybody, so it stops offering the tick. |
Resolved wins. An alert that was acknowledged and has since cleared reads Resolved, not Acknowledged — what matters is whether the condition still holds.
“Unresolved” is open and acknowledged together: everything still true, whether or not somebody has looked at it. That is what the Status filter’s Unresolved option shows, and what Open stock alerts on the Planning Cycle counts — acknowledging an alert no longer takes it out of that figure, because acknowledging does not fix anything. The figure links straight here with the list already filtered to Unresolved, and a badge above the grid reads “Filtered to Unresolved” with a × to clear it.
Alerts resolve themselves
The nightly sweep does not only raise alerts; it closes them. For every product it could check, any unresolved alert of a type it did not raise again this time is resolved, and stamped with the time. Receive the stock and tomorrow morning the below-reorder alert is Resolved without anybody touching it.
- A type the sweep could not check is left alone. If a product’s on-hand could not be worked out, the answer is unknown, not “fine” — so its alerts stay as they are rather than being resolved on a guess.
- A product whose policy is switched off or deleted has its alerts resolved. There is no threshold left to breach.
- Nothing is ever deleted. A resolved alert stays on the list as the record of what happened and when it cleared. Filter Status to Resolved to read the history, or to Unresolved for the work.
Severity
| Severity | Read it as |
|---|---|
| Critical | Act now — supply is genuinely at risk, or the stock has already expired. Running out is treated as more serious than holding too much. |
| Warning | Worth attention before it becomes critical. |
| Info | Noted for awareness. Excess stock is the only type raised at this level. |
Severity moves both ways on an alert that is already unresolved. A below-reorder warning that gets worse and reaches zero is promoted to critical, and one that recovers from critical back above zero — while still under the reorder point — drops back to warning. Either way the existing row is updated, with its figures and its date refreshed; a second row never appears. A severity that only ever rose left yesterday’s panic on the screen after the stock had partly come back.
When alerts are raised
Every night, at 3am in your account's time zone, QTRACA sweeps each site's active stock policies and checks the six conditions above. The list therefore reflects the position as at that sweep rather than this second.
The sweep runs after the 2am forecast deliberately. A forecast recalculates the Safety Stock Qty and Reorder Point Qty on every policy set to Dynamic or Forecast Based, and the alerts check those new figures the same night — so the thresholds a product is measured against can move without anybody editing the policy. See Stock Policies.
Acknowledging an alert
Acknowledging records that someone has seen the alert and who they were. It is a reading action, not a fix — the underlying stock position is unchanged, and the alert stays in the list.
Use the tick in the Actions column at the start of the row. You are asked to confirm:
Acknowledge Alert
Acknowledge this alert for <product code>? It will be recorded against your name, and won’t be raised again during the policy’s review period unless it gets worse. It resolves by itself once stock recovers.
The alert then reads Acknowledged, shows your name and the time in Acknowledged By and Acknowledged At, and the tick is no longer offered on that row: an alert is acknowledged once, by one person, and re-acknowledging it later would overwrite who first saw it. The tick is not offered on a Resolved alert either — there is nothing left to acknowledge — and the server answers “Alert has already been resolved” or “Alert has already been acknowledged” to anything that tries.
An acknowledged alert is still true. It stays in the Unresolved count and in the Planning Cycle’s Open stock alerts figure until the condition actually clears. That is the point: acknowledging records that somebody has read it, and the figure measures what is still wrong.
Alerts are never deleted. The history of what was flagged, when, who acknowledged it and when it resolved is kept. Acknowledging is the only change you can make here.
The quiet period
A nightly sweep does not mean nightly duplicates. Two rules keep the list readable:
- While an alert is unresolved and unacknowledged, it is refreshed rather than repeated. The same condition found again tomorrow updates the existing row’s message, figures, severity and date — a stockout alert goes on naming the day it now expects to happen, rather than a date already past. You never get a second row for the same product, type and batch.
- Once you acknowledge it, it stays quiet for the policy’s Review Frequency Days. Inside that window the condition is not raised afresh — unless it becomes more severe, which resolves the acknowledged one and raises a new alert straight away. After the window, if the condition is still true, the acknowledged alert is resolved and a fresh one takes its place, back at Open: acknowledging is a note that you have seen it, not a promise that it is fixed.
- And if it clears, it resolves itself — acknowledged or not. See Alerts resolve themselves.
A Review Frequency Days of 0 or blank means no quiet period at all, so an acknowledged condition can be raised again the next night.
Where the thresholds come from
Every threshold on this screen is a figure from the product's stock policy for the current site. If a product raises no alerts at all, the usual reasons are:
- It has no policy, or its policy is not Active.
- The relevant field on the policy is 0 or blank, which switches that rule off.
- Its policy is at another site. A policy set at one site never raises an alert at another, even for the same product code.
- Its stock cannot be counted in one unit. When some of a product's stock is held in a unit or pack that cannot be converted to its stock unit, the on-hand figure is unknown rather than smaller, so no alert is raised for it. The policy says so in the line above its form: "No conversion from CTN to KG for Custard Square; stock alerts paused". Add the missing unit conversion and the next sweep clears it.
Availability and permissions
Stock Alerts needs the Demand Planning module, which itself needs Manufacturing and Orders — see Getting started with Demand Planning. Viewing the list and acknowledging an alert are open to any user with a role. Alerts cannot be created or deleted by anyone.
A site is not a security boundary. The site selector decides which site’s alerts you are looking at and acting on, and it keeps another site’s 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 alerts. 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
- "Forecast deviation" is not raised. The type exists in QTRACA's data but nothing creates one, and it is deliberately left out of the Alert Type filter so you are not offered a filter that can only ever come back empty. Use Forecast Accuracy to see where the forecast is drifting from reality.
- An expiry alert needs stock in the batch. A batch that has been consumed to nothing keeps its status and its date, but there is nothing left to throw away and nothing anybody can act on, so it raises no alert. This is why a long list of ancient expired batches does not turn into a long list of alerts.
- A stockout risk needs a lead time and a forecast. With Lead Time Days at 0, or with no completed forecast covering the days ahead, there is nothing to project and the check is skipped. It also refuses to guess: an incoming order quantity that cannot be converted to the stock unit pauses the check rather than being counted as zero.
- Alerts are per site. They are raised against stock at a particular site, using that site's own stock policy — each site's equipment, stock and thresholds are its own.
- Acknowledging is the only place it can be done. The old Recent Alerts panel on the demand planning landing page has been removed; the Planning Cycle shows the unresolved count and links here with the list already filtered.
- Filtering and sorting act on the whole list, not the page you can see. Searching a product code or sorting a column asks the server for the matching alerts, so a match on page four is still found.
- There is nothing to fix here. This screen reports; the response is a purchase order, a batch, a stock movement, a disposal, or a change to the policy itself.