MunshiOnClick

The problem

A Pakistani ERP vendor was selling one accounting and operations system to businesses in several different trades — manufacturing, distribution, real estate, retail and services. Each trade wanted the same core books but a different daily workflow: a cold storage operator tracks inwards and outwards, a fast food outlet runs a till, a housing scheme tracks plot installments. The existing answer was to fork the interface per trade, which meant every accounting fix had to be applied in as many places as there were trades.

The second problem was the ledger itself. Customer and supplier balances were stored as running totals on each ledger row. Correcting a back-dated entry invalidated every balance after it, so the correction had to walk the whole ledger for that party. Done inline, during a working day, that blocked the request.

What we built

MunshiOnClick is a cloud-based ERP platform sold to businesses in Pakistan as a subscription. Each client company gets its own database; a subscription record controls whether that company's users can log in at all, and lapses block access at the point of sign-in rather than degrading quietly.

MunshiOnClick opens on a dashboard that reports the day's cash position — Today Paid (Credit), Today Received (Debit), Net Payable and Net Receivable, all in PKR — beside a queue of transactions still awaiting confirmation. The two module groups that carry the weight are the payable/receivable ledger and reporting. The ledger records every party — customer, supplier, salesman, investor, landlord — as one account with a running balance, and the dashboard's figures are that ledger aggregated. Reporting renders the same data to PDF against per-company templates, with configurable margins and Urdu (Jameel Noori Nastaleeq) text where a document needs it.

How it works

MunshiOnClick runs one Rails application against many per-company databases, switched per request from the signed-in user's company. That is what makes the per-trade interfaces affordable: the trade determines which sidebar and which controllers render, while accounting, inventory and payroll stay one codebase.

Ledger correction runs on Sidekiq's low queue rather than inline. When a back-dated entry forces a rebuild of one party's running balances, the job re-establishes its own connection to that company's database and walks the rows itself, so a correction on a long ledger doesn't hold a web request open for the user who made it or for anyone else on that company's system. PDF generation is queued the same way.

The platform now ships two interface generations at once. A V1/V2 toggle lets a user switch between the original menu and a rebuilt one, and the choice persists per browser. Both menus reach the same records, so a user can move between generations mid-task and no data migration is involved — nobody is migrated on a date.

The result

MunshiOnClick supports fourteen-plus trade-specific interfaces — cold storage, factory, fast food, oil station, mobile shop, housing scheme, taxi, dealer, tower and others — over one shared accounting core, which is the outcome the per-tenant database and per-trade view split were built to produce. The client positions the product as “Pakistan's Leading ERP Software for CRM.”