Load Register

Four separate things, each built on the one before it, all managed from the Border Posts admin screen (opened from the Cheque Requisitions toolbar) except the last:

1. Border Posts — the registry of actual border crossings (e.g. Beitbridge, Kopfontein), each optionally tagged with the country you enter by crossing it. This is just "which crossings exist" — no money involved yet.

2. Border Cost Types — the catalog of fees a specific border can charge (e.g. Beitbridge → "Road Toll", "COMESA", "Carbon Tax"). Each cost type belongs to exactly one border and has a default payee.

3. Border Cost Values — the dated rate history for a cost type (amount + currency + effective date + optional note). Adding a new value never overwrites an old one — it inserts a new dated row, and whichever has the latest effective date is the "current" rate. This is how a toll that goes up on 1 March still shows correctly on trips from before that date.

4. Border Costs (a.k.a. a border cost schedule) — the "🌍 Border Costs" button on an individual trip. Selecting a border crossing there builds a real per-trip schedule, with each line snapshotted from that border's current cost types/values at that moment — editing the catalog afterwards never changes an already-created schedule line.

Enter whatever the border actually charges in — the Currency field on both the Border Cost Value form and a schedule line is free text (defaults to ZAR, but accepts USD, EUR, anything). Nothing is auto-converted: there's no exchange-rate field anywhere in this flow, because rounding/bank fees mean a clean multiplication wouldn't match what a real currency-conversion app produces.

Instead, once a border cost schedule line is saved, its "Rand" column becomes editable and you type in the actual Rand figure by hand — after running the amount through your usual conversion process, if it wasn't already Rand. If the line's currency is already ZAR, there's nothing to convert — the Rand column pre-fills with the amount automatically.

A schedule can only be loaded into a Cheque Requisition once every line on it has a captured Rand value (all-or-nothing) — the card/list view shows an "N/M captured" count so you can see at a glance what's still outstanding.

Cost Fields (Cost Fields admin screen) are general — they apply to a trip regardless of which border it crosses, e.g. a standing insurance fee. You add them to a trip via "Load standard costs" on the Cheque Requisition, or as part of a Route Template.

Border Cost Types (Border Posts admin screen) belong to one specific border each — e.g. Beitbridge's toll is only ever offered when you're actually working with a Beitbridge crossing. They're not interchangeable with Cost Fields, and they're not picked separately in a Route Template — see the next question.

A named preset (admin screen opened from the Cheque Requisitions toolbar) bundling which border posts and which general Cost Fields a known route always needs — e.g. a "Joburg → Harare" template listing the Beitbridge crossing plus the standing Cost Fields that route always raises. Applying it to a trip adds both in one action instead of reassembling them by hand every time.

It's a shortcut, not a replacement — "+ Add crossing" and "Load standard costs" still work exactly as before for a route with no template yet, a mid-trip reroute, or a one-off extra crossing/fee a template doesn't cover. A template stores only which borders/Cost Fields, never amounts — those always come from the live current rate at the moment you apply it, same as adding them by hand.

Yes. A border's cost types are registered against that specific border, so there's nothing to separately pick in the template — selecting the border is enough. When the template is applied to a trip (or when you add that border crossing by hand via "+ Add crossing"), every active cost type registered for it is added automatically, pre-filled at today's rate.

The confirm dialog before applying a template says exactly how many border cost lines are about to be added, alongside the border crossings and Cost Fields, so nothing lands on the trip as a surprise.

Nothing gets duplicated. Applying skips any border already scheduled on the trip and any Cost Field already on a requisition — safe to run more than once, or to add one extra crossing by hand for a route that doesn't quite match a template.

Inactive or deleted borders/cost fields are never offered — the same rule as everywhere else they're picked. If one used to be on a template but was later deactivated, applying that template simply skips it rather than adding something no longer selectable by hand.

Three states, driven entirely by the Driver despatched/Driver returned dates (Edit trip → Night out allowance):

• Neither date set — the button is hidden entirely. A trip that hasn't left yet has nothing to close.
• Despatched but not yet returned — the button shows, greyed out, disabled. Hover it for a tooltip explaining why: it's waiting on a Driver returned date.
• Returned — the button is active.

Once it's clickable, see the next question for what else can still block actually saving the close-out.

Every line — every border/cheque req cost, and the cash-advance line if the trip has one — needs an Actual amount typed in before the trip can close, even if that amount turns out to be R0 or exactly match what was planned. The field starts blank on purpose: it has to be a deliberate entry against a real receipt, not left as a default that only looks reconciled.

If "Close trip" is blocked, the alert names exactly which line(s) still need an amount.

Cash advance lines get an Actual amount the same as any other cost. Separately, add the driver's cash slips (receipts) — description and amount each. The variance between cash advanced and slips totalled is what matters:

• Within R10 (rounding) — resolved automatically, no action needed.
• Driver owes money — you're asked whether to apply it as a payroll deduction this week.
• Driver fronted their own money — you're asked whether to reimburse via payroll this week.

Either way, accepting writes an adjustment straight into that driver's Night Out & Day Rate Schedule line.

No — there's no receipt photo/attachment feature. The app enforces that every line has been reviewed and a number entered; matching that number against the physical slip is still on whoever's doing the close-out.

Reopen it — button on the closed trip's panel, with a mandatory reason (kept on the trip record, and picked up by the Activity Log). Make your changes and close it again.

These are the three night-out types for a driver's night away — set per night, on the trip or in Daily Detail. Local and Foreign draw the admin-configured Local/Foreign night-out rate. Yard is for a night the driver actually stayed at the yard rather than away — it draws no night-out allowance (normally configured as R0 in Night Out Rates).

No — day rate for a temporary driver is worked out separately from the night-out type, for every day the trip covers. Yard only zeroes the night-out allowance; the day rate is unaffected.

Most likely cause: the driver's entry (from a trip, or Daily Detail) was created before the rate existed, so it's frozen at R0 from that moment. Just add or edit the rate again — Day Rate History and Night Out Rates both automatically sweep and backfill any of that driver's (or, for Night Out, anyone's) entries still sitting at a stale R0, with no need to touch the original trip again.

Other things to check: the driver is actually flagged Temporary in Driver DB (day rate only applies to temporary drivers), and you're looking at the right week — the schedule opens to the current week by default.

Submitting a week locks the due amounts only. Payments are never frozen — they're always read live from the Payments screen, even for an already-submitted week. Add a missed payment any time; date it to fall inside the original week if you want it to show under that week specifically, or today's date if you don't mind it showing under the current week instead. Either way the driver's running balance ends up correct.

Every trip create, edit, void, and close-out — written automatically by the database itself, not by the app remembering to log something, so it can't be bypassed by any login however privileged. Click "Show" on a row to see exactly which fields changed, before → after.

"Sign out" in the top bar. Useful on a shared computer, or to switch which login is being used — the app otherwise stays signed in indefinitely.

A subcontracted trip's paperwork is a different shape — no fuel/odometer fields, just the subcontractor and their quoted rate. At close-out it's one line: planned = the quoted rate, actual = the real gross invoice. Any prepayments or funded costs already raised against it show separately as a reference "amount still owed", never added on top of the gross invoice.

Backup downloads everything in this deployment's database as one file. Restore loads a backup file back in — meant for disaster recovery, not routine use. Both respect the same login restrictions as the rest of the app (hidden entirely for a tyre_only login).