All guidesCounter sale
Recover sales the till has not sent yet
What happens to a counter sale when the connection drops, and why re-sending one can never charge a customer twice.
- Steps
- 4 · About 3 min
- Who can do this
- Owner · Manager · Team member
- Needs the module
- Counter sale
Before you start
Connections drop, browsers get closed, tablets run out of battery. In a shop none of that is an emergency, because of one decision in how the till works: a basket is saved on the device before it is sent, not after sending fails.
By the time an assistant presses the button, the goods have gone over the counter and the money is in the drawer. The sale has already happened. Saving it first is the only order in which it survives whatever happens next.
The waiting count
When a sale has not been confirmed by the server yet, the till shows how many are waiting. Most of the time you will never see it — a sale is queued and cleared within a second.
If the number stays up, the connection is down. Keep serving. Sales keep being taken and keep being held, and the count tells you how many are owed to the server.
Re-sending is always safe
This is the part worth trusting, because it is what stops people doing damage while trying to help.
Every basket carries its own reference. When the till sends a sale the server has already seen, the server answers with the sale it recorded then — it does not record a second one. So a sale can be sent twice, or five times, and the customer is charged once.
That is why the till simply retries, and why you never have to work out whether one got through.
What not to do
Do not ring the sale up again. Re-sending is safe; re-ringing is not. A fresh basket is a new reference, and a new reference is a second sale — the one thing the design cannot protect you from. If you are unsure whether a sale landed, wait for the count to clear and look for it in the day's sales. It is almost always there.
Do not clear browser data on the till device while sales are waiting. The queue lives in that browser's storage, under the till session it belongs to. Clearing it discards the sales, and there is nothing anywhere else to recover them from.
Before you close the till
Close the session only once the waiting count is zero.
Closing while sales are still waiting produces a difference nobody can explain: the cash is in the drawer, the sales are not yet in the system, and the difference reads as a shortage rather than as a queue. Wait, then count.
If the connection is still down at closing time, count the drawer and write the figure on paper, then close the session once the sales have gone through. A number written at the time is evidence; a number reconstructed the next morning is a guess.
The queue belongs to the device and the till session it was taken on. Sales waiting on one phone will not send from another, and they appear nowhere until that device is back online. If a till device is lost or wiped while holding waiting sales, those sales are gone — which is the real reason to check the count is zero before walking away from a shift.
Next, you might want to
- Take a counter saleScan or search, take cash, card or cheque, give the change, and print the ticket.
- Close the till and count the drawerEnd the day by counting the cash and comparing it against what the register expected.
- Why nothing here is ever editedHorizon213 corrects mistakes by posting the opposite, not by changing what was written. This is the rule behind almost every "you cannot" in the guides.