Help & documentation

Everything that goes into a reorder decision, what each metric means, and how to make stocura work for the way you run your business.

This is the long-form companion to the in-app tooltips. If you clicked a "Learn more →" link, you've landed in roughly the right place — each tooltip's anchor matches a section heading here, so you can also use the table of contents on the left.

If something isn't covered or doesn't match what you're seeing, send a note via ? → Get support in the app.

Core concepts #concepts

stocura sits between your inventory system and your team. It pulls live stock numbers, learns from your sales history, and tells you what to reorder and when. The promise is simple: never run out of stock you should have, and don't tie up cash on stock you shouldn't.

To do that well, the system distinguishes a handful of concepts that look similar but matter differently.

SKUs, products, and parents

A SKU is a stock-keeping unit — the smallest thing your warehouse counts. Some SKUs are finished products you sell; others are raw materials or components that go into finished products. stocura tracks any SKU your inventory system tracks.

Stock levels

Three numbers describe your stock at any moment. They look similar but answer different questions:

• Available — what you can sell right now.
• On Hand — what's physically in the warehouse.
• Allocated — what's been promised to existing orders but hasn't shipped yet.

The relationship: Available = On Hand − Allocated. If you have 100 on hand and 30 are tied to open orders, only 70 are available to promise to the next customer.

Suppliers, lead time, MOQ

Each SKU is bought from a supplier. The supplier has a lead time (days from when you place the order to when stock arrives) and often a minimum order quantity (MOQ). stocura uses lead time to work out when to reorder, and MOQ to round order quantities up to the smallest amount your supplier will accept.

The reorder point

The single most important number in stocura. The reorder point is the stock level at which the system says "place a new order now." It's calculated to give you just enough buffer that the next batch lands before you run out — no more, no less.

How it's calculated is the topic of the next section.

The pages #pages

stocura is organised around four screens you'll touch every day. This section is a quick orientation to each one — what it's for, how to read it, and what to do when something looks off.

The Reorder Queue

The home page. A daily checklist of SKUs that need attention. Healthy SKUs aren't shown here — see Stock Overview for the full list.

The queue is split into two priority buckets:

• Order Now — at or below reorder point, no PO placed yet, supplier is domestic. These need action this week.
• Needs Review — supplier is out of stock, awaiting inventory sync, or international SKUs below threshold (which order via container 2-3 times a year, not as one-offs).

SKUs already on order are hidden — once a PO covers the threshold, the queue stops nagging. The Suggested Qty column tells you how much to order: enough to cover lead-time demand plus a buffer, rounded up to MOQ and pack size. Click Order Now on any row to start the PO with that SKU pre-selected.

Filters at the top let you split the queue by domestic / international suppliers — useful when domestic and container ordering are run by different people.

Stock Overview

Every active SKU at a glance — sortable by any column, filterable by supplier and search. Use this when you want a complete picture rather than just the reorder queue's priority subset.

Three column families:

• Stock levels — Available, On Hand, Allocated, On Order. The first three describe what's in your warehouse right now; the last is what's coming.
• Decision metrics — Reorder Point and Days Cover. These tell you whether the SKU is in trouble or healthy at the current sales rate.
• Operational — Notes, Stock Synced (when we last pulled live numbers from your inventory system).

The summary cards at the top give a roll-up: how many SKUs total, how many are out of stock, total available units across all SKUs, total on order. Useful for catching the day a supplier delivery is delayed and your "Out of Stock" count creeps up unexpectedly.

To configure a SKU, click its name to open the SKU Detail page.

The SKU Detail page

The deepest-dive view. Everything stocura knows about one SKU. Four sections, top to bottom:

• Stat cards — current numbers: stock levels, reorder points, projected order date, 3-month forecast. Hover any label for an explanation.
• Charts — sales movement over the last 12 months (with 3-month forecast overlay), 14-day daily activity, wastage and adjustments.
• Product Info — reference data: lead time, supplier, last PO, typical order size, when the SKU was first seen.
• Configuration cards (collapsed by default) — SKU Configuration for lead time, MOQ, pack size, reorder source, seasonality, and lifecycle status. Demand Boost for short-term campaign multipliers and the boost history.

If you're new to a SKU, the order to read it is: stat cards (what's the situation?) → Product Info (any context I'm missing?) → charts (what's the pattern been?) → configuration (anything I should change?).

Dashboard home

The first screen after sign-in. A high-level read on the whole operation: how many SKUs need ordering, how many are out of stock, how many active POs are in flight, total stock value, slow-moving count, and what's in staging. Each stat card is a link to the page that handles it.

Below the cards, three at-a-glance panels:

• Stock Movement — daily units sold over the last 28 days. Spot quiet weeks, sudden spikes, or trend reversals.
• Top Movers / Top Wastage — what shifted most in the last 14 days, sales-side and loss-side. Useful for catching products that are unexpectedly hot, or unexpectedly leaking.
• Recent POs / Open Notes — last five POs with activity and the most recent unresolved SKU notes. A "where am I picking up from" reminder.

Bottom of the page is the Forecast Accuracy strip — a calibration check on how well the forecasting engine has been doing.

Slow Moving items

SKUs that aren't pulling their weight. Each one needs a decision: keep watching, discount, bundle into something else, liquidate, or mark for discontinuation. The page is structured to make those calls quickly.

Two summary numbers at the top: total slow-moving SKUs, and how many of those still need a decision applied. The table is sorted with pending decisions on top, so each session you start at the work that needs you. See how slow-moving is detected and decision tags below for details.

Suppliers

The home of supplier records and the launching pad for orders. Three views from this one page:

• List (/suppliers) — every supplier with active SKUs, plus their currency, country, lead time, and ordering method. Click any name to edit, or the Order button to start a PO.
• Detail / edit (/suppliers/:id) — basic info, contact details, ordering method, currency and tax, lifecycle status, lead-time learning, DEAR aliases, and quick stats. Use this to onboard a new supplier or correct details after a PO has gone through.
• Order (/suppliers/:id/order) — a build-the-PO grid showing every SKU sourced from this supplier with suggested order quantities pre-filled. Edit qtys, set the expected arrival date, click Review Order to see the summary, then confirm — the PO lands in DEAR as a Draft.

Domestic suppliers and international suppliers use slightly different ordering UX — international (container) orders show months-of-cover and cover %; see international ordering.

Purchase Orders

Every PO that's been synced from DEAR, grouped by supplier. Two tabs:

• Open POs — placed but not yet fully received. Active inventory in the pipeline.
• All POs — full history including received and cancelled.

Per-line columns show qty ordered, qty received, unit price, and the latest receipt date. The Lines with Recent Changes stat at the top tells you how many lines had a quantity, price, or status change since the last sync — see PO changes. For partial-receipt mechanics see PO receipts. DEAR is the source of truth for prices and quantities; this page reflects DEAR's current state and surfaces the changes worth attention.

Wastage / Adjustments

All stock adjustments from DEAR — wastage, breakage, recounts, found stock, every signed correction to on-hand. Five summary numbers at the top: units lost, units gained, adjustment count, total line items, unique SKUs affected.

Filter by date range (presets for 7d / 30d / 90d / 12mo / All time), by SKU, by supplier, by type (loss only / gain only). Group flat to see the full transaction line view, or by SKU for a per-product roll-up with a Net column. Include voided brings in DEAR adjustments that were created and then voided — usually data-entry corrections — useful for full-trail audits but excluded by default. Download CSV from the toolbar.

How the reorder calculation works

The reorder point answers a single question: at what stock level should I place a new order so that my next stock arrives before I run out?

The basic math:

Three inputs, all derived from your data:

• Avg daily demand — how many units you sell per day, averaged over the trailing 12 months.
• Lead time — days from placing an order to stock arriving. stocura uses your SKU-level setting first, falling back to the supplier-level default.
• Safety multiplier — a buffer that scales with how much data we have. More data = lower buffer, because the average is more reliable.

That's the standard calculation. The system applies several adjustments on top:

• Seasonal lift — raises the reorder point ahead of detected high-demand windows (Christmas, Valentine's, Father's Day, etc.) so you start ordering early enough to land stock before the peak.
• Demand boosts — user-configured short-term multipliers for campaigns or other known demand events.
• Typical order size floor — ensures the reorder point never sits below the typical order size, so stock can't get "stuck" just below what customers want to buy.
• Manual override — lets you hard-set a reorder point when you know better than the data.

Each of these is explained in detail in the sections below.

Stock levels reference

Available

Stock you can sell right now — on hand minus what's already allocated to open orders. This is the number that matters for "can I take this customer's order?"

If Available drops to or below your buffer stock setting, the SKU is considered effectively out of stock.

On Hand

Total units physically in the warehouse, including any tied to existing orders. This is what you'd count if you walked the shelves.

Allocated

Units already promised to existing orders but not yet shipped. This is the gap between On Hand and Available — physically present, but not yours to sell again. The relationship: Available = On Hand − Allocated.

On Order

Units currently on a placed purchase order, due to arrive. The system uses this when computing days cover and projected order dates so you don't double-order something that's already on its way.

Avg Cost (DEAR)

Average cost per unit pulled from your DEAR / Cin7 Core inventory system. Updates daily. Used for cost calculations across the app but not for any reorder logic.

Days Cover

How many days of stock you have at the current sales rate, including units already on order. Calculated as:

This is your runway. A SKU with 30 days cover doesn't need urgent attention; one with 3 days does.

Stock Synced

Last time we pulled live stock numbers from your inventory system. The hourly sync runs automatically — if this timestamp is more than a few hours old, something's wrong with the sync. Check the Admin page for sync status.

Demand reference

Avg Daily Demand

Average daily sales over the trailing 12 months. The basis for almost every reorder calculation. Updates as new sales data comes in.

For SKUs with less than 12 months of data, we use whatever's available and apply a higher safety multiplier (see the reorder calculation section).

Typical Order Size

Average units sold on days that had any movement, over the last 90 days. This is a different question from avg daily demand — it's not "how much do you sell per day on average," it's "when something does sell, how much typically goes out at once."

Why this matters — the stuck-stock failure mode:

To prevent this, stocura uses Typical Order Size as a floor on the reorder point. If your calculated reorder point is below the typical order size, the system lifts the reorder point to the typical order size.

Confidence rules: we need at least 5 days of movement in the last 90 to apply this as a floor. With fewer days, the average is too unstable to trust — we display the value but don't act on it.

3-Month Forecast

Expected total unit demand over the next 90 days, factoring in seasonality and trend. This is informational — the reorder calculation uses it for some decisions (peak-aware seasonal lift) but the headline forecast number you see is the sum across the next quarter.

Reorder logic reference

Reorder Point (Standard)

The basic reorder point: lead-time demand plus a confidence-weighted safety buffer. See how the reorder calculation works for the formula and a worked example.

Reorder Point (Seasonal)

The standard reorder point adjusted for seasonal patterns in your sales data, then floored at typical order size. The system uses whichever of the two reorder points is higher when triggering alerts.

Seasonal lift kicks in three different ways:

• Standard — no seasonality detected, or a flat period. Reorder Point (Seasonal) equals Reorder Point (Standard).
• Shifted — stock you order now will arrive during a high-demand window. We use forecast demand for the arrival period, not trailing average, so you order enough to cover what's coming.
• Peak ahead — a high-demand window starts after stock would arrive. We use lookahead forecast to lift the reorder point now, so you start ordering early enough.

The goal is the same in all three: by the time the new stock lands, you have enough to cover whatever's actually about to happen, not whatever happened last month.

Reorder Source

Controls which reorder point the system actually uses to trigger alerts. Three options:

• System — always use the calculated reorder point. Best for SKUs with 6+ months of clean sales data.
• Manual — always use the value you set in Manual Reorder Point, ignoring whatever the calculation says. Best for SKUs where you know better than the data — one-off products, contractual minimums, etc.
• Blended (default) — use your manual value until 6 months of data accumulates, then auto-graduate to the calculated value. Best for new SKUs where the calculation isn't reliable yet but will be eventually.

Blended is the default for all new SKUs because it gets you set up quickly without locking the SKU into permanent manual mode. When a Blended SKU graduates to System, the system stamps the date and emails you so you know it's happened.

Manual Reorder Point

Your hard-set reorder threshold. Used when Reorder Source is Manual or Blended. The system shows the calculated value alongside it as a reference, so you can compare your guess to what the data suggests.

For new SKUs (in staging status, with no movement history), this field is required — the SKU can't move to active until you've given it a reasonable starting reorder point.

Seasonal Reorder Adjustment

How aggressively the system applies seasonal lift on this SKU. Three options:

• Auto (default) — lift reorder points during detected peaks, fall back to standard otherwise.
• Always enabled — lift even when seasonality is mild. Useful for products with subtle but real seasonal variation that the auto-detector might miss.
• Disabled — never apply seasonal lift. Useful for one-off viral spikes you don't want repeated next year (the seasonality detector would otherwise treat the spike as a recurring pattern).

Seasonality Override

Force a specific seasonality category instead of auto-detecting from sales data. The system supports categories like Christmas, Valentine's Day, Father's Day, Mother's Day, Easter, and several others.

Useful when you know the product's seasonality but don't have enough sales history yet for the system to detect it — e.g. a Christmas-themed SKU launched in March will look flat until October at which point you'll be too late.

Projected Order Date

Best estimate of when stock will hit the reorder threshold, based on current sales rate and any units on order. Calculated as:

Then projected to a date. Useful for cash-flow planning — lets you see at a glance which SKUs need ordering this week vs next month.

Demand boosts

A demand boost is a short-term multiplier you apply when you know demand is about to spike for reasons your historical data can't see — running a Meta campaign, doing a wholesale push, having a product featured in a publication. The boost lifts your reorder point for the duration of the boost so you don't run out mid-campaign.

Multiplier

How much more demand you expect during the boost. 2× means twice the normal sales rate. The number is multiplied through into the reorder calculation, so a SKU with avg daily demand of 0.6 and a 3× boost is treated as if avg daily demand were 1.8 for the duration of the boost.

Boost stacks with seasonal lift. If you boost a SKU during its Christmas peak, both the seasonal index and the boost multiplier apply — the math is correct, but be careful about double-counting.

Window (Starts and Ends)

Boosts run from the start date at midnight to the end date at end-of-day, in your tenant's local timezone. So a boost ending "11 May" runs through all of 11 May Sydney time and stops at midnight Sydney on the 12th.

You can't backdate a boost — if the end date is in the past, the boost would have no effect on future calculations.

Reason

Optional but recommended. A short note about why you're boosting — campaign name, channel, product feature. The reason shows up in the boost history table and in the boost-ended digest email so you have context when reviewing whether the boost worked.

Set vs Actual

After a boost ends, the system computes how much lift actually happened by comparing average daily outflow during the boost window to the 30 days before. The result becomes the Actual column in the boost history.

This is the system holding a mirror up to your campaign forecasts. Over time, you build intuition for what multipliers your campaigns really drive.

"Low confidence" appears when the boost ran for fewer than 5 days or the SKU's baseline outflow was very low — both make the ratio noisy. Treat low-confidence numbers as directional only.

Supplier and ordering reference

Lead Time

Lead Time (Config)

Days from placing a purchase order to stock arriving. Used in every reorder calculation — lead time directly determines how much lead-time demand the reorder point needs to cover.

You can set lead time at the SKU level (overriding the supplier default) for cases where one product takes longer than the supplier's typical timeline. If the SKU-level field is blank, the system falls back to the supplier-level setting.

MOQ

Minimum Order Quantity. The smallest amount your supplier will accept on a purchase order. Order quantities are rounded up to the next multiple of MOQ.

Pack Size

Units per pack. If your supplier sells in cartons of 12, pack size is 12, and orders are rounded up to whole cartons. Pack size is applied after MOQ, so the final quantity respects both.

Buffer Stock

Optional safety floor. Stock at or below this level counts as effectively out of stock — useful when you always want to keep a minimum on hand for VIPs, sample fulfillment, or pre-orders.

The setting can be configured globally (in Admin) and overridden per-SKU. Leaving the per-SKU field blank uses the global default.

Last PO Date

When the most recent purchase order for this SKU was created. Note: this is when the order was placed, not when it arrived. See Days Since Received for arrival.

Last PO Qty

How many units were ordered on the most recent purchase order. Useful for sanity-checking the system's typical order size floor — if every PO is for 1,000 units but customers only order 5 at a time, the floor probably doesn't need to be very high.

Days Since Received

How long since stock last arrived from a supplier. Goes amber after 6 months — possibly a stale supplier relationship worth reviewing, or a SKU you're winding down without realising.

Lead Time Learning

Compares actual lead times (order placed → stock arrived) against the supplier-stated lead time. Once a few completed POs are recorded, you'll see Avg Actual, Avg Variance (how much late or early), and the min/max range on the supplier detail page.

What to do with it:

• Variance close to zero — supplier is reliable. Stated lead time is fine.
• Positive variance (chronically late) — bump the supplier's stated lead time up so reorder points fire earlier. Don't just absorb the late delivery as wastage of cover.
• Wide range — the supplier is unpredictable. Treat the upper bound as the planning lead time, or add buffer stock for SKUs from that supplier.

International / container orders

Suppliers based outside Australia don't get reordered one trickle at a time — they ship in containers two or three times a year. So the ordering UX changes for them: instead of "what should I order to cover the lead-time gap?", the question is "what should I order to cover X months of demand after the container lands?"

The order page for an international supplier shows three things differently:

• Months of cover (post-arrival) — how long the order should last from when stock lands. Default is 4 months; adjust at the top of the order page.
• Forecast (X mo) column — expected demand over the cover period, using the seasonality-aware forecast.
• Cover % column — what share of forecast demand the suggested qty covers. 100% = exactly forecast demand. Above = additional safety. Below = the line is short and stock will run out before the next container.

Suggested quantities include a 20% safety buffer and account for stock that will be consumed during the lead time itself (so you're not double-counting demand). Edit any line to override.

SKU lifecycle

Status

Where a SKU is in its lifecycle. Four values:

• Staging — new SKU not yet ready for active reordering. Hidden from the Reorder Queue. Used to onboard products before sales data exists.
• Active — available for sale, fully tracked, included in reorder calculations.
• Discontinuing — phasing out. Still tracked but flagged so you don't accidentally reorder.
• Discontinued — retired from active inventory. Hidden from most views.

Staging SKUs require a manual reorder point before they can move to Active. The system also sends a daily digest listing newly-staged SKUs so the team knows what needs configuring.

Snooze

Hides a SKU from the Reorder Queue until a specified date. Useful when you have excess stock from a one-off bulk buy and don't want it nagging you, or when you've placed a manual order outside the system that the data hasn't caught up with yet.

Snoozed SKUs still appear in Stock Overview and SKU Master — only the Reorder Queue suppresses them. The snooze expires automatically on the chosen date.

First Seen

When this SKU first appeared in your inventory data. Mostly informational — useful for distinguishing newer SKUs (where less history is available) from established ones.

Slow-moving items reference

Slow-moving trigger

A SKU is flagged as slow-moving when either:

• it has more than 180 days of cover at the current sales rate, OR
• it sold fewer than the slow-moving threshold (default 24 units / 12 months) over the last 12 months and still has stock on hand.

SKUs younger than the new-SKU grace period (default 180 days) are exempt — they haven't had a fair shot yet. SKUs older than the grace period but younger than 12 months have their sales annualised so they're judged on the same scale as established SKUs. Discontinuing SKUs always show on the page so end-of-life decisions don't get lost.

Both the threshold and grace period are tenant-configurable from Admin.

Decision tags

Each slow-moving SKU gets one or more decision tags. Multi-select — a SKU can be both "Discount" and "Bundle" if you're trying both. Click a tag to toggle it on/off.

• Keep monitoring — not ready to act yet, but acknowledged. Use this to clear the SKU from the "pending decision" pile without committing to a strategy.
• Discount — will be price-reduced to move stock.
• Bundle — will be combined with another product to clear faster.
• Liquidate — sell at cost or below to clear remaining stock.
• Discontinuing — this SKU's lifecycle is ending. Pair with setting the SKU's status to Discontinuing.

Tags are persistent — they stay attached even if the SKU drops back below the slow-moving threshold, so the history of decisions is preserved.

Purchase orders reference

Receipts and partial receipts

Each PO line has a Qty Received column showing how many units have actually arrived. It can be:

• Zero — PO is placed but nothing has landed yet.
• Less than ordered — partial receipt. The supplier shipped some, more to come. Common for split shipments or partial back-orders.
• Equal to ordered — fully received. The line is closed.
• Greater than ordered — rare, but possible. Supplier over-shipped and you accepted it.

Date Received shows the latest receipt date for the line. Used by lead-time learning to compare actual against stated lead times.

Lines with recent changes

Counts PO line items where the quantity, price, or status changed in DEAR since the previous sync. The point is to surface surprises — a supplier amending an order, a partial receipt landing overnight, a price correction — without you having to scan every line manually.

If the count is zero, nothing has shifted since last sync. If it's non-zero, the affected lines are highlighted in the per-supplier groups below.

Forecasting reference

Forecast accuracy

The Dashboard home page closes with a four-tile read on how well the forecasting engine has been performing. Each forecast made in the past becomes scoreable once enough actual sales data exists to compare against. The strip aggregates the last 90 days of those comparisons.

• Accuracy — share of forecasts that landed within 30% of actuals. The headline number. Higher is better.
• Avg MAPE (Mean Absolute Percentage Error) — the average gap between forecast and actual demand, expressed as a percentage. Lower is better. Note: MAPE is sensitive to low-volume SKUs — a small absolute error on a SKU that sells one unit a month looks like a huge percentage. Read it alongside Accuracy rather than in isolation.
• Forecasts Scored — number of forecast/actual pairs that have been evaluated. More pairs = more confidence in the headline figures. Builds up over time.
• Health — plain-language reading: Strong (≥80%), Reasonable (≥60%), Improving (≥40%), Needs work (<40%). What to act on:
  • Strong / Reasonable — trust the forecast for reorder timing.
  • Improving — the engine is still learning. Lean on manual reorder points for high-stakes SKUs until accuracy climbs.
  • Needs work — usually means seasonality or boost data is missing. Set seasonality on top SKUs and apply demand boosts for known campaigns.

Notifications and email digests

stocura sends a small number of email digests rather than a stream of individual alerts. All digests fire at your configured digest time in your local timezone — one email per day per category, even if multiple events occur.

Reorder alerts (digest)

Daily list of SKUs that crossed their reorder point since the last pass. Configure recipients and digest time on the Settings page.

Staging notifications

Daily list of newly-staged SKUs that need a manual reorder point set before they can become active. Helps prevent SKUs from sitting in staging indefinitely.

Reorder graduation

One-off email when a Blended SKU has accumulated 6 months of data and auto-graduates to System reorder source. Lets you know the system is now using the calculated value rather than your manual one.

Boost ended

Daily digest of demand boosts that ended (auto-expired or manually ended) since the last pass. Includes the actual lift comparison so you can refine your estimates next time.

FAQ

Why is my reorder point higher than I expected?

A few things can lift it above the basic calculation: an active demand boost, the typical order size floor, seasonal lift, or a manual override. The Reorder Point (Seasonal) sub-line on the SKU detail page tells you which one is in effect.

Why hasn't my SKU graduated yet?

Graduation runs once per day and only fires when a Blended SKU has 6+ months of accumulated data. If you set the SKU up 4 months ago, it has 2 more months to wait. You can switch the SKU to System manually if you want to use the calculated value sooner.

Why is the dashboard slow?

Reorder calculations run on every page load to ensure the numbers reflect the latest sync. For tenants with many SKUs (1,000+), this can take a few seconds. We're working on caching the engine output without sacrificing freshness.

What happens if I change a SKU's lead time?

The change is immediate — next reorder calculation uses the new value. Reorder points across the SKU detail page and the Reorder Queue update on the next page load. Nothing is "remembered" from the old lead time.

Can I bulk-edit SKUs?

Not yet through the UI. For now, individual edits via the SKU detail page or supplier-level settings (which cascade to all SKUs from that supplier) are the supported paths. Bulk import via CSV is on the roadmap.

Why did a SKU disappear from the Reorder Queue?

A few possibilities: stock recovered above the reorder point (good), a PO was placed and the on-order quantity now covers the threshold, or the SKU was snoozed. Check the SKU detail page — the dashboard hides SKUs whose available + on order exceeds the reorder threshold.