The sync queue, Perlu perhatian and stuck items

Labels in bold are written exactly as they appear in the app.

Opening the queue

1. Tap Lihat (View) on the offline pill or the sync strip. Antrian sinkron (Pending sync) opens: "Items saved offline that haven't reached the server yet. Discard only items you're sure are duplicates or invalid."
2. Each row shows the number or name (e.g. OFFLINE-4F2A9C or a bill name), the kind (Transaksi or Bill), its age, Percobaan (Retries: how many sends failed) and, if present, the last failure reason. Empty reads "Tidak ada item menunggu sinkron." (nothing is waiting).
3. Automatic sending retries with growing gaps (5 seconds, 10, 20, 40 and so on, at most 10 minutes). After 3 failed tries the row gets a red Perlu perhatian (Needs attention) tag and the marker on the strip lights up. It only means "a person should look"; the system keeps trying.

What the reasons mean

• "Tidak ada koneksi ke server..." (no connection) and "Server terlalu lama menjawab..." (server too slow): network trouble. Get online, tap Sinkron sekarang, wait.
• Any other text is the server's own message. A referral-code refusal (REFERRAL_... codes) will not fix itself; the row goes straight to Perlu perhatian and retries only every 10 minutes.
• Bills and their sales are sent in order: an offline-made bill goes first so its payment links to it.

What staff and the owner do

1. Read the reason, make sure the device is online, tap Sinkron sekarang.
2. If still stuck, open Transaksi (filter Hanya Luring) and look for the number: if the sale is already there, the queue row is a duplicate and can be discarded.
3. If it is not in Transaksi and the reason is a server refusal, do not discard yet: tell a manager or the owner with the written reason, because discarding means the sale never reaches the server.
4. To discard: tap the trash icon, then Buang in Discard this item? ("This permanently removes the queued item from this device. The action is logged for the owner. Only discard if you're sure it's a duplicate or invalid."). No PIN or approval is asked. Discarding a sale also removes an offline bill that existed only for that sale.
5. The owner sees the trail in the Log Audit: the action "Offline sale discarded", resource "Offline queue", with number, total, retries, failure reason and creation time (Audit trail and common mistakes explains reading the Audit Log).

Replay rules (sales sent later)

• Shift: a sale carries the shift it was rung on and is still accepted after that shift was closed or force-ended.
• Paket: the selling-schedule and daily-limit checks for packages are not applied to queued sales. The other limits in Limits and refusal messages describe live sales.
• Time: a late-arriving order is normally given the time it was made on the device, not the arrival time (the server only moves it earlier, and not before the shift), so busy-hour reports do not shift.
• Bill discount: if the bill was deleted while the device was away, its discount value is filled back onto the order when the discount permission is still held.
• A sale that arrives by replay is tagged as offline-origin (the Luring badge in Transaksi).