Retail POS

Retail POS is a point-of-sale platform that scales from a single shop to a multi-store chain. Its core design decision is this: price and campaigns are managed centrally, while the sale itself completes in the store independently of head office.

Three problems recur in multi-store retail:

1. The till stops when the link drops. In a design where the till waits for central approval, an outage turns directly into lost revenue.
2. End-of-day differences cannot be traced. When till totals, bank POS totals and the physical count disagree, the source is hunted by hand.
3. How a campaign applied to a receipt cannot be verified. Without a versioned rule set, a past receipt cannot be recalculated.

The till application keeps what it needs locally: items, barcodes, price lists, campaign rules and a defined limit for customer balances. When a sale completes, the receipt is written to a local queue and uploaded when connectivity returns.

On the central side every sale is deduplicated by till identity plus receipt number. Even if the same receipt is sent twice, the second copy is not processed. This is the rule that prevents duplicate records on an offline-capable till; we cover it in detail in our offline POS design guide.

Price and campaign changes are published centrally as a version. Tills download the version, and head office can see which till runs which one. A lagging till does not silently keep selling at old prices: once a defined delay is exceeded it raises a warning.

• Sales and till: fast checkout screen, keyboard shortcuts, park/recall, partial and mixed payments.
• Returns and voids: returns against a receipt reference; unreferenced returns flagged as a distinct type.
• Stock: store inventory, count sessions, transfers, waste and shrinkage records.
• Customers and loyalty: account balance, points, offline spending limit.
• Price and campaigns: layered discounts, combined campaigns, rule priority.
• Reporting: sales by cashier, time slot, product group and store.

Fiscal devices and payment terminals, bank POS reconciliation (bank integration), e-invoicing and e-archive, scales and barcode hardware, the central ERP, e-commerce and marketplace channels, and time and attendance for staff.

• A local database per till with two-way synchronisation to the centre.
• Receipt, payment and return lines in separate tables; balances are never updated in a single field.
• Role-based authority plus a data scope separation, so a franchisee sees only its own data.
• Who-and-when records on critical actions (voids, discount overrides, drawer opening).
• Card data is not stored on the till; the boundary between the payment device and the application is defined in writing at the start of the project.

Offline operation is not left unlimited. Once a defined period is exceeded the till warns the manager, because selling at stale prices for long produces campaign and margin errors. The number of queued sales and the age of the oldest record are visible on the till screen.

• Grocery chains: central campaigns, inter-store transfers, scale integration.
• Apparel and footwear chains: variant-level barcodes, end-of-season markdown rules.
• Franchise networks: data scope separation and per-franchise turnover reporting.
• Store plus online: managing both channels from the same stock record.

Primarily multi-store retail, and manufacturers that also run their own shops in textiles, furniture and food.

1. Single-store pilot — choose the most complex branch, not the easiest.
2. Head office integration — price and campaign distribution, sales upload, bank reconciliation.
3. Roll-out — transfer flow, authority matrix, multi-store reporting.
4. Channel expansion — publishing store stock to the online channel.

Do we have to replace our existing ERP?

No. The POS does not replace the central ERP; it exchanges item, price and stock data with it. The precondition is that the ERP can expose its data through an API or database access.

How are fiscal device requirements handled?

A sale completes matched to the fiscal device, and the device transaction number is written to the receipt record. Without that match, the device report cannot be compared to till totals during end-of-day reconciliation.

At how many stores does a central structure become necessary?

Less about store count than about the need for inter-store transfers and central campaigns. If two stores transfer stock regularly, central stock visibility is already required.

Do we have to replace our till hardware?

Usually not. Scanners, receipt printers and drawers use standard interfaces. Where replacement is needed, the reason is normally vendor support on the fiscal device or payment terminal side.