Lost kitchen tickets
Printing straight from a browser means an offline printer, an empty paper roll or a closed tab loses the order outright, and the table simply waits.
Floor map service, station-routed kitchen tickets, KDS and cash shifts, with recipe stock consumption behind every plate.
Service fails in small, expensive ways: a ticket that never printed, a bill split badly, a bar stock count nobody trusts. Penahak takes printing out of the browser and puts recipe consumption behind every dish.
Printing straight from a browser means an offline printer, an empty paper roll or a closed tab loses the order outright, and the table simply waits.
Without recipe consumption, food cost is a monthly guess derived from purchases rather than from what was actually served.
Pour variance is invisible when sales and stock live in different systems that are reconciled by hand, if at all.
If a cancelled item leaves no record, the difference between a genuine mistake and a habit cannot be seen.
Each step below creates or references a real document. Nothing is retyped between them, and every figure at the end traces back to the action that caused it.
A starting point, not a fixed bundle. Add or drop modules once we have seen how you operate.
Table service built around a floor map, station-routed kitchen tickets and durable print jobs that survive a printer going offline mid-service.
One inventory engine serves retail, restaurant, hotel minibar and manufacturing. Movements are vouchered, costed and reconcilable back to accounting.
Light manufacturing that consumes real stock and produces costed output, with a production journal you can audit line by line.
A double-entry core with a real chart of accounts, cost centres, fiscal-year control and immutable posting. Every sale, folio, payroll run and stock movement in Penahak resolves to a source document here.
Not features — outcomes. If these are not true six months after go-live, something has been configured wrongly and we want to hear about it.
Every total drills down to the source document behind it.
IRD-approved, with fiscal invoice behaviour in the central SalesBill and POS paths, IRD sync, VAT customer and vendor summaries, and an audit trail built for inspection rather than reconstructed after the fact.
Bikram Sambat fiscal-year control, business-date close and dual-date handling throughout documents and reports.
eSewa, Khalti, Fonepay, card, bank, QR and wallet adapters, with verification evidence required before a provider goes live. Cash stays simple: no merchant ID, no callback URL.
Interface translations and a localisation layer in both the web application and the reporting engine.
Every posting command carries an idempotency key. Corrections go through approved reversal or credit paths; posted truth is never edited in place.
Granular roles and permissions, IP address whitelisting, two-factor authentication, user activity logging, time-based account expiry, and stage-based setup gates that block posting until configuration is safe.
We map your outlets, books, stock locations and statutory obligations, and agree what go-live means.
Chart of accounts, tax and bill terms, document numbering, godowns, roles and payment providers, all checked against the setup gates before anything posts.
Masters, opening balances and opening trial imported and reconciled against your closing figures.
Role-based sessions for owners, cashiers, front desk, kitchen, storekeepers and accounts, using your own data.
One full test cycle end to end, then supervised go-live with a support engineer on hand.
Ongoing support, statutory updates, new-release rollout and periodic health checks.
Book a walkthrough and we will demo the modules that match how you actually trade — not a generic slide deck.
No obligation. Typically 30–45 minutes.