Taking payment
A touch screen built for the rush: sales layout by category, discounts, preparation notes, split bills and refunds.
Country and language
Other markets: these available language versions show the same page.
Business software
One system for the till and the stock: every sale reduces the real quantities, and service carries on even when the connection drops.
The need
In most shops and restaurants the till records the sales and the stock is kept somewhere else: a spreadsheet, a notebook, or the manager's memory. The two drift apart within weeks. A product that no longer exists gets sold, an order goes out for something already sitting in the back room, and the end-of-month count closes with a gap nobody can explain.
We develop the till and the stock as a single system. Every receipt reduces the real quantities the second it is validated, including when the sale contains a recipe made of several ingredients. The manager sees the stock available without walking the store room, and the inventory gap becomes useful information again rather than something to put up with.
One point is not negotiable: the till has to work without a network. Our POS software stores sales locally when the connection drops, keeps taking payments and resynchronises as soon as the network is back. A service never stops because a router restarted at the wrong moment. Receipts keep printing, stock is still counted down locally, and nothing is lost when the data syncs again.
Features
A payment core, stock plugged into it, and the automation that keeps items from running out.
A touch screen built for the rush: sales layout by category, discounts, preparation notes, split bills and refunds.
Every sale removes the quantities sold, ingredient by ingredient for recipes. The stock shown is the real stock.
Sales are recorded locally when the network drops, then resynchronised automatically. Service is never blocked.
A threshold per item, a suggested order generated automatically, and stock entry on delivery.
Cash, card, meal vouchers, credit notes. Till closing with the gap recorded, a sales journal and an export to accounting.
Revenue by hour, by seller, by product. Turnover, slow-moving items and the real margin once the cost of goods is deducted.
How we work
Four stages, in this order. You sign off each one before the next starts.
We spend a service with you, in the dining room or in the shop, to watch how the work is really done. The requirements of the French regulations that apply to POS software are identified at this stage and included in the scope.
1 to 2 weeksClickable screens tested on the hardware you will actually use: tablet, receipt printer, cash drawer, barcode scanner, card terminal.
2 weeksTaking payment first, then stock, thresholds and statistics. A testable delivery every two weeks, including a full test in offline mode.
6 to 10 weeksCatalogue and stock imported, teams trained, then maintenance and new work. The source code is yours.
OngoingIntegrations
What we most often connect around the till:
Example project
Each shop kept its till and its stock separately, with a manual monthly count and regular stockouts on the best-selling items. We delivered a till that works offline in each shop and a consolidated stock view at head office.
Budget
The price depends on the number of sales points and on how complex the catalogue is. The most common starting point:
Indicative figure, hardware not included. The firm quote is issued as a fixed price after the scoping phase, with no subscription per till and none per user.
FAQ
The till keeps going. Sales are recorded on the device, receipts print, and everything reaches the server as soon as the connection is back. We test this scenario before go-live every time, with a real network cut, because it always happens at the worst moment.
We deal with their requirements during scoping: record integrity, event log, daily closings and archiving are part of the priced scope, in the same way as the business features. The subject is handled project by project, with you and your usual adviser, rather than through a generic promise on a web page.
Yes. You describe each dish as a set of ingredients with quantities, and selling a dish reduces every component. That is what lets you compare the theoretical cost of goods with real consumption, and see where the gaps come from.
Yes. Each sales point takes payment on its own, with its own stock, and head office sees a consolidated view: sales, margins, transfers between shops and grouped supplier orders. The catalogue and the prices are managed centrally or shop by shop.
See also
Let's talk
Thirty minutes is enough to understand your payment flow and your recurring stockouts — and to give you an honest range.