POS That Writes to the Same Stock Record as the Rest of the Business

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. Plenty of cloud POS products describe offline support and turn out to mean a read-only screen.

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.