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. This guide is for the dispatcher who plans the deliveries and the installation jobs. 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.

Your delivery day at a glance

Set up drivers, vehicles, delivery regions and return reasons — once (Step 0).
Finalise the sale, then click Send To Queue on its Delivery Details tab: finalising alone puts nothing in the queue (Step 1).
Create the trip, with a vehicle and a driver (Step 2).
Put the jobs on it with Add to Trip, and set the order of the stops (Step 3).
Set the trip to Ready To Ship when the goods are on the loading bay, and confirm installation appointments (Step 4).
The driver runs the trip and records the proof of delivery at each stop (Step 5).
Close the day: Complete Trip for the run, and cancel the job of any stop that failed, from the listing it came from, so its quantity goes back in the queue (Step 6).

The job runs across three pages. This one carries the setup and Step 1; Steps 2 to 4 are on Plan and load the trip, and Steps 5 and 6 on Run and close the trip.

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 delivery stamp the moment the job goes on a trip — usually Fully Delivered, before anything has moved, because the stamp measures how much of the line is planned onto jobs, not how much has arrived (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.

The chain, end to end:

    flowchart LR
  SD["Sales Order, Sales Invoice<br/>or Delivery Order<br/>FINAL"] -->|"Send To Queue"| PP["Pick-pack queue"]
  PP -.->|"sales orders only:<br/>Send To Warehouse Picking Queue"| WMS["Warehouse picking queue"]
  PP -->|"Add to Trip"| J["Jobs on a trip<br/>Delivery Arranged"]
  J -->|"delivery stamp, usually<br/>Fully Delivered, at once"| SD
  J --> RS["Ready To Ship<br/>goods on the loading bay"]
  RS -->|"Start Trip"| OUT["Out For Delivery<br/>driver confirms each stop"]
  OUT -->|"Complete Trip"| DONE["Complete"]
  OUT -.->|"cancel job"| PP

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) — meant to be 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. Today the driver’s phone does not show them. The driver applet looks the list up under a fixed applet identity that is not the one this screen saves under, so its Failure Reason dropdown is empty whatever you configure here. Until that is fixed, tell drivers to type the reason in the Remarks box beside it, using the same short phrases every time, so you can still count them afterwards.

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. The order of work is: fill in the delivery details, finalise, then send. On 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 — once the document is final — 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 unless somebody sends it to the queue again from the order’s Delivery Details — if it is missing from the job listings, that is where it went.

Which document you deliver against is a choice:

Deliver against	When it suits
Sales Order	You want the van scheduled before the invoice is raised — common when the customer pays on delivery, or when you invoice at month end
Sales Invoice	You invoice first and deliver after. The stock has already gone out, so the delivery is pure logistics
Delivery Order	Your 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.

The part of the Delivery Details tab to get right while the document is still a draft is the address block: 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. Then finalise, then Send To Queue, as above.

What success looks like

Five minutes at the end of the day:

Open the trip. Every job reads Complete or Cancelled, and nothing is still Out For Delivery.
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.
Open the sales invoice behind it. Its delivery status reads Fully Delivered — which here means “all of it was planned onto jobs”, and it read the same before the van left. The job’s Complete is the real answer.
Open a cancelled job’s source listing. The quantity is back in the queue, ready to re-schedule.
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.

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

The mistakes that belong to one part are on that part’s page: reading the invoice’s Fully Delivered as delivery progress is on Plan and load the trip; cancelling a trip to fix one bad stop, cancelling a job from the wrong listing, treating a completed job as proof the customer is happy, and assuming a cancelled job stays cancelled are on Run and close the trip.