Designing Offline Fiscalisation Without Losing Control of State

Separate the local sale from server acknowledgement

A reliable workflow gives the local document a durable identity before attempting network transmission. The record, line items, taxes, payments, device identity, fiscal day, and sequence state should commit atomically. Synchronization then advances through explicit queued, sending, acknowledged, rejected, and intervention states.

A vague online or offline flag is not enough. Operators need to know whether the sale is recorded locally, whether a fiscal submission is pending, and whether the receipt can be treated as acknowledged.

Make retries idempotent

• Assign a stable client event or document identifier once and reuse it for every retry.
• Treat timeouts as an unknown result until the server can confirm whether it accepted the original event.
• Never generate a new fiscal sequence merely because a request is retried.
• Persist attempt count, last error, next retry, and the authoritative acknowledgement.
• Quarantine non-retryable validation or state conflicts for review instead of looping forever.

Protect device and fiscal-day state

Device identity, certificate state, fiscal-day number, receipt counter, and last acknowledged sequence form a connected history. Restoring only part of that history can create duplicates or gaps. A recovery process should compare local and server snapshots and stop when both sides have advanced independently.

Closing a fiscal day should have preconditions: no unresolved state conflict, a defined policy for pending work, a captured accumulator snapshot, and a durable close result. The interface should show which device and day are active before a user commits a document.

Monitor the queue as an operational system

• Oldest queued-event age and count by workspace and device.
• Repeated validation, authentication, certificate, and fiscal-state errors.
• Sequence gaps, duplicate identifiers, and acknowledgements that arrive after a timeout.
• Certificate expiry, prolonged open fiscal days, and devices that stop checking in.
• Restore-package downloads and every privileged reconciliation decision.

Test the uncomfortable paths

Automated tests should cover network loss before and after server acceptance, app termination during a write, duplicate taps, rejected tax configuration, clock and currency edge cases, concurrent device use, and restore conflicts. A release is not ready because the happy path can print a receipt; it is ready when interrupted work has a deterministic outcome and support can explain the evidence.