The Count Is the One Thing the Phone Cannot Do Offline

Every offline demo is run in a room with good wifi. Somebody switches the phone to aeroplane mode, taps three things, switches it back, and everyone watches a little counter go from three to zero. It is a genuine capability and it is genuinely worth having. It also tells you almost nothing about the operation you are actually worried about, which is the one where two people spend four hours on a basement floor with a clipboard and a phone, counting every box in the branch.

So here is the specific answer, in one sentence, before the reasoning. Our mobile app will queue four operations offline — a stock transfer, an inventory check-in, an inventory check-out and an asset movement — and a stock count is not one of them. The count screens are on the phone and they work, but they need a live connection to the server for every step.

The rest of this post is the part that is more useful than the sentence: what the offline queue actually does, why counting is a different shape of problem from the four things that queue, and what a pharmacy should do about it on the night.

The four things the phone will hold for you

That last row is broader than it looks — eight distinct asset actions ride on one queued operation type, including verification, which is the one a pharmacy doing an equipment walk-round would use most.

The queue underneath those four is properly built, and it is worth describing because it is the part that determines whether offline capture is trustworthy or merely present.

• Every operation carries an idempotency key. If the phone pushes and the response is lost, the retry does not create a second transfer.
• Order is preserved on a transient failure. If a push fails for a reason that might succeed later — the network drops mid-sync — the operation stays pending and the sync stops there rather than skipping ahead and applying later work first.
• Permanent failures are separated from transient ones. An operation the server has definitively rejected is marked failed and set aside, with the error message kept against it.
• You are told, app-wide. An orange strip across the top of every screen reads "Offline mode", and once you are back online it keeps showing while anything is queued or failed, with the counts.
• You can inspect the queue. There is a screen listing every queued and failed operation, and a detail screen for any one of them showing what it was and why it failed.
• The subscription is checked before anything is pushed. On reconnect the app verifies the plan with the server first; if it has lapsed, queued work stays put rather than being pushed into a closed account.

Counting is on the phone. Counting offline is not.

This distinction gets lost, so it is worth being blunt about. There are four inventory count screens in the mobile app: the list of count sessions, the setup form, the counting form itself and the session detail. They are real screens with real functionality. A pharmacy technician can run a full count session from a phone — see their assignment, enter counted quantities, submit, watch variances resolve.

None of those four screens contains a single line of offline handling. No connectivity check, no queueing, no local draft. Search all four for any reference to the offline system and you get nothing. They call the server, and if the server is not reachable, the call fails like any other failed request. The app-wide orange strip will tell the counter they are offline; the count screen itself will not do anything clever about it.

The four operations that queue are all deltas. A count is not a delta. It is an assertion about absolute state at a specific moment, and a stale absolute is worse than none.

Why a count is a different shape of problem

It is tempting to assume counting was left out of the offline queue because it was further down a list. That is not the reason, and a buyer evaluating this is better served by the real one.

Look at what the four queueable operations have in common. Every one is a change relative to whatever is there. Move five boxes from A to B. Issue three units. This asset is now with that person. Those instructions are still correct six hours later. They can be applied in order against whatever state the server has reached in the meantime, and they land where they should. That property is what makes them safe to hold in a pocket.

A count says something categorically different: there are forty-two of these here, right now. That statement is only true at the instant it is made. Push it six hours later, against a system where four have been dispensed and a delivery of thirty has arrived, and you are not applying a delta — you are overwriting the truth with a photograph of the past, and generating a variance that describes nothing that happened.

The lock is the real reason

There is a second, harder reason, and it is specific to how counting is built here rather than a general observation about distributed systems.

A count session in this product can freeze the stock it is counting. It is an option on the session, with a start and an end, and while a session holding that freeze is open, counting, submitted or awaiting approval, the items in it are locked. That is not advisory. Any attempt to move locked stock through the inventory service raises an error and refuses: this item is locked by an active inventory count session.

That lock is a promise the server makes to every other user at once — to the till, to the receiving bay, to the other branch requesting a transfer. A phone with no connection cannot hold that promise. It cannot take the lock, cannot know a lock was taken while it was dark, and cannot honour one it never heard about. Offline counting against a freeze-capable session is not a queueing problem; it is a promise the device is not in a position to make.

The frustrating part: the device already has the data

None of the above means the gap is small. It is worth seeing how close the pieces already sit, because it tells you what a fix would involve if you ever wanted to commission one.

The app caches a substantial reference set on the device: the item list, item form data, locations, warehouses, units of measure, adjustment reasons, assets, custodians, asset policy, recent asset movements, recent adjustments, and inventory levels. It also caches custom field definitions for nine modules — and one of the nine is inventory count sessions.

So the phone already holds the items, the locations and the stock levels a count screen would need to display with no signal. The queue that would carry the results already exists, with idempotency and ordering. The banner that would tell the counter what state they are in is already on every screen. What is missing is not the parts. It is the wire between the count screen and the queue — plus an answer to the two questions above, which is the part that takes real thought rather than real typing.

What to actually do on stocktake night

This is the practical section, and it assumes you are running the count in a place where signal is unreliable — a basement, a back store, a rural branch on a mobile hotspot.

1. Test the signal where the stock is, not where the counter sits

   Walk the actual route with the app open a week before. The strip at the top of the screen turns orange the moment the connection drops, so you get a free survey by watching it. Note the dead spots.

2. Decide the fallback before you need it, not at 21:00

   If a section of the branch has no signal, that section gets counted on paper and entered afterwards. Agreeing that in advance turns an outage into a procedure. Discovering it mid-count turns it into an argument.

3. Do not run a frozen session across a dead zone

   If the session holds a stock freeze and counters cannot reach the server, they cannot submit, and the freeze stays on — which blocks the till and the receiving bay for as long as it takes. Either the signal is reliable where you are counting, or the session should not hold the freeze.

4. Use the four queueable operations freely

   Transfers, check-ins, check-outs and asset movements really do survive a dead connection. If part of stocktake night is moving stock between locations or verifying equipment, that part is safe offline and you should lean on it.

5. Check the queue is empty before anyone goes home

   The strip shows pending and failed counts, and the queue screen shows each one. An operation sitting failed is a movement that did not happen, and the morning after a stocktake is the worst possible time to discover one.

The question worth asking every vendor

Offline is the single most over-claimed capability in this category, because the demo is easy and the boundary is invisible. These questions find the boundary in about two minutes, and they work on us as well as on anyone else.

The fourth question is the one that separates products that thought about offline from products that added a queue. There is no free answer to it. A vendor who answers immediately and specifically has been through it; a vendor who says "it syncs automatically" has not.

A narrow offline capability that is honestly described is worth more than a broad one that is vaguely described, because you can plan around the first and you cannot plan around the second. Four operations, mobile only, with a real queue underneath — that is the shape of it, and now stocktake night can be planned against a fact.