POSOffline and recovery

Recover failed or blocked queued work

Sync recovery distinguishes retryable connectivity failure from business rejection and protects queued work during branch switch or logout. Open the sync status, read the failed item and error, and restore connectivity and retry through the offered control. Queued means stored on this device, not completed on the server; reconnect and verify the final record before retrying.

Before you start

An authenticated POS session on the intended branch and terminal.
The local sync indicator and queued transaction count are visible before recovery begins.

Steps

Open the sync status.
Read the failed item and error.
Restore connectivity and retry through the offered control.
Verify the server record.
Contact support with queue count and error if it remains failed.

Expected result

Each retryable queue item reaches one server record, while rejected items remain visible for controlled correction. Queued means stored locally, not completed on the server; do not recreate or delete the transaction while its outcome is unknown.

Permissions

POS access for the active branch is required; business rejections may need a manager to correct the original order, payment, shift, or configuration.

Troubleshooting

Staff cannot open the sync status because the control is missing, disabled, or rejected before they read the failed item and error.

Check the required state before trying again: An authenticated POS session on the intended branch and terminal. The local sync indicator and queued transaction count are visible before recovery begins. Check those conditions on /billing and repeat only the blocked step once. Preserve the screen and ask Support to review the queue reference, terminal ID, branch, action, safe record reference, error, retry count, and time. Note whether POS changes as staff open the sync status.

The local queue and server order, payment, or shift record do not establish one synchronized result after the final checkpoint: Contact support with queue count and error if it remains failed.

Keep the same branch and inspect the queue, sync status, and matching server record after reconnection. Never repeat queued or syncing work. Retry only when the queue is clear and the server proves the action absent. If those records still disagree, stop and send Support the queue reference, terminal ID, branch, action, safe record reference, error, retry count, and time. The final evidence must establish whether staff could contact support with queue count and error if it remains failed.

Understand POS offline and sync status
The register displays connectivity, local queue depth, sync progress, last error, and recovery state; queued does not mean completed on the server.Handle an offline checkout safely
Current checkout code can queue eligible order or payment work, while scheduled orders, Khata, loyalty redemption, split payment, and unsupported methods require a live connection.Handle an offline shift action safely
Shift open or close can be saved locally when connectivity fails; the drawer is not open or finalized on the server until synchronization succeeds.