One address for every terminal: how centralised reporting works

What the owner actually asked for

By the end of 2013 Ethos was billing in a handful of Fresspresso cafés. Each outlet had its own till, its own database and its own printer, and each one worked. The problem was not any single counter. It was the owner's evening. To know what the group had sold that day meant a call to each outlet, a figure read out over the phone, and a spreadsheet typed up at home.

In January 2014 we shipped centralised cloud reporting with database synchronisation: one address holding the reports for every terminal in the country. It is still one of the most used parts of the platform. This article explains how it is put together and what it changes.

Two kinds of truth

The design starts from a decision about who owns which record.

The till owns its bills. Every bill is raised, stored and printed on the outlet's own machine. It does not ask the cloud for permission, which is why the counter keeps serving through an outage. The central database owns the group picture. It holds a copy of every bill from every outlet, and all the reports are read from there.

Keeping those two jobs apart is the whole trick. A till that is also the reporting server slows down at month end. A cloud that is also the till stops the queue when the broadband does. Separate them, and each can be good at its one job.

How a bill travels

When a bill is closed on the counter, it is written to the local store first, tagged with the outlet and terminal it came from and the order it was raised in. A sync process then pushes new records to the central database. If the connection is down, the records queue on the till and go when the link returns.

Records are only ever added at the centre, never rewritten by a terminal, so two outlets cannot overwrite each other and an audit trail exists for every bill. If a terminal has not reported in for a while, that is visible from the centre too. This has turned out to be as useful as the sales figures: a silent terminal is usually a router that needs attention before anyone at the outlet has noticed.

What it changes for the owner

The evening phone round disappears. Yesterday's sales for every outlet, today's so far, the best-selling items by site, stock variance by site and the comparison between a new café and the ones that opened before it are all on one screen at one address. Ethos itself is reached at ethospos.atplcloud.com, and the group reports sit behind the owner's login there.

It also changes how an outlet is opened. A new café is a new terminal registered to the group, not a new reporting project. Fresspresso has gone from four outlets to 50+ on this model, and Ethos overall now reports from 125+ restaurants and cafés.

What has to be looked after

A reporting centre is a server, and servers need minding. Three things get our attention.

• Backups. The central database is backed up on a schedule and the restore is tested, because a backup nobody has restored is a guess.
• Monitoring. The sync lag per terminal and the health of the server are watched, so a problem is seen at the centre before it is felt at the counter.
• Growth. Years of bills from 125+ outlets is a large record. Our rule is that reports read from summaries rather than scan every bill, so the owner's dashboard does not slow down as the history grows.

Where this design is the wrong one

Centralised reporting is near-live, not instantaneous. A terminal that lost its link reports when it is back, so a figure across every outlet is correct to the last sync, not to the second. If a decision genuinely needs every outlet's number correct to the second, that is a different design with different costs, and we would say so rather than stretch this one. And if you run a single outlet with no plan for a second, the local reports on the till are enough; the central address earns its keep from the second outlet onwards.

The same shape, outside restaurants

The pattern is not specific to billing. A site that must keep working when its link is down, writing locally and syncing to a centre that holds the group picture, is how we think about any business with more than one location: a clinic group, a textile unit with a warehouse in another town, a distributor with depots. The same questions apply. Who owns which record? What happens offline? What is watched? What is backed up?

That design, and the hosting, monitoring and backup work that keeps it honest, is what our cloud and infrastructure service covers. If your business has outgrown one location and one spreadsheet, that is the place to start.