Point of Sale
A standalone till gives you sales in one system and stock in another, reconciled by somebody on a Friday afternoon.
Why It Matters
With a standalone POS, the till holds sales and the ERP holds stock, and somebody bridges them with an export. Between exports the shop floor is guessing.
The internet will drop. A till that cannot sell during an outage costs money within minutes and costs goodwill faster than that.
The operator signs in to a named till, the opening float is counted and entered, and the local cache of products, prices and promotions is refreshed.
Items are scanned or picked from quick-select, weighed goods come off the scale, and price lists, promotions and loyalty discounts apply as the basket builds.
One tender or several. The amount is sent to the card terminal rather than rekeyed, change is calculated for cash, and vouchers and store credit are redeemed against their balance.
The receipt prints, the drawer opens if cash was taken, and the sale reduces stock and posts revenue and tax. If the till is offline the sale is queued and posts in order on reconnect.
Drops are recorded, the operator counts and declares the drawer, variance against expected cash is logged by operator, and the shift totals roll into store and group reporting.
Screen layout, keyboard shortcuts and quick-select tiles built around your actual basket, then timed against a real peak queue.
Local product, price and promotion cache, a transaction queue that survives an outage of hours, and a tested sync and numbering path on reconnect.
Cash, card, split tender, vouchers, gift cards and store credit, with the card terminal integrated so amounts are never rekeyed.
Float, drops, blind counted declaration at close, and a variance report by operator and by shift that a store manager can actually read.
Store price lists, dated promotions, multibuy and mix-and-match, loyalty tiers, and an override path with approval and an audit log.
Printer, drawer, scanner, terminal and scale tested per store, staff trained on the till, and a pilot store run before the rest follow.
One till and no stock complexity? A cheap dedicated POS product will serve you better and cost less.
We pull the connection during acceptance testing, sell through it, and prove the queue syncs with the right receipt numbers and stock movements.
A real basket, a real operator, a stopwatch.
Printer, drawer, scanner, terminal and scale models are confirmed as supported at evaluation, because a driver gap after go-live is slow to fix.
Refund authorisation, override logs and variance by operator are configured as reports someone actually reviews weekly, not as data sitting unread in a table.
One store runs live for a full trading cycle including a weekend and a stock count before the rollout continues. Problems are found on one till, not on thirty.
A genuine offline mode caches the product list, prices, promotions and recent customers on the till itself, keeps selling when the link drops, queues every completed transaction locally, and pushes the queue up when the connection returns. You should expect a till to survive an outage of hours, not minutes. Card payment will still need the terminal's own connectivity, so cash and account sales continue while card sales depend on the acquirer. Test this in the demo by pulling the network cable mid-basket.
Because the till writes to the same stock ledger every other part of the system reads. A sale at the counter reduces the item on hand immediately, or on sync if the till was offline, and the same figure drives reorder points, transfers and the online channel. There is no nightly file, no reconciliation spreadsheet and no argument about which system is right. That single figure is the main reason to run POS inside the ERP rather than beside it.
Yes. Products, price lists and promotions are maintained centrally and pushed to each store, so a price change happens once rather than store by store. Staff can see stock in other stores and either transfer it in or send the customer to a branch that has it. Sales, margin and cash variance report by store, by till and by operator on one set of figures. Store level price lists are still supported where a location genuinely prices differently.
A receipt printer, a cash drawer triggered by the printer, a barcode scanner, a card terminal and, for anything sold by weight, a scale. Most tills run on a normal PC or tablet. The practical constraint is peripheral support: check that your specific printer, scanner, terminal and scale models are supported by the product you are buying before you commit, because a driver gap at one store is a slow and irritating problem to fix after go-live.
The till is where loss most often occurs, and refund authority is the usual route. So refunds run through a controlled path: a return is linked to the original receipt where one exists, the reason is recorded, the refund tender is restricted by policy, and anything above a set value or without a receipt needs a supervisor authorisation that is logged against that supervisor. Exchanges are handled as a return and a new sale so stock and margin stay correct. The refund and override log by operator is then reviewed like any other control.
Yes, provided the online channel and the till read the same stock record and the same customer record. Click and collect reserves the stock when the order is placed, and the store hands it over and closes the order at the till. An online order returned in store is processed against the original order, refunds to the original tender or to store credit, and puts the item back into store stock. If the two channels run on separate stock figures, both of these break in the same way and staff learn to distrust the screen.
Related
The other services in this section, and related pages from TCB Infotech.
No commitment. If one till and simple stock is your whole situation, we will point you at a cheaper product and say why.
