Software demonstrations happen on good connections. Shops, warehouses, delivery routes and remote branches do not.
An offline ERP claim usually turns out to mean a browser tab that shows a friendly error. In Nama it means something physical: on the paths where an outage would actually cost money, the data lives on the device first and travels to the server afterwards.
The till is a desktop application, deliberately
Most of Nama runs in a browser. The point of sale is the exception — a dedicated desktop application running on the register itself — and the reason is stated plainly in its own documentation: a point of sale cannot stop selling just because the internet went down.
Every register keeps its own local database. An invoice, a return, a payment, a shift opened or closed, a stock count: each is written locally first. It is saved, it is on screen, it can be printed for the customer. At that moment it is unsent — real, but not yet at head office.
In the background the register keeps trying to send. Once a document arrives, it becomes a permanent record in the central system: visible to head office, posted to accounting, in the company-wide reports. Offline, documents simply queue, and the queue drains the moment the line comes back.
The prices and stock shown while offline are whatever was last cached, so they may be slightly behind. That is the trade, and it is the right way round.
One stuck document does not stop the rest
Sync is invisible until it isn’t. If a document fails to upload, the register counts the failure against it, and after 25 attempts it stops retrying that one — so a single bad document cannot jam the queue behind it.
The usual causes are ordinary: the server was unreachable, the customer has since been blocked, the item no longer exists, the credentials were rejected. The document waits, unsent, until somebody fixes the cause; then the counter is reset and it goes up. Resetting without fixing just fails again, which the documentation says in those words.
The field is the same story
Nama Mobile is offline-first for the same reason. The app downloads the data it needs locally at login and syncs its documents whenever the network is available, so the rep writing an invoice at the customer’s site, the warehouse keeper scanning barcodes, the technician documenting a visit and the driver capturing a signature are not waiting for coverage to do their jobs.
And for a site, not just a device
Where the problem is a whole location rather than a moment — a branch on a poor line, or servers in different countries — replication keeps several Nama sites in step, packaging records created at one site and delivering them to the others, with the routing driven by the dimensions on the record. Replication is licensed separately from the core system.
None of this is glamorous. It is simply the difference between a system that assumes the network and one that was built by people who have watched it fail.
Good question — already answered
What happens at the till when the internet drops?
Selling carries on. Every sale, return, payment and shift is written to the register's own local database first, and queues as unsent. When the connection returns the queue drains to the server on its own. An outage never costs you a shift's sales.
Are prices and stock accurate while offline?
They are whatever was last cached, so they may be slightly behind. That is the honest trade — the register keeps selling against local data rather than stopping, and it pulls fresh prices, items and configuration the moment it is back online.
What if one document will not upload?
The register counts failures against that document and stops retrying it after 25 attempts, so a single bad document cannot jam the queue. It waits, unsent, for someone to fix the cause — a blocked customer, a deleted item, a credentials problem — after which the counter is reset and it goes up.
Does the mobile app work offline too?
Yes. It downloads the data it needs at login and syncs documents when the network is available, so a rep writing invoices at a customer's site or a driver capturing a signature is not waiting on coverage.
What about a branch with a bad line, not just a bad moment?
That is what replication is for: several Nama sites kept in step, with records created at one site packaged and delivered to the others, routed by dimension. It is licensed separately from the core system.
