Inventory basics

Inventory is optional: you can run pure order-to-dispatch without it. But if you switch it on, the system becomes the single record of your stock counts.

The model, in plain words

Each product/colour is a stock line with three buckets:

• On hand: physically on the shelf, free to sell.
• Processing: reserved. A courier has been assigned to an order using these units, but the parcel hasn't been packed yet. Still in the warehouse, but reserved.
• Damaged: written-off units (e.g. an RTO that came back unsellable).

Units move between buckets automatically as orders move:

Event	What happens
AWB assigned	on hand → processing (reserved)
Order packed	processing → removed (shipped out)
Order cancelled before packing	processing → back to on hand
Return/RTO received in good condition	back to on hand (if you enable auto-restock)
Return received damaged	into damaged

The ledger: why your counts are explainable

Every movement is a line in a permanent ledger: date, order, quantity, direction, who. The current count is just the running total. So "why does it say 43?" always has an answer you can read, movement by movement. Manual corrections (counts, receipts, adjustments) are ledger lines too.

If a movement was ever recorded with the wrong quantity — say a mis-set mapping wrote 32 where one unit really left the shelf — a manager can amend it: open the line, find the row in Movement history, type the true number and press Amend. The row is rewritten to the truth, keeps a visible "was 32" trace with the amender's name, and the counts at the top adjust by the difference. If the same order has other rows at the wrong size (its pack row, for example), amend those too — the confirmation message points them out.

SKU mapping: teaching it your catalogue

Orders arrive with your store's SKU codes. The system matches them to stock lines automatically where it can; anything it can't match lands on the mapping queue (Tools → SKU mapping). You map each SKU once (including bundles: "GIFTSET-1 = 1 mug + 2 coasters") and the mapping is remembered. Until a SKU is mapped, its stock movements are held back rather than guessed, so a wrong count is never written.

One number on that form matters: units per sale — how many units leave stock each time one of that SKU sells. A 3-piece bundle is 3; almost everything else is 1. It is not your stock count. If a mapping is saved with the wrong number, fixing the mapping also fixes the orders already reserved under it — the reservations re-align on the spot.

The packing gate

With inventory on, packing checks stock at the last safe moment:

• Unmapped SKU on the order → packing blocked until mapped (or a manager overrides with a reason).
• Not enough available units → blocked the same way.

You can soften this to "warn but allow" in settings; then stock can go negative, but the negative count shows on the needs-attention queue.

Getting your stock in

• CSV import on day one (Tools → Stock import): product, colour, SKU, count, reorder level, unit cost. You can use the sheet you already keep. One upload takes up to 10 MB or 50,000 rows — a longer list is fine, just split it and upload the parts, since importing the same rows twice changes nothing.
• Or start at zero and let receiving/counting build it up.
• Reorder levels per line give you low-stock warnings, and optionally a daily low-stock email to the founder.

Products you don't count

Some order lines aren't stock: a printed letter, a card, a free add-on the floor makes per order. Because inventory self-populates from real orders, one of these can show up as a stock line and start collecting reservations. Open the line and press Archive line: orders stop reserving and deducting it, any units it holds in processing are released on the spot, and future orders won't re-create it. It still appears on pick lists and packing checklists — the floor keeps including it; only the counting stops. Adding the product again by hand (or in a CSV import) turns tracking back on.

What your stock is worth

Admins get a valuation page (under Operators) that prices every line: on-hand value, units in transit, damaged write-offs. Each line uses its own unit cost if you've set one; otherwise it falls back to your sheet on Settings → Default unit costs — one row per product (every colour and variant included), cost per single unit in rupees. Cost prices are private: they show on admin pages only, never on the Inventory tab the floor uses.

How fast stock moves (admins)

Under Operators → Stock analytics, admins get one page built from the same ledger:

• Velocity — units out per line per week and per month, a 7-day trend, and which channel they went through (online orders, B2B and channel dispatches, replacements, manual adjustments). Pick the window it measures over (7 to 180 days). Rates only count complete days, and if your ledger is younger than the window the page says so and divides by the days it actually has.
• Runs out — the day each line's on-hand stock reaches zero at its current rate. Set your supplier lead time (Settings → Operations policies) and lines that would run out before a reorder could land are marked in red. The page tells you when; how much to order is your call — it never suggests quantities.
• Stock not selling — lines with units on the shelf that sold nothing in the window, priced at your unit costs, so you can see the rupees sitting still.
• Came back — RTO and return units received per line against units out, so a product that keeps coming back stands out.

Nothing on the page changes stock; it only reads the ledger.

What inventory does NOT do

No purchase orders, no supplier management, no multi-warehouse, no forecasting or order-quantity suggestions. It tracks one warehouse's counts.