Ledgr/Documentation/Offline & load shedding

Offline & load shedding

A South African accounting system that stops when the power does is not an accounting system. Ledgr keeps working with no signal, replays what you captured when the connection comes back, and is honest about the handful of things that genuinely cannot wait.

How it works

When you save something offline, Ledgr writes it to the database on your own device and puts it in a queue. The screen updates immediately — your invoice is in the list, your expense is in the total — and the queue empties itself as soon as there is a connection.

Every queued write carries an identifier your device generated at the moment you pressed save, and that identifier becomes the record's permanent id on the server. That is what makes a replay safe to repeat: if the connection drops after the server accepted your invoice but before your phone heard the reply, the retry lands on the same record instead of creating a second one. Duplicate invoices are the classic failure of offline accounting apps and this is the specific defence against it.

What you can capture offline

What needs a connection, and why

Everything else is online-only, and the app says so on the screen rather than letting you capture something that will fail later. Two rules decide it:

• It moves real stock at a real cost. Issuing a part to a job takes a specific batch out of a specific bin at what that batch cost. Two technicians offline in two different vans cannot both be given the last one, and guessing produces a stock figure that does not reconcile to the ledger.
• It mints a number somebody else relies on. Converting a job card to an invoice allocates a document number and posts to the general ledger. Two devices offline would allocate the same number to two different customers.

So on a job card the card queues and what happens on it does not. That split is deliberate: the field work — raising the card, logging the hours — is exactly what happens where there is no signal, and it is the half that can be made safe.

Payroll, bank reconciliation, approvals and anything in production are online-only for the same reasons.

Watching the queue

Settings → Sync shows the connection state, how many writes are waiting, and anything that failed. The top bar carries the same state as a pill, so you always know which mode you are in without opening a screen.

Failures are told apart rather than retried blindly:

• A temporary failure — the server was busy, the connection dropped mid-request — is retried automatically, backing off so a flat connection is not hammered.
• A permanent failure — the customer was deleted while you were offline, a field was rejected — stops and is shown to you. Retrying it forever would only hide it.
• If your session expired while you were away, the queue simply waits. Nothing is lost and nothing is retried until you have signed back in.

Load shedding specifically

Load shedding is a connectivity problem before it is a power problem: the phone still has battery, but the fibre router and the tower on the corner do not. Ledgr treats it as an ordinary offline period — there is no separate mode to switch on and nothing to remember to do beforehand.

Two places elsewhere in Ledgr know about it by name. Scrap on the production screen counts a cycle cut mid-process as its own reason rather than as a quality failure, and the delivery exception reasons in logistics include it, because it is the most common reason a South African delivery is turned away at the door.

Two devices, one business

Work captured on a phone in the field and work captured on a laptop in the office are separate queues that both land on the server. They do not see each other until they have both replayed — so a job card raised on site appears on the office screen once the phone has a connection, not before.

That is worth knowing when two people are working the same job in the same hour. It is also why the things that must not be duplicated stay online-only.