Ledgr/Documentation/Logistics
Logistics & fleet
The half of a delivery that happens after the paperwork. Which vehicle went where, who signed for it, what actually came off the truck, and why the one that failed failed.
Logistics is included from Manufacturing upwards. See pricing. It sits at the top of the ladder because it is a second product rather than a feature: nobody Ledgr competes with in South Africa ships proof of delivery at any tier, and the standalone POD apps businesses buy instead are priced per vehicle per month.
What this fixes
A delivery note is a document that describes an intention. It is printed before anybody drives anywhere, it has a box for a pen, and nothing in most accounting systems ever reconciles it against what happened. So when a customer rings in March about a pallet they say never arrived in January, the answer is a driver's memory and a signature on a page in a file — if the page can be found.
What Ledgr captures instead, as data: who signed, where they were standing, when, a photograph of the goods at the door, and how much of each line actually changed hands. Plus, when it went wrong, a reason from a list rather than a sentence nobody can count.
Set up the fleet
- Logistics → Vehicles → Add vehicle
Registration, what it can carry, and the three dates that stop a vehicle at a roadblock: the licence disc, the certificate of fitness, and — for a goods vehicle over 3 500 kg — the operator card. Ledgr warns you thirty days out and keeps warning you after.
- Logistics → Drivers → Add driver
A driver is not a Ledgr user and does not need a login. Capture their licence code and expiry, and their PrDP if they hold one. Adding drivers costs you nothing in seats.
Plan a run
- Plan a trip — a date, a vehicle and a driver.
- Add the loads
The Load planning tab lists every delivery note and pro-forma that is not yet on a trip. Adding one from there is what links the stop to the document and each stop line to its invoice line — which is what lets a short delivery raise a credit note against the right line three weeks later. A stop typed by hand can be signed for perfectly well; it simply cannot be reconciled to anything.
- Order the stops
The sequence is the route. It can be changed until the trip is dispatched — after that the driver is working down the list, so only new work at the end is allowed.
- Dispatch
The trip appears on the driver's phone. Departure asks for the odometer reading, which is what the trip's distance, its fuel consumption and its cost per drop are all worked out from.
Proof of delivery
At each stop the driver records what happened: delivered in full, part delivered, or not delivered. A part delivery asks for the quantities line by line, and a failure asks for a reason from your own code list — which ships with the ones a South African delivery actually fails for, load shedding included.
Ledgr will accept a thin proof. That is deliberate: a signature pad that blocks a driver from closing a stop is a signature pad drivers work around, and a business then has a proof of delivery that is a lie rather than one that is thin. What it does instead is grade every proof and say so plainly:
- Strong — signed, named, located at the address and photographed. This is what you show an insurer and expect the conversation to end.
- Adequate — signed or photographed, and located. Believed in the ordinary case, short of what settles a determined dispute.
- The driver's word — recorded honestly, with nothing attached.
The grade is on the stop, on the printed proof, and rolled up on the performance tab. It is a number a business can move: "84% of our deliveries are signed and located" is a target; "we have delivery notes" is not.
What happens to stock
Goods move when they leave the vehicle, not when the invoice is raised — the same rule job cards use for parts. Deliver against a delivery note and Ledgr posts the stock movement at the door, costed from the batches. Deliver against an invoice and it posts nothing, because the invoice already took the goods out when it was raised. Posting twice would show a shortfall that never happened and report the margin on that sale at roughly nothing.
The driver app
Ledgr publishes the driver-facing API so an in-cab app can be built against it — yours, or one built for you. Drivers → Issue link mints a credential scoped to one driver, which the app sends as an ordinary bearer token. Three things worth knowing:
- It is shown once. Ledgr cannot show it again — issuing another retires the one the driver is holding.
- Withdraw takes effect on the phone's next request, not at expiry. A lost handset is a thirty-second problem.
- It expires in ninety days by default, and can never be made permanent.
The endpoints are listed in the API playground under Driver app. They are shaped for a phone in a bakkie: one request per screen, nothing to look up elsewhere, and every write safe to retry — a proof carries a client-minted reference, so replaying a capture queued while out of signal returns the stored proof rather than creating a second one.
If you already run a tracking provider, their feed can post positions to
/api/logistics/positions against the vehicle id their system knows,
with no mapping table at your end.
What it tells you afterwards
- Success and on-time rates. On-time is measured only against stops that carried a promised window — a business that promises nothing has no on-time figure, which is different from having a bad one.
- Why deliveries failed, in order, with the chargeable ones marked. Most SMEs never bill for a wasted trip because they cannot evidence whose fault it was.
- Cost per drop and litres per 100 km, per vehicle, from the odometer readings and the fuel you captured.
- Odometer distance beside tracked distance. Where the two disagree is usually the most useful line on the page.