Skip to content
Installation Scheduling Workflow

Installation Scheduling Workflow

You have sold an air-conditioning unit that somebody has to carry up three floors, mount on a wall and switch on. By the end of this guide you will have turned that sale into a scheduled job, put it on a van with a driver and a mate, and followed it to a signature at the customer’s door. Planning a day’s deliveries takes about fifteen minutes once the master data is in place; the first-time setup of drivers, vehicles and regions takes an hour.

What BigLedger gives you, stated plainly

Be clear about this before you plan anything around it, because it is less than the name suggests and more than enough.

BigLedger’s delivery module has four objects: Jobs (what has to be delivered), Trips (who, when, which vehicle), Drivers and Vehicles, with Delivery Regions and Logistic Hubs to group and route them. A job moves through five statuses — Delivery Arranged → Ready To Ship → Out For Delivery → Complete, or Cancelled — and every change is written as a job event. The sales document behind the job gets a single stamp, Partially Delivered, the moment the job goes on a trip (more on that in Step 3); the job and trip statuses are where progress actually shows.

What it does not have: site surveys, installation checklists, technician skills or certifications, equipment lists, a separate installation appointment, testing-and-handover records, or post-installation follow-up. The applet is called Delivery Installation because installation crews use it the same way delivery crews do — a job is a job. If your installation needs a survey first, that survey is a phone call and a note in the job remarks, not a document type.

Nothing here posts to the ledger or moves stock. Trips, jobs and delivery statuses are operational records. The stock left when the Sales Invoice or cash bill was finalised. Completing a job does not change a balance anywhere in accounting.

Meet GadgetSphere

GadgetSphere Sdn Bhd sells large-format displays and air conditioning alongside the small electronics, so a proportion of GS-KV-01’s sales need two people and a van. Today’s van has three stops: a 75-inch display at RM 9,800 for a corporate office that needs wall-mounting, a split-unit air conditioner at RM 3,200 for a residential customer, and a straightforward drop of six laptops at RM 4,200 each to a reseller. All three sales are already finalised.

Step 0: Set up the master data — once

Delivery Installation > Driver Listing, Vehicle Listing, Delivery Region Listing

You do this once, not every day.

  • Drivers. A driver record is a record in the delivery module, not an employee record. If the driver will use the phone applet, their record needs an e-mail that matches a BigLedger login — use Verify Email, or Send Invite if they have not registered yet.
  • Vehicles. Code, name and capacity. Capacity matters if you plan by volume.
  • Delivery regions. Klang Valley north, Klang Valley south, and so on. Regions are how the trip calendar becomes readable when you run more than two vans.
  • Return reasons (Settings → Return Reasons) — the failure reasons a driver picks from when a stop does not go to plan: Customer not home, Access refused, Goods damaged in transit, Wrong address. Without these the driver has a free-text box and you have no data.
Return Reasons can only be added to a configuration row that already exists. If the screen errors when you try to save your first reason, the row has not been seeded for your tenant — ask BigLedger support to seed it rather than retrying. This catches every new tenant once.

Step 1: Finalise the sale first

Sales > Sales Order (Internal), or Finance > Sales Invoice (Internal)

The outcome: lines waiting in the pick-pack queue.

A document becomes deliverable when somebody sends its lines to the queue — finalising alone does not do it. Open the document’s Delivery Details tab, switch Require Delivery on for the lines going out, check Qty To Deliver (it defaults to the line quantity), and click Send To Queue. That button writes the pick-pack queue; a FINAL invoice nobody has sent is as invisible to the job listings as a draft. Click it once — a second send after a page reload adds to the queued quantity rather than replacing it. The Sales Order applet refuses to send a draft; the Sales Invoice and Delivery Order applets do not check, so finalise first as a matter of habit.

From the pick-pack queue a line has two exits. The one this guide follows is Create Delivery Job: the delivery module reads the queue in its Job Sales Order / Job Sales Invoice / Job Delivery Order screens, and the same button also sits on the source applet’s own Pick Pack Queue screen.

The other exit is the warehouse picking queue: a branch that runs the Warehouse Management applet clicks Send To Warehouse Picking Queue on the Sales Order applet’s Pick Pack Queue screen (sales orders only). A line sent that way leaves the pick-pack queue and cannot become a job — if it is missing from the job listings, that is where it went.

Which document you deliver against is a choice:

Deliver againstWhen it suits
Sales OrderYou want the van scheduled before the invoice is raised — common when the customer pays on delivery, or when you invoice at month end
Sales InvoiceYou invoice first and deliver after. The stock has already gone out, so the delivery is pure logistics
Delivery OrderYour process uses a separate dispatch document

GadgetSphere invoices its corporate customers first and delivers after, so all three of today’s stops come from sales invoices.

Fill in the Delivery Details tab on the source document before you finalise: delivery branch and location, the requested date, and the contact at the far end. That is what the driver’s screen will show, and a wrong phone number there is a failed delivery.

Step 2: Create the trip

Delivery Installation > Trips > Create, or the + on the Trip Calendar

The outcome: a run sheet with a date, a driver and a van.

Give the trip a name your team will recognise — KV01-2026-09-16-AM rather than Trip 47. Set the date and duration and pick the vehicle — the one thing the form insists on, because it brings the vehicle’s capacity with it. Pick the driver (or type a third-party driver’s name if you are subcontracting) and the delivery region too; both are optional on the form, but a trip with no driver is a run sheet nobody will see on their phone.

Nothing is scheduled yet. A trip with no jobs on it has no delivery status at all.

Step 3: Put the jobs on it

Delivery Installation > Job Sales Invoice (or Job Sales Order / Job Delivery Order) > select > Add to Trip

The outcome: three stops on today’s van, and three sales documents that now know they are being delivered.

Open the listing that matches where your work came from — Job Sales Invoice for today’s three. The screen reads the pick-pack queue, so each invoice whose lines were sent to the queue appears with its queued quantity. If one you expect is missing, nobody clicked Send To Queue on it — go back to Step 1. Select the three and click Add to Trip.

This one click does more than it looks like:

  • it creates a job per source document, with a job line per document line;
  • it links the jobs to the trip;
  • it sets the trip, the jobs and their document links to Delivery Arranged;
  • it writes a job event against each one;
  • it stamps the source invoice’s delivery status.

Add to Trip is the only place the initial status comes from. A job that exists but has never been added to a trip is not scheduled, whatever else it looks like.

That last stamp is the one that confuses sales desks, so tell them once. The invoice does not get Delivery Arranged — it gets Partially Delivered, from the moment the job is on a trip, before anything has left the building. And it keeps saying Partially Delivered after the trip completes, because 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 row exists, which for a job built from a document does not happen.) Read the invoice’s delivery status as “planned onto a job”, not as progress; the job and trip statuses are the ones that mean something.

On the trip’s Jobs tab, drag the stops into the order the driver will drive them. The sequence is saved against the trip; it writes no event, so reordering is free.

Delivering something that never had a sales document? Use a Shipment. Key it in or import it from a file, then Create Jobs on the shipment listing. Shipments cover goods pushed in by an external warehouse or a third-party logistics feed, and they behave like source documents everywhere downstream.

Step 4: Ready to ship

Delivery Installation > Trips > (your trip) > Ready To Ship

The outcome: dispatch knows this van is loaded.

Set the trip — or individual jobs — to Ready To Ship when the goods are picked and on the loading bay. The status writes through to the jobs, their document links and their shipment links, with a job event each. It is the job and trip status the sales team should look at to answer “has it left?” — the invoice’s own delivery status stays at Partially Delivered whatever happens on the van.

For the display and the air conditioner, this is also when you confirm the appointment. Neither will fit through a door unannounced. Put the confirmed time slot in the job’s remarks; it is what the driver reads on their phone.

Step 5: The driver runs the trip

Delivery And Installation Driver (on the driver’s phone)

The outcome: three signatures and a photo of each installed unit.

Set the trip to Start Trip when the van leaves — this applies Out For Delivery to every job on it in one action.

The driver opens the Delivery And Installation Driver applet and sees only their own trips, on a calendar. Tapping a trip shows the stops in the order you set. Each job card has the address as a map link and the contact as a tap-to-call number.

At each stop the driver taps Start Job, does the work, then Confirm Delivery and fills in the proof of delivery: quantity delivered per item, the recipient’s name and IC number, a signature on the screen, photographs, remarks, and any cash collected. Short or refused items get a Failure Reason from the list you configured in Step 0.

What the driver cannot do, deliberately: start or complete a trip, set a custom status, back-date an event, or see any job that is not on one of their trips. All of that stays with you.

Step 6: Close the day

Delivery Installation > Trips > (your trip) > Complete Trip

The outcome: every sales document marked as delivered, and a record of what did not go to plan.

Complete Trip sets every job on it to Complete, writes the completion event on each, and re-stamps the source documents and shipments — which, for a job built from an invoice or an order, leaves the document reading Partially Delivered (Step 3). The trip and the jobs are the record of completion; the Delivery Job Line Report is the day’s proof.

When a stop fails — nobody home, access refused — cancel that job from the listing it came from. Cancelling puts the quantity back into the pick-pack queue, which is exactly what you want: the invoice becomes deliverable again and you can put it on tomorrow’s trip.

Cancel Trip cancels every job on it. If you are calling a trip off but three of its five stops are going out on another van, move those jobs to the other trip first, then cancel. There is no undo, and re-creating jobs means going back to the source listings.

Cancel a job from the Job Sales Order / Job Sales Invoice / Job Delivery Order listing it belongs to. The Cancel Job button on the combined Delivery Job listing only handles shipment-sourced jobs and will refuse a document-sourced one with SHIPMENT LINK TABLE NOT FOUND.

What success looks like

Five minutes at the end of the day:

  1. Open the trip. Every job reads Complete or Cancelled, and nothing is still Out For Delivery.
  2. Open one completed job’s Job Event tab. Arranged, ready, out, complete — with times. This is the record that answers a customer disputing a delivery date.
  3. Open the sales invoice behind it. Its delivery status reads Partially Delivered — which here means “was planned onto a job” and is the most it will ever say. The job’s Complete is the real answer.
  4. Open a cancelled job’s source listing. The quantity is back in the queue, ready to re-schedule.
  5. Run the Delivery Job Line Report for today. Item, quantity, trip, vehicle, driver, source document — one line per thing delivered. That is the day’s proof.

Common mistakes

Expecting the delivery to move your stock. It does not, and neither does completing a job. Stock left on the invoice or the cash bill.

Finalising and waiting for the invoice to appear in the job listing. It never will on its own. Nothing has queue rows until someone clicks Send To Queue on the document’s Delivery Details tab. If the invoice you want is missing from the list, that is the first thing to check — and if its quantity is doubled, somebody clicked the button twice.

Reading the invoice’s Partially Delivered as delivery progress. It means the lines are on a job, and it does not change after the trip completes. Sales staff who take it literally will chase dispatch for a second drop that does not exist. The job and trip statuses are the truth.

Cancelling a trip to fix one bad stop. Every job on it goes. Move the good ones first.

Cancelling a job from the wrong listing. Document-sourced jobs are cancelled from their own listing. The error message is not obvious about why.

Leaving the delivery contact blank on the sales document. The driver’s screen shows what the document carried. No number, no delivery.

Treating a completed job as proof the customer is happy. BigLedger records that goods arrived and were signed for. Whether the air conditioner actually works is between your installer and the customer, and if you need that recorded, it belongs in the job remarks or the photographs — there is no commissioning record to fill in.

Assuming a cancelled job cannot be completed. In current builds a job cancelled with Cancel Job can still be completed afterwards, because the guard compares against a different spelling of the status than the button writes. Treat the job event history as the true record, and do not rely on the guard.

Related documentation

Last updated on