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. Submit the shift action once, read whether it was queued, and keep the terminal on the same branch and user context. 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
- Submit the shift action once.
- Read whether it was queued.
- Keep the terminal on the same branch and user context.
- Reconnect and verify the shift history before proceeding.
Expected result
The local shift action remains queued once and later reconciles to one server shift record after reconnection. 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
POS does not let staff submit the shift action once; they cannot continue to read whether it was queued.
Verify these conditions before another test: An authenticated POS session on the intended branch and terminal. The local sync indicator and queued transaction count are visible before recovery begins. Keep the same branch and record, reopen /shifts, and try the blocked action once. If it still fails, stop and send Support the queue reference, terminal ID, branch, action, safe record reference, error, retry count, and time. Record the visible response when staff submit the shift action once.
The local queue and server order, payment, or shift record do not establish one synchronized result after the final checkpoint: Reconnect and verify the shift history before proceeding.
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. An unresolved mismatch needs Support review with the queue reference, terminal ID, branch, action, safe record reference, error, retry count, and time. Confirm from the records whether staff could reconnect and verify the shift history before proceeding.
Related articles
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.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