Planning Delivery Trips
You have a day’s worth of deliveries and a small number of drivers and vans. This page turns the first into a run sheet for the second. Setting up the master data takes an afternoon, once. After that, planning a day takes ten minutes.
Three words, and the whole applet makes sense
- A job is what has to be delivered. One job per source document, one job line per document line.
- A shipment is a physical consignment — useful when the thing being moved does not correspond to a BigLedger document at all.
- A trip is who, when, and in which vehicle. It is the run sheet a driver executes.
Jobs come from the pick-pack queue. A line gets into that queue when somebody opens the finalised Sales Order, Sales Invoice or Delivery Order, goes to its Delivery Details panel and clicks Send To Queue — finalising alone does not do it. Jobs go onto trips. Drivers run trips.
Meet GadgetSphere
GadgetSphere Sdn Bhd runs deliveries out of its Klang Valley fulfilment centre. Thursday has 14 deliveries to make with two vans. We will build the northern run: one trip, one driver, one vehicle, seven jobs.
Before you start — the master data
Delivery and Installation > Delivery Region Listing / Vehicle Listing / Driver Listing
Three lists are worth setting up before you plan anything, and two of them have every field required:
- Vehicles — number, brand, model, engine capacity, vehicle capacity, purchased date and status. All required. Capacity matters because it is copied onto every trip, and a trip cannot be saved without one — so you need at least one vehicle before you can plan at all.
- Delivery regions — region code, name, country, state, a Google location name and URL, and a radius. All required on the region form; the region itself is optional on a trip.
- Drivers — name, identity number, licence number, mobile, joined date, status, and emergency contact details. All required. The e-mail is optional, but it is what links the driver to a BigLedger login: Verify Email matches an existing login, or sends an invitation. A trip can name a third-party driver as free text instead, so an outside courier does not need a driver record.
Do this once, properly. Everything else depends on it.
Step 1: Create the trip
Delivery and Installation > Trip Calendar > + — or Trips > Create
The Trip Calendar is where the applet lands, and it is the better starting point: month, week, day and agenda views, filterable by driver, vehicle or region, so you can see what a driver already has before you add to it.
Fill in:
- Trip Name — what it will be called on the calendar. Thu KV North beats Trip 47.
- Driver Name from the driver list, or Third Party Driver Name as free text for an outside driver.
- Start date and delivery start time, end date and end delivery time. Both dates are required and they are what place the trip on the calendar.
- Delivery Region.
- Vehicle Number, which brings its capacity with it — the one field on this form, other than the name and dates, that the applet insists on.
Save. You now have an empty trip with no delivery status at all — a trip only acquires one when jobs are added to it.
Step 2: Put jobs on the trip
Open the trip > Jobs tab
This is where jobs are created from their sources — Sales Order, Sales Invoice, Delivery Order or Shipment. Alternatively, work from the other direction: the Delivery Job listing shows every job regardless of source, and Add to Trip attaches selected jobs to a trip.
If a document you expect is not offered, nobody sent its lines to the queue. Go back to the document’s Delivery Details panel and click Send To Queue; it needs to be FINAL first.
Adding a job to a trip is the moment the delivery status begins. It sets the trip, the jobs and their document links to Delivery Arranged and writes a job event. Nothing before that point has a delivery status.
It also stamps the source document — and here is the part that confuses sales desks. The source order or invoice does not get “Delivery Arranged”. It gets Partially Delivered, the moment the job is added to a trip, before anything leaves the building — and in the current build it keeps saying Partially Delivered after the trip completes too. The rule behind it checks whether the line still has a pick-pack queue row, and queue rows are never removed; their balance just reaches zero. (Fully Delivered is written only when no queue row exists, which for a job built from a document does not happen.) So read the order’s delivery status as “planned onto a job”, not as delivery progress; the job and trip statuses are the ones that mean something. Tell your sales team once and they will stop ringing the warehouse.
The Job Sales Order, Job Sales Invoice and Job Delivery Order listings are the same jobs grouped by where they came from, with the same functions — useful when you want to plan everything sitting behind sales orders and nothing else.
Step 3: Sequence the run
Trip > Jobs tab — drag the rows
Drag the jobs into the order the driver will do them. This writes the sequence and nothing else: no status changes, no events. Order them the way you would drive them — nearest first, time-committed deliveries where they have to be, and the last stop on the way back.
Bulk tools on the Delivery Job listing help here: Bulk Date Edit sets arrival and departure dates across many jobs, Bulk Remarks writes the same note to many, and Add Logistic Hub routes jobs through a transfer point.
Step 4: Run the day
The statuses go Delivery Arranged → Ready To Ship → Out For Delivery → Complete, and each can be set on a single job or on the whole trip:
- Ready To Ship — loaded and ready.
- Start Trip — sets every job on the trip to Out For Delivery in one action.
- Complete Trip — sets every job to Complete, and re-stamps the source documents and shipments (which, for document-sourced jobs, leaves them reading Partially Delivered — see Step 2).
Each status change can be back-dated with the Trip Status Date, which is what you use when you are catching up at 6pm on a trip that finished at two.
Step 5: When a delivery does not happen
Cancel a job from the listing that matches its source — Job Sales Order, Job Sales Invoice or Job Delivery Order. This is important and easy to get right once you know it: cancelling puts the quantity back into the pick-pack queue, so the document can be planned onto another day’s trip. A shipment-sourced job is cancelled from the Delivery Job listing instead, which returns the quantity to the shipment’s balance.
Cancel a trip and every job on it is cancelled the same way, with all the queue quantities restored.
Re-arrange a trip when the run is being rebuilt rather than abandoned — it moves the trip and its jobs to a re-arranged state without releasing anything.
There is no “void” here. A job is cancelled, or removed from the trip’s Jobs tab.
One quirk to know: a job cancelled with Cancel Job can still be marked Complete afterwards, because the two actions spell the cancelled status differently and the guard only recognises one spelling. A job cancelled through Cancel Trip is properly blocked. Treat the job’s event history, not its last status, as the record of what happened.
Step 6: Check the day afterwards
The Delivery Job Line Report gives you item-level detail for a date range: item, quantity, trip, vehicle, driver, job, start and end of delivery, source document and customer, printable with your company’s format. It is the report to run at the end of the week.
What success looks like
Two minutes after you finish planning Thursday:
- Open the Trip Calendar on Thursday. The trip is there, against the right driver and vehicle, in the right time window.
- Open the trip’s Jobs tab. All seven jobs are on it, in the order you want them driven, and the trip’s status reads Delivery Arranged.
- Open one of the source sales orders. Its delivery status now reads Partially Delivered — which means “planned onto a job”, and is what the sales desk sees without calling you.
Common mistakes
| What goes wrong | What you see | The fix |
|---|---|---|
| Lines never sent to the queue | The document is FINAL but cannot be turned into a job | Open its Delivery Details panel and click Send To Queue |
| A trip with no jobs | It has no delivery status at all | The status begins when jobs are added; an empty trip is just a calendar entry |
| Reading the order’s Partially Delivered as delivery progress | Sales expects the rest to be on its way; nothing is outstanding | The order’s status means “on a job” and does not change after completion. The job and trip statuses are the ones that mean delivery |
| Cancelling a job the wrong way | SHIPMENT LINK TABLE NOT FOUND | Document-sourced jobs are cancelled from their own Job Sales Order / Invoice / Delivery Order listing; shipment-sourced ones from the Delivery Job listing |
| Deleting a job instead of cancelling it | The quantity never returns to the pick-pack queue and the document cannot be re-planned | Use Cancel Job |
| Completing a trip that was cancelled | Refused, with a message naming the trip | A cancelled trip cannot be completed — re-arrange instead of cancelling if the run is only being rebuilt |
| Skipping the intermediate statuses | Reports show deliveries that were never out for delivery | Nothing enforces the order; set Ready To Ship and Start Trip as you go |
| No vehicle set up | The trip will not save — Vehicle Capacity is required | Create the vehicle first; driver and region can follow |
| Expecting this applet to move stock or post | Nothing appears in the ledger | It never does. The sales invoice is what posts |