Engineering Jewellers Pro: GST billing, live gold rates and offline-first POS

Jewellers Pro is our cloud ERP for gold, silver and diamond retailers — our own product, built and operated by VBRO. Jewellery retail is a wonderful stress test for software design because it compresses several genuinely hard problems into a single billing screen. This article covers the four that shaped the architecture.

1. Prices that move under your feet #

A jewellery price is derived: weight × today's metal rate ± making charges, adjusted for purity. The rate moves daily — sometimes hourly. The naive design stores the price; the correct design stores the derivation. Every invoice line in Jewellers Pro snapshots the metal, purity, weight and the rate it was struck at. That is what keeps the books consistent with the market they were written in, and it is what makes margin analysis computable months later.

2. The customer who is also a supplier #

Old-gold exchange makes one person a buyer and a seller inside a single transaction: they hand over a bangle, it is valued at purity, and the amount offsets the new purchase — on the same GST-correct invoice. Modelling exchange as a first-class part of the sale, rather than a discount hack, was one of the earliest decisions and one of the most load-bearing.

3. Karigars, wastage and reconciliation #

Manufacturing runs on karigars — outworker artisans who are issued metal and return finished pieces. Between issue and return sits wastage, some legitimate, some not. Each job in Jewellers Pro records metal out, expected wastage and pieces in, reconciled per karigar. Losses become visible per job instead of surfacing as a mystery at the annual stock-take.

4. The counter must never stop billing #

A jewellery counter that cannot print a bill is a shop that has stopped trading — and connectivity in Indian retail is not a thing you bet the festival rush on. Billing terminals are offline-first: invoices are written locally and synced when the line returns. The server applies sync operations idempotently, so a replayed queue cannot create a duplicate invoice.

// Every synced operation carries a client-generated key.
// Applying the same operation twice must be a no-op.
public function apply(SyncOperation $op): void
{
    if (Ledger::hasApplied($op->key)) {
        return; // replay — already in the books
    }

    DB::transaction(function () use ($op) {
        $op->execute();
        Ledger::markApplied($op->key);
    });
}

GST as a data-model property #

Multi-metal, multi-tax invoicing with correct HSN codes is not a report you generate — it is a property of the data model. Because every line knows its metal, purity and rate, the tax treatment is computed rather than typed, and "100% GST-ready" stops being a marketing line and becomes a constraint the database enforces.

Around that core sit the parts a modern shop expects — CRM with payment reminders, WhatsApp and SMS campaigns, and a white-label storefront with a customer portal selling from the same stock the counter bills against. In English and Hindi, because software that does not speak the counter's language does not get used.