Command dashboard
Network KPIs across every region: outlets needing attention, out of stock, critical and low-stock alerts, stale outlets, and stock value, each against the same period thirty days back.
Commerce & Operations · Available
Know what every outlet has on the shelf, before it runs out

A chain with forty outlets usually runs inventory in one system, alerting in a spreadsheet, and the books in a third place that reconciles weeks later. BluYards collapses all three. Stock moves, alerts fire, and the vouchers post from one document in one transaction, so the shelf, the alert and the ledger can never disagree with each other.
Network KPIs across every region: outlets needing attention, out of stock, critical and low-stock alerts, stale outlets, and stock value, each against the same period thirty days back.
Outlets down one axis, products across the other, 2,000 SKUs per outlet without pagination. Each cell carries on-hand, in-transit, days of cover and a health band, updated live over server-sent events.
Thresholds resolved global to category to product to outlet, held in units with hysteresis so they cannot flap, escalated by region and de-escalated in place. Alerts are evaluated inside the stock movement transaction, not on a cron.
The masters behind the matrix: outlet hierarchy and regions, catalogue with categories, and warehouse locations, each with its own stock position and health score.
Receipts and dispatches as documents. Each one posts its matching voucher at the same moment it moves the stock, so there is no overnight job that can leave the two out of step.
Direct transfers where the destination is known, and open pools where outlets claim from a released quantity as they need it. Batches are all or nothing, deduplicated per outlet, up to 500 movements per call.
Cycle and full counts with variance against book stock, plus CSV import for sales, counts and catalogue, and Tally import that is safe to re-run without double counting.
Trial balance, profit and loss, balance sheet and ageing, all built from posted vouchers only. Two-way TallyPrime integration over the HTTP gateway or XML, and an append-only stock ledger with an audit log behind every figure.



Interface previews are representative layouts. Every deployment is configured to your own modules, terminology, and branding.
Days of cover per outlet and SKU projected from real consumption rather than a fixed reorder point, so replenishment is raised against demand instead of a calendar.
Suggested minimum and reorder levels per outlet and category, derived from that outlet's own history, so a slow branch is not held to the same bar as a flagship.
Counts read against book stock and movement history to surface the outlet, product or route where the loss is concentrated, rather than a network-wide variance figure.
Ranking across hundreds of open alerts by value at risk and time to stock-out, so the list an area manager opens is ordered by consequence.
BluYards is built to sit inside the estate you already run. These connectors ship with the product; anything else is an integration engagement rather than a limitation.
It is tested at 2,000 SKUs per outlet and over a million stock-level rows, with thresholds recomputed set-based in SQL. Chains from ten outlets to several hundred run on the same architecture; the matrix is virtualised, so the browser renders only what is on screen.
No. BluYards integrates with Tally and TallyPrime in both directions, over the HTTP gateway or by XML. Import and re-import are safe to repeat without double counting, so the statutory books stay where your accountant expects them.
A transfer has a known destination and moves stock from one location to another. An open pool releases a quantity that outlets claim as they need it, which suits promotions and seasonal stock where you do not want to decide the split in advance.
Because a cron that sweeps every few minutes means an outlet can be out of stock and unaware of it for that window. Evaluating the threshold in the same transaction that moves the stock means the alert exists the instant the level crosses, and it is delivered in under a second.
Thresholds are held in units with hysteresis, so an item hovering on the boundary raises once rather than repeatedly. Alerts escalate by region and de-escalate in place, and triage ranks the open list by value at risk and time to stock-out.
How it works
The path a record takes through the product, and what the system does at each step without being asked.
Outlets, warehouses and catalogue form one matrix, so the position at every location is a single query rather than a nightly roll-up.
Inward, outward, transfers and open pools move stock as documents, in all-or-nothing batches that are safe to retry.
Thresholds are evaluated inside that same transaction, so the alert exists the moment the stock level crosses, not on the next sweep.
The matching voucher posts with the movement, which is why the trial balance and the shelf never drift apart.
Counts, Tally import and the append-only audit log close the loop, and every figure can be traced back to the document that made it.
Send us how you run this today, including the spreadsheets. We will show you BluYards against your own process and tell you plainly what it would and would not change.