Retail / Mart POS

Demo ready

A counter that moves at the speed of the queue, and a stock figure you can believe on a Sunday evening.

A mart does not usually fail at selling. It fails at knowing. Sales happen all day without trouble, and then at closing the only honest statement is how much cash is in the drawer. What moved, what is nearly finished, what was given away in discount and what quietly walked out of the door are all guesses until someone does a full physical count.

This is one of the two things described on this site that already exists as working software rather than a plan. Even so, it is not a boxed product. The item master, the rate structure, the receipt, the discount rules and the reports get shaped around how your mart actually runs, because a general store with two thousand lines and a supermarket with twenty thousand are not the same shop at a different size.

What it fixes

  • Closing cash that matches nothing, because sales, discounts given on the spot and staff purchases were never separated
  • Shelf stock and godown stock treated as one number, so a shelf stands empty while four cartons sit at the back
  • Loose items — sugar, rice, pulses — weighed and keyed by hand at a slightly different rate each time
  • Expiry on dairy, bakery and packaged goods noticed by the customer before the staff
  • Two or three counters on a busy evening with no way to tell which till a disputed receipt came from
  • Purchase rates moving every few weeks, so nobody is certain which lines are still making money

What gets built

A starting point, not a fixed list. The build is scoped to your own process before anything is written.

Fast counter

Barcode scanning with keyboard fallback for the many items that carry no barcode, and a sale that completes without the operator waiting for the screen. On a Sunday queue, speed is the feature.

Shelf and godown stock

Stock held separately for the floor and the store at the back, with transfers recorded, so a reorder decision is based on what is actually in front of the customer.

Weighed and loose items

Lines priced per kilo, including the pre-packed labels most marts print in the morning. This is scoped to the scale you already own, which is worth naming early.

Discounts and offers

Line discounts, bill discounts and the usual deal formats, each recorded against the user who applied it. Giving a discount is fine; not knowing who gave it is the problem.

Multi-counter and shifts

Several tills on the same stock, each with its own operator, opening float and closing summary, so a shortage belongs to a shift rather than to the whole day.

Reports that get read

Daily sales, item movement, slow and dead stock, expiry approaching and margin by line. The aim is the three or four numbers an owner checks every night, not a report library.

Who this is for

General stores, marts and small supermarkets running one to roughly six counters, where the item count has grown past what one person can hold in their head. It suits an owner who is tired of discovering problems at stock-take. It is not worth it for a small kiryana counter where the owner personally sells every item and the khata is working, and it is not the right starting point for a chain of many branches with central purchasing — that is a larger build on different foundations.

Questions

Do we need FBR POS integration?

Only certain tiers of retailer are legally required to integrate, and the thresholds and the procedure change. We do not treat it as a tick-box that is already done. Confirm your tier and your obligation with your tax adviser first, and if it applies we scope the integration as its own piece of work with its own cost.

We have thousands of items and no clean list. Is that a problem?

It is the real work, and it is usually underestimated. Building a reliable item master with correct rates, pack sizes and barcodes takes effort from your side, not only ours. We would rather plan that honestly than hand over a fast counter attached to poor data.

What happens when the internet or the electricity goes?

A counter that cannot sell during a load-shedding slot is worse than a notebook. Where that matters it should run on the local machine and sync afterwards, and the counter needs a UPS. Tell us about your site conditions before the design is fixed rather than after.

Tell us how your mart runs.

We scope it first — what it takes, how long, what it costs. No obligation.

Start a conversation

More in Retail & POS