The Field That Is Checked and Discarded
A sale submitted from a device can name the warehouse it came out of. The field is accepted, checked, and then thrown away in favour of the one attached to the till — which is the safe answer, and it makes the field a liability in a place nobody looks: the key that stops a sale being rung twice.
There is a category of software defect that produces no wrong answers, no error messages and no security exposure, and is still worth finding. This is one: a value you can send that is carefully checked and then completely ignored.
On its own that is untidy. It becomes interesting because of where the ignored value ends up.
What happens to the field
A sale arriving from a till app can state which warehouse it came out of. The request is validated, so a nonsense value is rejected. The value is then recorded as part of the request's fingerprint — the short summary used to recognise the same sale arriving twice.
And then the sale is written using the warehouse attached to the counter, looked up fresh, scoped to the business and to the cashier who is signed in. Stock comes out of that warehouse. The receipt says that warehouse. The submitted value has no effect on anything.
The safest possible handling of an untrusted input, and it leaves the input sitting in the one place where a value that does nothing can still do something.
Why ignoring it is right
Worth saying clearly, because the fix here is not "use the submitted value". A till belongs to a counter, a counter belongs to a place, and the cashier signed in at that counter is not the right party to decide which warehouse the goods leave. Taking it from the counter means a device cannot sell stock out of a store it is not standing in, whatever it sends.
That is the correct design and it is properly implemented. The counter is loaded against both the business and the signed-in user, so there is nothing to be gained by sending a different value. Nobody can move stock anywhere by asking.
The part that is not right
A till submits a sale over a connection that is, on a good day, unreliable. The request goes, the network drops, and the app does not learn whether it arrived. It has to try again, and the entire business of the fingerprint is to make the second attempt safe: same fingerprint, same sale, one basket.
The fingerprint includes the warehouse the app sent. So two requests for the same basket, differing only in a value that changes nothing about the outcome, produce two different fingerprints — and are therefore two different sales.
-
The sale is submitted
With whatever warehouse the app had in its state at that moment. The server records it, ignores it, and writes the sale against the counter's warehouse.
-
The connection drops before the reply arrives
The app has no idea whether the sale exists. This is the ordinary case on a market stall, in a basement, or on a bad afternoon — not an edge case.
-
The app retries — and something has refreshed
A synced setting, a re-read of the counter, a user switching store on the device. The warehouse in the retry differs from the warehouse in the original.
-
A second sale is created
Correctly, by the rules as written. The two requests are not identical, so they are not the same sale. The customer is charged once and the books record two, and both are against the same warehouse, because the field never mattered.
The failure needs the retry and the change together, so it is uncommon rather than routine. It is also silent, produces a real duplicate in the accounts, and is invisible from the shop floor, because the two sales look identical and nobody rang the second one.
The reasoning was already done once, for a different field
This is the detail that makes it instructive rather than embarrassing. The signature a customer draws on a screen is deliberately excluded from the fingerprint, and the code says why: a retry where the customer signed again would produce different strokes, hash differently, and be treated as a second sale. Ringing the same basket twice was judged a far worse outcome than a replay landing without the redrawn mark.
That is exactly the right analysis. It was applied to the field where the problem was obvious — a drawing is different every time — and the two location fields, which are stable almost always, were not revisited.
The rule this suggests
A duplicate-request fingerprint should be built from the inputs that determine the outcome, and nothing else. Every additional field is a way for two identical operations to look different. The test is not "is this field part of the request" but "if this value changed and nothing else did, should this be a different transaction?" For the warehouse on a till sale the answer is no, because the server does not use it.
Three questions for anybody whose till submits sales over a network
What stops the same sale being recorded twice after a dropped connection?
What you will hear
A description of a duplicate check.
How to read it
Every serious till has one. The question separates products that thought about the shop from products that assumed the network works.
What exactly goes into that check?
What you will hear
A pause, then "the whole request".
How to read it
The whole request is the intuitive answer and the weak one. Anything in it that varies between two attempts at the same sale defeats the protection, and the fields most likely to vary are the ones the server does not even use.
Which fields on a sale does the server ignore?
What you will hear
Rarely asked, rarely answered.
How to read it
A good sign if they can answer at all. A field the server overrides for safety is correct; the same field inside the duplicate check is a small hole in the safety net, and the two decisions are usually made by different people at different times.
The short version
Overriding a client-supplied warehouse with the one attached to the till is the right call, and it is what stops a device selling stock out of a store it is not in. Keeping that same value inside the fingerprint used to recognise a repeated sale is the mistake, because it lets two attempts at one basket look like two baskets. Duplicate protection should be built from what decides the outcome and nothing else — and the authors of this code already reached that conclusion once, for the customer's signature.
What AWRA OpsHub does today
- Duplicate protection on submitted sales, so a retried request after a dropped connection resolves to the existing sale rather than a second one.
- The warehouse and location taken from the counter, looked up against both the business and the signed-in cashier, so a device cannot sell out of a store it is not attached to.
- The customer signature deliberately excluded from the duplicate check, so a re-signed retry does not become a second sale.
- Sales refused without an open cash session, on the sale and on the payment, so a shift's takings are complete.
- Stock decreased through one allocation path, with the same batch and location rules the rest of the product uses.
More we can add to your workspace
- A duplicate fingerprint built only from the fields that decide the outcome, so a value the server overrides stops being able to split one sale into two.
- A refusal when a submitted warehouse differs from the counter's, so a mis-configured device is corrected rather than quietly overridden.
- A duplicate-sale report, listing sales with identical baskets, amounts and timestamps for somebody to review.
- An acknowledgement the till can trust, letting a device confirm a sale landed rather than inferring it from a reply it may not receive.
Where we point you to a specialist
- The warehouse stays a property of the counter and we would keep it that way. Letting a device name its own source of stock would trade a real control for a convenience, and it is the control that stops a till in one branch drawing down another branch's shelves.
- How a till behaves when it cannot reach the server is a decision about your shop rather than about our software. We would build the confirmation and the retry rules you specify and would decline to choose between selling offline and refusing to sell for you.
- Where a control can be worked around rather than simply waiting to be built, we fix it before writing about it. The counter check holds regardless of what a device sends, which is precisely why this behaviour is safe to describe in public at all.
A tightened duplicate fingerprint, a mismatch warning and a duplicate-sale report are scoped work we can quote on.
Three, and the first is a small change with a real effect
The duplicate protection already exists and works. What changes is what it is computed from.
A fingerprint of the deciding fields only
The basket, the amount, the tender and the counter — and nothing the server overrides. Two attempts at one sale then look like one sale even when the device has refreshed its state in between.
A mismatch warning
Where a device sends a warehouse that differs from its counter's, say so rather than overriding in silence. A mis-configured till is worth knowing about, and today it behaves identically to a correct one.
A duplicate-sale review list
Identical baskets, amounts and times, on one screen, for somebody to confirm or void. The backstop for every duplicate that gets past a fingerprint of any design.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your tills run over mobile data or patchy wifi, the first item is the one to raise.
Talk to us about till reliabilityAsk what is in the fingerprint
Any product that submits transactions over a network has one. Ask what goes into it, then ask which of those fields the server ignores. The overlap between those two answers is where a duplicate gets in.
Talk to us about point of sale