Festival stock ordering sheet — what you ordered, what it cost, and the day it ran out

tyohari is for the family running a kirana or provision store, sitting at home twice a year — once a few weeks before the festival to write the order, once a week after it to record what happened. Nothing here is ever touched during trading hours.

What you record

Per line: the item, the quantity, and what the wholesaler billed. Then, a week later, one of exactly two observations — both readable off the counter with no stocktake:

• it finished → you write the date;
• it was still there a week later → you tick a box.

If nobody noticed, you leave it blank. A blank line is honest; a guessed date is not.

What it prints

One A4 ordering sheet: the item table with a deliberately blank quantity column and up to three filled year columns beside it, the goods and freight totals, and the limits block. Plus a half-page counter slip — item, ordered quantity, and two empty boxes per row (finished on ____ and a tick box) — so the observation itself never needs the laptop.

A worked example

Ghee went from 22.000 kg at ₹10,340.00 last Diwali to 25.000 kg at ₹12,500.00 this one, and ran out two days before the day.

Two change columns, because they are not one number. The line cost rose 20.88%, but you also bought three more kilos: the wholesaler's rate moved 6.38%. A single column headed "cost change" sitting next to a quantity column reads as "ghee got 21% dearer", which the data does not support. So tyohari prints both, each labelled with its own numerator and denominator, and marks every row whose quantity also moved.

The Agarbatti row shows the other rule. A cost of zero means not priced yet, not free — so the rate cell prints a dash and says why, never "₹0.00 per packet". And a line that was not on last year's list has nothing to change from, so both change cells print a dash, never a 0 and never "+100%".

What it refuses to do

The quantity column on the printed sheet stays blank. There is no forecast, no suggested quantity, no "order 15% more", and no verdict of any kind — the outcome vocabulary contains no word like "over-bought", because that judgement is the owner's and the app has no basis for it. The summary is a count with its denominator printed, never a grade.

There is also no leftover-stock field, on purpose. Festival stock in a kirana does not sit in a separate pile waiting to be counted, so any "₹ of stock left over" number would be invented — and it would be carrying the whole analysis. The run-out date and the week-after tick replace it, and both are observable at the counter.

What it will not do

No festival calendar and no item list — tyohari ships zero rows of data of its own; every name, date and number is one you typed. No stock or inventory system. No selling price, margin, GST or profit. No credit, udhaar or dues ledger of any kind, and no customer names. No staff attendance or wages. No sales entry, no billing, nothing typed during trading hours. No live rates and no internet at runtime. No accounts, no sync, no sharing. No AI and no "smart" anything.

This demo page loads only files served beside it — no CDN, no third-party script, font or analytics. CanvasKit is vendored here rather than fetched from Google, and Flutter's font-fallback URL is pinned to this same origin, so a glyph missing from the bundled font renders as a blank box instead of fetching one. The one network request tyohari's desktop build makes is to 127.0.0.1, your own machine.

Try it below

The register below is loaded with three made-up Diwalis for a shop that does not exist. Edit it, add your own lines, print the sheet — nothing you type leaves this page, and a refresh resets it.