How the numbers are made
The pipeline runs entirely on your own data, and every step is visible as a column — nothing is a black box:- Sales history — every order line counts as a sale (refunded and voided orders are excluded), summed per SKU across all your shops.
- Demand rates — units sold over the last 30 / 90 / 180 days become daily sales rates, blended with more weight on recent windows so a product that is speeding up or slowing down is seen early.
- Seasonality — a seasonal factor per calendar month, measured from your own history (you can override it). The factor is applied to the coverage window — the period the new stock will actually be selling in — not to today’s month. Ordering in October for goods that arrive before Christmas is planned with the Christmas factor, not the October one.
- Coverage — the forecast demand is held against what you have (stock on hand), what is already coming (open purchase orders and their arrival dates), and how long replenishment takes (supplier lead time + buffer + safety stock).
- One decision per SKU — the result is a single row in the Procurement Queue: a status, a recommended order quantity (respecting minimum order quantities and order multiples), the last sensible order date, and the reasons behind all of it.
The Procurement Queue
One row = one buying decision per tracked SKU. The same view answers two questions: unfiltered, it is the coverage overview of everything you track (“how long does each product last?”); filtered to Action Required, it is your order list.Statuses
The first matching rule wins:
Products that are paused, discontinued, or not marked as procurement-tracked never enter the queue.
Only ORDER_REQUIRED and ORDER_OVERDUE set
action_required = true — that filter is the working order list. Every row also carries reason codes (e.g. stockout before replenishment, open PO arrives too late, missing supplier) so you always see why a row has its status.
The ride-along rule
Shipping costs money, so the queue also answers: “while we are ordering anyway, what else should go into the same shipment?” A column called include in next shipment is true when a product’s last sensible order date falls inside its own replenishment window (lead time + buffer + safety stock) — even if it is not urgent yet. A healthy product with 68 days of runway and a 88-day replenishment window rides along with seven units, instead of triggering its own shipment a month later. The queue computes a recommendation for every row; the status only says whether it is urgent now.Reading the recommendation
The recommended quantity is derived transparently: target coverage (daily demand × target stock days) minus what you have minus what is already coming, then raised to the supplier’s minimum order quantity and rounded to the order multiple. Both the raw need and the final recommendation are shown — so “need 87, MOQ 100 → order 100” is a sentence you can read off the row.Purchase Orders
Where: DATA › Purchase Orders. One row per ordered item (order header and line combined). Rows carry the product name, variant, and supplier name as plain text — a purchase order is a record of what was ordered at the time, and stays readable even if the product is later renamed.Lifecycle
A draft already counts as open supply. As soon as a purchase order exists — even as a draft — its quantity counts toward what is “already coming”, and the queue stops recommending the same units again. This is deliberate double-order protection: without it, a draft written yesterday would be re-recommended today. The flip side: a forgotten draft holds the recommendation down, so drafts are shown in their own column and should be reviewed regularly. Expected arrival dates only come from orders actually placed — a draft promises no date.
Suppliers
Where: DATA › Suppliers. Master data per supplier: name, currency, default lead time (how long from order to arrival), a lead-time buffer for uncertainty (peak season, shipping delays), and target stock days (how much coverage an order should aim for). Products inherit these defaults; individual products can override them. Lead times drive the whole timing calculation — a 7-day supplier and a 120-day supplier get very different order dates for the same demand.The supporting analytics views
Each of these feeds or explains the queue, and each is a normal data view you (and your agents) can query:- Product Demand — the demand engine’s per-variant output: units sold per window, the weighted daily rate with seasonality removed, and the planned demand rate that actually goes into recommendations. Also shows current stock and days of coverage per variant. If you want to check why the queue recommends a quantity, this is the view that shows the arithmetic.
- Weekly Sales — units sold per product variant and calendar week, newest first. This is the raw trajectory behind every demand rate — use it to eyeball whether a product’s trend is real or a one-week blip.
- Family Trend — sales momentum grouped by model family rather than single SKU, seasonally adjusted. Rising and falling families are flagged with a confidence level, and percentages are suppressed below a minimum volume so tiny numbers can’t fake a 400% trend. A watchlist, not an ordering signal — trends never change recommended quantities on their own.
- Seasonality — the seasonal factor per calendar month and where it comes from: measured from your history, dampened while the history is short, or manually overridden. Overrides always win; everything else is computed live from your data.
- Customer Reorder Due — the retention side: repeat customers whose next purchase is statistically due, benchmarked against typical reorder gaps. Filter needs action for customers who are due and have not yet been contacted.