Not a generic inventory form stretched to fit a tyre business. Each module below is built around the real journey of stock and money through a distributor's network, with every record linked to the one before it.
The foundation everything else sits on — how your business, your dealers, and your dealers' dealers are actually structured.
| Form | Purpose | Key Fields |
|---|---|---|
| Dealer Type | The catalog of tiers your network is built from — a starter Distributor → Wholesaler → Retailer → Sub-Dealer chain ships by default, and you can add your own. | Code, name, description, allowed parent type (each type nests under exactly one type above it) |
| Dealer | One node in your hierarchy — a real business location with its own stock ledger. | Code, name, dealer type, parent dealer, status, credit limit, address, contact |
| Dealer User | A login scoped to exactly one dealer node — sees only that dealer's own data and whatever is beneath it. | Email, full name, dealer, role, status |
A tenant onboards with the default four-tier catalog already in place. Main Distributor is created as the top-level node (Dealer Type: Distributor, no parent). A Wholesaler is created beneath it, then a Retailer beneath that wholesaler, then a Sub-Dealer beneath the retailer — each creation checked against the type chain, so a Sub-Dealer can never accidentally be created directly under a Distributor.
One immutable ledger, from a supplier's delivery all the way down to a sub-dealer's shelf.
| Form | Purpose | Key Fields |
|---|---|---|
| Supplier Invoice | A purchase bill from a supplier — scanned and AI-read, or entered by hand — staged for review before it touches stock. | Supplier, invoice number/date, line items (product, HSN, quantity, rate, tax), status (Uploaded → Extracted → Reviewed → Applied) |
| Stock Transfer | A movement of stock between two nodes — warehouse to dealer, or dealer to dealer. | Product, quantity, source (warehouse or dealer), destination dealer, status (Requested → Approved → Dispatched → Received) |
| Stock Movement | The immutable ledger row every quantity change writes — the source of truth behind every number on screen. | Product, dealer or warehouse, movement type (Purchase/Transfer/Sale/Adjustment), quantity delta, actor, timestamp |
A supplier invoice for 400 units of a tyre SKU is scanned, reviewed, and applied to the central warehouse — one PURCHASE stock movement is written, and the product's cost basis updates. A wholesaler then requests 120 units via a Stock Transfer; once approved and dispatched, the warehouse's on-hand drops by 120; once the wholesaler confirms receipt, its own stock ledger rises by 120 — two more movement rows, permanently linked to that one transfer.
A dealer's sale to its own customer — stock and GST invoicing from the same transaction, never re-entered.
| Form | Purpose | Key Fields |
|---|---|---|
| Order | A dealer's sale to its own end customer, out of its own stock. | Dealer, customer, line items (product, quantity, unit price, GST %), status (Placed → Confirmed → Fulfilled), invoice-required flag |
| Outgoing Invoice | The GST tax invoice — generated from a fulfilled order, or issued standalone for a walk-in sale. | Dealer, customer or sub-dealer, payment mode, taxable value, CGST/SGST/IGST, total value, due date |
| Customer | A dealer's end customer master record. | Code, name, GSTIN, address, contact, email, credit limit |
| Supplier | Who a purchase came from — the mirror record on the inbound side. | Code, name, GSTIN, address, contact details |
A retailer places an order for 2 units at ₹16,000 each. It's confirmed against the retailer's real stock, fulfilled — deducting 2 units from the retailer's ledger — and invoice OUT-001000 generates automatically: taxable value ₹32,000, CGST ₹2,880, SGST ₹2,880, total ₹37,760, on credit terms.
Everything downstream of an unpaid invoice — payments, aging, a credit score, and dunning, all reading from the same ledger.
| Form | Purpose | Key Fields |
|---|---|---|
| Payment | A single receipt against one outgoing invoice — immutable once recorded. | Invoice, amount, payment date, mode (Cash/UPI/Card/Cheque/Bank Transfer), reference, recorded by |
| Credit Aging | A tenant-wide view of every outstanding invoice, bucketed by days past due. | Customer, total outstanding, Current / 1-30 / 31-60 / 61-90 / 90+ day buckets |
| Credit Score | A provisional, per-customer score — the reasoning is returned alongside the number, not hidden. | Overdue invoice count, average days late, outstanding-vs-limit ratio, resulting score (0–100) |
| Customer Follow-Up | A manually-logged dunning contact — the human half, alongside the automatic reminder emails. | Customer, dealer, date, channel (Call/Visit/Email/SMS/Other), notes |
Invoice OUT-001000 (₹37,760, due in 60 days) receives a payment of ₹10,000, dropping the balance to ₹27,760 and its status to Partially Paid. It shows up in the Aging report under whichever bucket matches today's date against its due date, and factors into the customer's credit score alongside every other invoice on their account.
Zooming back out — the platform contains 14 core record types across the four modules above, all built to reflect how stock and money actually move through a real dealer network.
Dealer Type is the parent chain; every Dealer and Dealer User references it.
Supplier Invoice → Stock Transfer → Stock Movement, the ledger underneath everything.
Order → Outgoing Invoice, with Customer and Supplier as the master data either side reference.
Payment → Aging → Credit Score → Follow-Up, all views over the same invoice ledger.
Bring your process — we'll show you exactly how it maps onto TreadChain.
Request a Demo