A browser-based till with split tenders, returns and a transaction record that carries through to reporting.
This point of sale system case study covers a browser-based register. A cashier there scans goods and combines several tenders before issuing a printed receipt to the customer. Customer records, stock administration and the cash-up figures all sit in the same application.
The till allows a sale even when stock shows a warning. That fits an item sitting on the counter, as long as staff reconcile the recorded discrepancy afterward.
The challenge
Stored value needs a stricter rule than stock does. Two cashiers must never spend the same gift-card balance, even though the inventory policy does allow a negative count.
The saved sale also had to hold its payments and stock movements together. A partial save would break that. It would leave the reports and the counter transaction describing different things.
What we built
The register takes searches and barcodes, and it also reads kits and full receipt numbers. A receipt number finds the original sale for a return. Cashiers can suspend a basket, prepare a quote or an invoice, and split one payment across several tenders. Completion recalculates the taxes and puts the change on the cash tender.
Card charging happens on a separate terminal. The till records the terminal's reference instead of processing the card itself.
Stock is tracked by location, with receiving and movement history. A suspended sale or a quote reserves no stock, and a negative quantity stays possible.
Technical approach
The basket lives in the employee's database-backed session until the sale is completed. Saving then writes the sale and its lines in one transaction, and the same transaction records the payments, the taxes and the stock movements. A failed write rolls everything back. A clean save clears the basket and opens the receipt ready to print.
Check the balance as it is spent
Gift-card spending runs through a conditional database update. The update subtracts the amount only while enough balance remains. Doing the check and the deduction in one statement stops two tills from trusting the same earlier balance.
When no row changes, the sale rolls back and reports an insufficient balance. Loyalty spending works the same way.
A cancellation keeps the original sale on record and then adds reversing stock movements. Each sold line also keeps its original item cost. A later change in supplier price then cannot rewrite the historical margins.
Cash-up compares the counted takings against the expected tenders for a chosen store-wide period, after cash expenses. Server permissions govern sensitive actions, among them price changes and cancellations.
Project success
Cashiers can complete sales and receipt-based returns, while the back office keeps the movements behind them. The application treats two situations differently on purpose. A stock discrepancy can be reconciled later. A gift-card or loyalty debit, though, has to pass the balance check the moment the sale is saved.
Technology stack
Server application
PHP, CodeIgniter
Database
MySQL or MariaDB
Register interface
Bootstrap, browser forms and server-rendered views
Session storage
Database-backed employee sessions
Documents
Browser receipt printing, PDF invoices and quotes
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
