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. Read the sync status before taking action, when offline, note the queue reference and allowed method, and reconnect the terminal. 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
- Read the sync status before taking action.
- When offline, note the queue reference and allowed method.
- Reconnect the terminal.
- Wait for synchronization and verify Orders, Payments, or Shifts.
Expected result
The sync indicator distinguishes offline, queued, syncing, failed, and fully synchronized states with queue depth. 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
The workflow stops while staff read the sync status before taking action, before they can when offline, note the queue reference and allowed method.
First confirm the following access and record state: An authenticated POS session on the intended branch and terminal. The local sync indicator and queued transaction count are visible before recovery begins. Return to /billing without changing user, branch, or record. Try the blocked step once; if it remains unavailable, stop and provide Support the queue reference, terminal ID, branch, action, safe record reference, error, retry count, and time. Keep evidence of the result when staff read the sync status before taking action.
The local queue and server order, payment, or shift record do not establish one synchronized result after the final checkpoint: Wait for synchronization and verify Orders, Payments, or Shifts.
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. When no single result can be proved, pause and provide Support the queue reference, terminal ID, branch, action, safe record reference, error, retry count, and time. Before another attempt, establish whether staff could wait for synchronization and verify Orders, Payments, or Shifts.
Related articles
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.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 in TajerGo
Sign in with the appropriate role and confirm your Business Account and branch before continuing.
Read as Markdown · Guidance for support agents
Last reviewed 2026-09-06 · Send documentation feedback