The store loses connectivity, continues through its permitted contingency process and reconnects later. The sales dashboard catches up quickly. A few fiscal documents remain unresolved, stock moved twice during a retry and finance cannot explain why the payment total differs from the exported sales total. Online again is not the same as reconciled.
For a Brazilian retailer buying point-of-sale integration or custom store software, recovery should be a first-class workflow. The product needs to explain what happened to every sale across its payment, inventory and fiscal records. A single synchronised badge hides too many independent outcomes.
Scope the fiscal route with the responsible specialists
The national NF-e portal's manuals collection includes technical documentation for NFC-e and offline contingency. The NFC-e contingency annex provides a primary reference for that mechanism. Use the versions and technical notes applicable to the actual operation, with the retailer's fiscal adviser and issuing-software provider.
Do not infer one universal permission, deadline or correction process for every state and business from a generic blog. Confirm where NFC-e is applicable, which contingency route is permitted and who owns subsequent transmission and resolution. These decisions define the software's operating envelope.
Within that envelope, engineering can make the process durable and observable. It cannot turn an unauthorised workflow into an acceptable one by storing a receipt locally or adding a QR code to a printout.
Give each sale a durable local identity
An offline sale needs an identifier that survives application restart, reconnect and central import. Link its line items, payment attempts, inventory movements and fiscal-document references. Keep those relationships even when a later correction changes the commercial outcome.
Consider an illustrative shop with two tills. Both reconnect after an outage, and one retries an upload because the acknowledgement was lost. If the central system treats each upload as a new sale, the store's stock can be reduced twice. The cashier may never notice because both screens show successful completion.
Make repeat delivery safe at the business-operation level. Store the original operation identity and detect whether its effect has already been applied. A transport message identifier alone may not be enough when an application recreates messages after restart. Test the identity path through the actual POS and ERP interfaces.
Preserve the sale without pretending every part succeeded
Payment collected, goods handed over, fiscal document queued and document authorised are separate facts. Represent them explicitly. The store manager should be able to find a completed commercial sale with an outstanding fiscal task without losing sight of either state.
Do not silently replace a rejected document with a new commercial sale. Keep the rejection evidence, the source data and the next action under the agreed fiscal process. If correcting a customer or product field is permitted, record the correction and its author. Retain the original relationship so the back office can follow what changed.
This is also where responsibility matters. Cashiers should not receive a technical error they cannot resolve, while accountants should not have to browse every successful transaction to find the exceptions. Route each issue to the role able to take the next legitimate action.
Store recovery work where a restart cannot erase it
A pending queue should be durable on the device or store system used for the permitted offline workflow. Define how it behaves when the application closes, storage is nearly full or the device is replaced. A browser tab with unsaved state is a weak foundation for business records.
Keep the original payload and the result of each transmission attempt according to the agreed retention policy. Protect signing material and fiscal credentials using the issuing provider's supported architecture. Do not scatter certificates or secrets across ad hoc scripts to make testing easier.
On reconnect, control the rate of work and preserve ordering where the business process requires it. A burst of retries should not overwhelm the destination or obscure the oldest unresolved items. Alert on the age and reason of failures, not just the total number of queued messages.
Reconcile stock and money independently
Inventory recovery should use the sale's business identity and the type of movement: sale, return, correction or transfer. Do not equate a fiscal retransmission with another stock movement. Establish which system owns the available-to-sell quantity and how other channels learn about offline activity.
Payments need their own reconciliation. A cancelled sale, an approved refund and a fiscal correction may proceed through different systems and timescales. Show what each system has confirmed instead of assuming that one successful action completes the others.
An operations report should explain the difference between store totals and central totals. Useful categories include awaiting import, payment outcome unresolved, fiscal response awaiting review and inventory adjustment awaiting approval. A single unexplained difference forces the finance team back into spreadsheets.
Make the acceptance test include the power switch
For a pilot, choose one store workflow and the actual destination interfaces. Simulate an interruption after local recording but before acknowledgement, a repeated upload, a rejected fiscal document and a delayed payment notification. Restart the application during recovery and confirm that no intended sale disappears or applies twice.
Then ask the store manager and fiscal team to resolve the test cases using the application, without direct database edits. If they need an engineer to identify every failed record, the release is still missing an operational interface.
Agree how updates to fiscal specifications reach the product backlog and how changes are tested before rollout. Keep the POS core usable while an integration service is degraded within the permitted operating process. The support agreement should say who diagnoses a store-side issue and who escalates to the issuing provider.
Buy recovery as a deliverable
A credible proposal includes the data model, durable queue, reconciliation screens, security arrangements, counterpart testing and a support runbook. Separate these from optional dashboard design so buyers can compare the work that determines operational reliability.
Our idempotent pipeline guide explains repeat-safe processing, and the integration scope guide helps assign ownership. TuniCyberLabs offers custom software development for store and back-office integration. Discuss an offline retail recovery pilot with your POS, ERP, fiscal provider and the specific unresolved records your team currently repairs after an outage.