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

There are two halves to this, and the first one is the half people notice.

Reading: every screen you have opened, from your own device first

Ledgr keeps a copy of what the server told it on the device itself. Open a screen and it is drawn from that copy first, then refreshed behind you — so the invoice list, the dashboard, a customer's history and a stock level are all on screen before the network is asked, and they are still on screen when there is no network to ask. This works on every screen, not a chosen few — but only for what this device has already been shown. A screen, a customer or a report you have never opened on it has no copy yet, so open the ones you will need before you lose signal.

If the figures change when the refresh lands, the screen updates itself. If the server cannot be reached, the screen says the figures came from this device rather than pretending they are live.

Writing: it is saved on the device, then sent

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.

It also means the record is real from the moment you save it. It has its final id, it opens, and it does not renumber itself when it syncs. (It is not found by a search until it has synced — see Common problems.)

You can see what has not gone yet

A queued record appears in its own list, where you would look for it, marked Waiting to sync — the invoice in your invoice list, the lead in your leads, the job card on the board. That matters more than it sounds: a message saying "saved" over a list that has not changed is not believed, so the person captures the same thing again, and two captures are the one thing a queue cannot merge.

• Only what you typed is shown. Anything the server decides — a job number, a workflow card's key — reads Number pending rather than a figure that would change later. A figure that changes after you have read it is worse than a blank, because the first one was believed.
• The arithmetic you can trust is still there. A queued invoice shows its real totals, worked out by the same code the server uses, so they are the figures it will store.
• A queued payment is stated, not subtracted. It appears beside the balance on the document it settles rather than being taken off it — somebody else may have part-settled the same invoice since your device last heard anything, and a figure reduced here and declined there is money misstated on a customer's account.
• A write that failed for good stays on the list, badged Not sent. It is still the only copy of something you recorded, and dropping it would make it look deleted.
• Buttons that need the server are withheld on a queued row — sending, approving, converting — because they address a record the server has not been told about yet. Opening and reading it is not withheld.

What you can capture offline

Nineteen kinds of record, across most of the product. The Settings → Sync card lists the same set inside the app, so this is never a question of remembering what a web page said.

Scroll the table sideways to see every column.

The mileage trip is the one worth pointing at: it is logged where the trip happened, which is the only place its odometer readings exist.

Driver mode keeps its own queue. A driver's proof of delivery — who received it, the signature, the quantities and the reason — is kept on the phone with no signal and sent when there is some. So are its photographs: they are kept on the phone with the proof and upload after it is accepted, each exactly once. See the driver app.

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 is a decision about how things are right now. Approving a claim, converting a quote, reconciling a bank account and running a payroll are all judgements about the state of the books as they are — and replaying one made against the state as it was is how a queue quietly does the wrong thing. Converting also assigns a document number and posts to the general ledger, and two devices offline would give the same number to two different customers.

So on a job card the card and the hours queue, and the part issue and the invoice do not. That split is deliberate: raising the card and logging the hours is exactly what happens where there is no signal, and it is the half that can be made safe.

The named exclusions are: approving anything, a stock adjustment, transfer, issue or build, quote-to-invoice and job-to-invoice conversion, payroll runs, SARS returns, importing a bank statement, bank reconciliation, and anything in production. Everything else on the list above works. A workflow card can be created and commented on offline but not moved, because a move depends on where the other cards are and on a limit that cannot be checked with no server to ask.

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.

When two devices changed the same record, the changes are merged, not overwritten. This applies to the edits that work offline — a customer's, supplier's or lead's details. Each device sends only the details it changed, and what each of them said on the copy it was editing. When the changes reach Ledgr:

• A detail only one device changed is saved. Two people fixing different details of the same customer both keep their work.
• A detail both changed to the same thing is simply saved once.
• A detail both changed to different things is not saved from either side. The sync indicator turns to Attention and its panel shows the change under Changed elsewhere with both values side by side: Keep mine sends yours over the other, Keep theirs leaves theirs and still sends any other detail you changed. Until you choose, nothing from that edit is saved — neither version is lost.

The merge is per detail, not per word: two different notes typed into the same notes field are a choice between them, not a combination. An edit that was already saved is never saved a second time, even if the phone sends it again after losing the answer.

Common problems