Work/Retail
Fikastore
A point of sale that keeps selling offline and proves every naira.
Live · paying customersLive, with active paying customers. Retail businesses sell on it every day.
WindowsWeb
The problem
“The drawer is short, the power is off, and nobody can say why.”
Small and mid-sized Nigerian retailers lose money in ways their tools cannot show. The drawer is short and nobody can prove who it was. The power goes and the shop stops selling, because the register needs a network. The accountant will not sign figures that change when a report is reopened. Owners with several branches cannot see stock, takings and staff in one place, and cannot tell a legitimate write-off from stolen stock. Browser tills lose queued sales when a tab closes.
Who had it
- Shop ownersProof that takings, stock and cash figures can be trusted.
- Branch managersControl of stock, prices and staff at their branch.
- CashiersA till that keeps working, and a fair record when the drawer is short.
- Accountants and auditorsFigures that stay fixed and can be checked by someone else.
What the answer had to survive
- Power and network fail on the busiest afternoons.
- Every sale and cash count must be provable later.
- Many tills and branches must stay in step.
- Shops use the printers they already own.
- Reports must not change when they are reopened.
What we built
A till that keeps selling offline and records every naira as evidence.
Each checkout computer holds its own copy of products, prices and staff. It records every sale on the computer and sends it to the cloud by itself, so selling carries on when the power or network fails. Receipt numbers run without gaps, and every shift ends with a counted drawer. Stock and wallet balances are built from movement records and never overwritten. The owner portal brings branches, prices and reports together, and finished months can be frozen as statements with a check code. Two print paths let the till work with the printers a shop already owns.
What it does
At the till
- Works with no networkSells from a local copy of products and prices, queues every record, and uploads it by itself when the connection returns.
- PIN login and auto-lockEach cashier signs in with a PIN, and the till locks itself after idle time.
- Split paymentsOne sale can be paid across cash, card, transfer, credit and customer wallet or voucher codes.
- Void and refund controlsRefunds by receipt lookup, with a manager PIN above a set threshold and plain reasons when refused.
- Hold and recall salesPark a sale while a customer fetches something, then bring it back to the screen.
Proof of the numbers
- Receipt numbers without gapsA missing number means a completed sale was removed, narrowed to one till, one shift and one cashier.
- Counted drawers every shiftEach shift opens with a float and closes with a counted drawer and a recorded difference.
- Shrinkage in two numbersDeclared write-offs are shown apart from unexplained loss, so theft cannot hide behind a write-off.
- Frozen statementsA finished month is frozen under the owner's name with a check code, so any copy can be verified.
Owner portal
- Branches, staff and rolesOwner, central admin, auditor, location manager and cashier roles, with approvals for new staff and new tills.
- Prices and tax rulesPer-branch prices, price floors, tax recorded at the rate then active, and permission limits.
- Stock as a ledgerReceiving, counts, and transfers between branches with in-transit status and waybill evidence.
- Suppliers and purchase ordersOrders checked against what was received, with the order emailed to the supplier.
- Cash position and daily closeFloats, takings, refunds, payouts and deposits shown as one line of arithmetic.
Customers
- Online shop per businessA public storefront that sells from the same stock figure the counter uses. Handing over an order records an ordinary sale.
- Customer walletCustomers register with a store, top up a balance, redeem vouchers and see their own loyalty points.
- Loyalty and creditPoints per phone number, customer accounts for sales on account, and company accounts credited by bank transfer.
Money handling
- Card machine reconciliationCard sales are recorded against a registered machine and compared with that machine's own settlement report.
- Expenses with approvalExpenses above a set amount wait for the owner's approval, with categories and a report.
- Alerts and daily digestNightly alerts flag anything unusual, and a daily email summary goes to the owner.
- Excel import and exportLoad a product catalogue from a spreadsheet and export reports with filters applied.
A day with it
- 1
Set up the business
The owner registers, creates the business and first branch in the portal, and imports products from Excel.
- 2
Set rules and staff
The owner sets prices, tax and permission limits, then adds staff. New staff and new tills wait for approval.
- 3
Install and approve a till
The till installer is downloaded from the portal, a setup wizard registers the computer, and the owner approves it.
- 4
Open a shift and sell
A cashier opens a shift with a float, scans items and takes payment. If the network drops, nothing changes at the counter.
- 5
Count and close
At close the cashier counts the drawer. The difference is recorded and the receipt range prints with signature lines.
- 6
Review and freeze
Everything reaches the portal by itself. The owner reviews takings, alerts and shrinkage, then freezes the month's statement.
How it works inside
The till is a Windows program with its own local database and an outbox of unsent records. The cloud holds prices, staff and rules and sends them down. The till sends sales up. Every record carries a unique ID, so a retried upload is never counted twice.
Cut the network to see what this system does without it.Internet links are down. Everything on the device and inside the building carries on, and queues its changes.
On the device
- Windows till appSells from its own copy of products, prices and staff.
- Local till databaseHolds products, prices, staff and every sale.
- OutboxQueues every record until it is uploaded; never pruned.
Our cloud
- Owner and staff portalBranches, staff, prices, reports and approvals.
- Online shop and walletPublic storefront and customer wallet pages for each business.
- Cloud APIOne application serves the till, portal, shop and scheduled jobs.
- Ledger databaseInsert-only ledgers for sales, stock, wallets and points.
Outside services
- File and backup storageWaybill evidence and verified nightly database backups.
- Payment gatewayWallet top-ups and online card payments, on each store's own account.
- Email serviceDaily digests, purchase orders and support replies.
Every part and every link, as text
- Windows till app — Sells from its own copy of products, prices and staff. (on the device)
- Local till database — Holds products, prices, staff and every sale. (on the device)
- Outbox — Queues every record until it is uploaded; never pruned. (on the device)
- Owner and staff portal — Branches, staff, prices, reports and approvals. (our cloud)
- Online shop and wallet — Public storefront and customer wallet pages for each business. (our cloud)
- Cloud API — One application serves the till, portal, shop and scheduled jobs. (our cloud)
- Ledger database — Insert-only ledgers for sales, stock, wallets and points. (our cloud)
- File and backup storage — Waybill evidence and verified nightly database backups. (outside services)
- Payment gateway — Wallet top-ups and online card payments, on each store's own account. (outside services)
- Email service — Daily digests, purchase orders and support replies. (outside services)
- Windows till app → Local till database: Writes every sale locally (works offline)
- Windows till app → Outbox: Queues every record (works offline)
- Outbox → Cloud API: Uploads when online (needs internet)
- Cloud API → Windows till app: Prices, staff, rules (needs internet)
- Windows till app → Cloud API: Wallet and code debits (needs internet)
- Owner and staff portal → Cloud API: Owner reviews and approves (needs internet)
- Online shop and wallet → Cloud API: Orders and stock checks (needs internet)
- Cloud API → Ledger database: Reads and writes ledgers (works offline)
- Cloud API → Payment gateway: Payments and top-ups (needs internet)
- Cloud API → File and backup storage: Waybills and backups (needs internet)
- Cloud API → Email service: Digests and orders (needs internet)
The hard parts
Receipts that printed as empty pages
- The situation
- A shop's receipts came out as empty files with no error. The till sent raw printer commands, but modern Windows print drivers accept none, so the spooler said accepted and printed nothing.
- What we did
- Found the cause over three attempts and wrote a second print path that draws text through the Windows graphics layer. The till now detects the driver type and picks the right path. Proof was a captured print file, not an assertion. Characters printers cannot encode are transliterated.
- The lesson
- The software adapts to printers shops already own. Spooler accepted is not the same as printed.
Testing the real till against the real server
- The situation
- Unit tests passed while real selling flows still failed. A manager's approval PIN was never checked until a screen with no field for it. Cash refunds were added, not subtracted, at shift close.
- What we did
- Built a Docker end-to-end harness that starts the real till window against the real API on MySQL, loaded with real prices, and drives selling, shifts and sync through it. It found two bugs the unit tests had missed.
- The lesson
- Money-handling bugs are caught in a controlled run, not at the counter.
Receipt numbers that make theft visible
- The situation
- Owners could see totals but could not tell whether a sale had been rung and then removed.
- What we did
- Numbers are issued per till with a location prefix. Only completed sales use one, a refused sale gives its number back, and numbers are never reissued, even after data is cleared. Statements add a check code over the figures, so identical figures always give the same code.
- The lesson
- A gap in the sequence is evidence, narrowed to one till and one shift.
A sync that broke because of a rename
- The situation
- After the product was renamed, new installs would not sync. The till's local data folder had moved with the name, so it had no record of a shift the cloud still held open.
- What we did
- Gave the app a stable data path, added a cloud endpoint for the current shift, and taught the till to adopt the cloud's open shift. Rows already in the queue were repaired too, because fixing the code does not fix what is already queued.
- The lesson
- Upgrades and renames must never strand a shop's data.
The stack
- Apps
- Flutter (Windows desktop)DartInno Setup installerServer-rendered web pages
- Backend
- PHP 8.3LaravelToken sign-in for owners, staff and customers
- Data
- MySQL 8 (insert-only ledgers)SQLite on each tillExcel and PDF import and export
- Infrastructure
- Cloud server with nginxHTTPS with auto-renewing certificatesObject storage for files and backups
- Services
- Payment gatewayAmazon SES email
- Testing
- flutter_test for the tillPHPUnit for the cloudDocker end-to-end harness against the real API
How it came together
- 1From plan to cloud applicationThe architecture plan became a working cloud application on a server.
- 2The Windows tillThe till was built with its installer, and the product took the Fikastore name.
- 3The rest of the shopReceipt printing, purchase orders, loyalty, the owner phone view and the online shop were added.
- 4Backups provenA nightly backup to separate storage was built, and a restore was proven.
- 5Tested end to endFloat corrections were added and an end-to-end test harness built.
- 6Money-correct voidsTill version 1.17.0 made voided sales move money correctly.