The server prices the refund, not the till

On 11 September the till stopped choosing its own total: it asks for a sale to exist, and the server says what it costs. The refund was the other half of that sentence, and until this week it still belonged to the till.

The return screen added up its own refund and sent it with the return, and the refund payment, the drawer’s cash-out and the ledger entry all took that figure as it stood. A till that sent a refund of 5,000 against a sale of 500 paid out 5,000, and the register balanced. It also made seven separate writes, so a failure part-way could leave a return with no lines, or money paid out against no return at all.

A refund is what the sale charged

The till now says which units are coming back and in what state. The server reads the original sale and refunds what the customer paid for each unit: the line’s total divided by its quantity. That line total is one the server priced in the first place, so the basis of the refund cannot be edited either.

• Never more than was paid. A refund above what the customer paid for a unit is refused, whoever asks for it.
• Less, only for a reason the till can name. A damaged unit may be refunded less than it cost, and so may part of something sold by length. An undamaged unit refunds exactly what was paid; the return screen offers no price box for one.
• Once. A unit has to be on the sale and still marked sold, so one that has already come back is refused. A roll sold by length can only return what is still allocated to its line, so the same length cannot be refunded twice.
• All or nothing. The return, its lines, the units, the refund payment, the drawer’s cash-out and the sale’s return status are written in one transaction. Either the whole return exists or none of it does.
• A quoted total is checked, never used. If the figure the teller quoted disagrees with the server’s, the whole return is refused, nothing is written, and the refusal carries the server’s figures so the teller can see why.

The return is created as pending and settled last, so by the time the ledger entry posts, the return’s lines and the restocked units already exist. The entry carries the server’s refund and the cost of what came back.

Exchanges go through the same door

An exchange is a return whose money goes towards a new sale rather than out of the drawer, and it now takes the same route. The credit is what the original sale charged for the units coming back, written as one exchange tender on the new sale. No cash moves, so no drawer transaction is recorded, and an exchange with no new sale to credit is refused.

With both of the till’s callers on that one door, any other write to a return has its refund figure removed. The server marks its own figure in a way no request can carry, so there is no side entrance left.

Why the arithmetic lives on the server

A screen is a poor place to decide an amount of money, for three separate reasons. It can be wrong: a page left open since yesterday, or a bug in one version of the till. It can be changed: anybody can alter what a page sends. And two screens can disagree: two tills on two versions give two answers to the same question.

The server holds one copy of the sale, so there is one answer, and every till gets the same one. The screen still shows the refund before the customer is paid, worked out the same way and rounded the same way, so nothing a teller sees has changed. What changed is which of the two is believed.

The screen shows the refund. The server decides it.

Three more changes at the counter

The shop’s own payment methods

The checkout used to offer a fixed list: Cash, Card, Bank and Mobile Wallet. It now lists Cash, then the payment methods the shop switched on in its console, by the names it gave them — its card gateway, its mobile wallets, its bank transfer. Each is booked as the tender that method maps to, which reaches the same ledger account as a web order paid the same way, and a test holds the two mappings to each other so they cannot drift apart. Cash-on-delivery methods are not offered at a counter, where the customer is standing in front of you, and a tender the shop has not configured keeps its generic entry.

A report for any period

The till’s report page used to count the first page of the sales list and add up two totals in the browser, which made it a sample from the day a shop rang up its 101st sale. It now asks the server for a period — today, the last seven or thirty days, this month, or any dates up to 370 days — and reads every sale in it: takings, the average basket, discounts, and takings by day, by cashier and by payment method, with cash net of the change handed back. Open and cancelled tickets are shown apart, returns by method, and the net. Days start and end at the till’s local midnight.

Expired stock stays on the shelf

A nightly sweep writes off units past their expiry date, but it runs once a night, so a unit that expired that morning could be sold all day. The server now refuses it at every point it could leave: adding it to a sale, checkout, and taking it on account, each before any payment is recorded or any stock moves. The refusal names the unit’s barcode and its expiry date. Behind those, the unit itself cannot move from in stock to sold or reserved, which covers a web order too. A unit expiring today still sells today, and one with no expiry date never expires.

At the order desk

Four changes in Rutba Orders, where web and phone orders are picked, packed, delivered and paid for.

A list of customers to ring

A shop taking cash on delivery often rings the customer before packing: is the order meant, is the address right, will the cash be ready? The desk now has a To Confirm list of every order not yet out for delivery whose customer nobody has confirmed — cash on delivery by default, oldest first, with the name, the city and a number to tap. The call is recorded against the order with how it was made and a note, stamped on the server with who made it and when. The Confirmed tab shows who confirmed each one, with Undo for a mis-click. A confirmation cannot be recorded once the order has left, because that would say the desk checked something it did not.

Cash drops, confirmed in bulk

When a rider collects cash at the door, the payment is recorded against the order as unconfirmed, and until now accounts confirmed those one order at a time, from inside each order. Cash Drops, under Payments, is now an inbox of every collected payment nobody has confirmed, oldest first, with what each rider is holding. Accounts can tick several and verify them at once, dispute one with a note, or reopen one. Each is still verified through the same single-order door, so a refusal names its order, and a verified cash-on-delivery payment posts its settlement to the books there.

The person who collected the cash does not confirm it

Verifying an order’s payment used to be open to any member of staff, including the orders, till and delivery roles that collected and recorded the cash. Now only an accounts role can: accounts staff, accounts receivable, or the books roles. Read-only accounts viewers are refused as well. The order desk still sees the inbox, but not the buttons.

A rider with no signal

The rider app already kept a run’s doorstep actions on the phone when the signal dropped. Offers, deliveries and availability now do the same: accepting or refusing an offer, marking an order out for delivery, delivered or failed, messaging the customer, and going available or unavailable. Each is kept and sent in order when the signal returns, where before it was a browser alert and a lost tap. A move that has already happened counts as sent when it is replayed, and one the office refuses — an offer that expired in the meantime — waits in the queue bar with Retry and Discard.

What is not done

• A refund to a card is recorded, not sent. At the till, a card refund is written against the sale as a negative card payment; nothing asks the card provider to return the money. On an order’s return, the refund is recorded as waiting for accounts to pay by hand. A refund linked to the payment it reverses, started from the order, is planned and not built.
• The report splits by tender, not by payment method. A till payment records Card, Bank or Mobile Wallet, with the method’s own name in its reference. Until the payment row has a column for it, the report cannot tell two wallets apart.
• Old registers keep an old mistake. Before this, an exchange’s credit could be counted as cash paid out, which can leave an older register showing an impossible expected cash figure. New sales are right; old ones are not corrected, and the report page says so.
• Accounts needs a role in Orders to open the inbox. Cash Drops lives in the Orders app. A copy in the accounts app is separate work.
• No accounts role, no prepaid orders prepared. Preparing a prepaid order waits on a verified payment, and only an accounts role can verify one. A shop where nobody holds such a role has its prepaid orders held until somebody does.
• The confirmation list is a list, not a gate. Nothing stops an order nobody has rung from being dispatched.