Delivery Installation applet

Turn what is due for delivery into driver jobs and trips. Lines from sales orders, invoices and delivery orders reach this desk only when someone presses Send To Queue on the document; finalising the document creates no queue row by itself, and a shipment keyed in or imported can stand in for a document. Drivers do not work here; they update the same jobs from the Driver applet. And a line reads Fully Delivered once all of it is on jobs and those jobs are put on a trip, before anything has actually arrived.

Your job, and the screen for it

Overview

The Delivery Installation applet is the back-office dispatch console of BigLedger’s delivery module. It takes the lines that are due for delivery from Sales Orders, Sales Invoices and Delivery Orders (through the pick-pack queue — rows that a user sends from the document’s Delivery Details panel with Send To Queue; FINAL alone creates none), or from Shipments that were keyed in or imported from a file, and turns them into delivery Jobs with Create Delivery Job. The same button, doing the same thing, also sits on the Pick Pack Queue screens of the Sales Order, Sales Invoice and Delivery Order applets, so a job can be created without opening this applet. A pick-pack row that was instead sent on to the warehouse picking queue (Send To Warehouse Picking Queue, Sales Order applet → Warehouse Management applet) is deleted from the pick-pack queue and never reaches this applet. A dispatcher groups Jobs onto a Trip with a driver, a vehicle and a delivery region, then follows the trip through Delivery Arranged → Ready To Ship → Out For Delivery → Complete (or Cancelled). Every status change is written as a job event. The source document’s delivery-tracking status is also rewritten at every step, but what it shows is coarser than progress: from Add to Trip a document-sourced line reads Fully Delivered once none of it is left in the pick-pack queue (Partially while some is), and completing the job does not change it (see Lifecycle and effects).

Drivers do not work in this applet: they update their jobs in the Delivery And Installation Driver applet (and its mobile build), which drives the same job and trip status changes from the driver’s side.

Where it fits

Screens and menus

Left menu (in the order the applet shows them):

Configuration

Before you can use it

• Source documents sent to the queue. The Job Sales Order / Job Sales Invoice / Job Delivery Order screens read the pick-pack queue, so a Sales Order, Sales Invoice or Delivery Order must have had its lines sent with Send To Queue (Delivery Details panel; lines with Require Delivery = YES and a Qty To Deliver) before it can become a job — and not yet sent on to the warehouse picking queue (Send To Warehouse Picking Queue on the Sales Order applet’s Pick Pack Queue screen), which removes the row.

  FINAL on its own creates no queue row. Cancelling a document-sourced job adds the line quantity back to that queue; cancelling a shipment-sourced job adds it back to the shipment’s open balance.

• Branch and location in Organisation: shipments carry from/to branch and location, and jobs and trips are searched by them.

• Drivers, vehicles and delivery regions in this applet’s own listings — a trip needs a driver (or a free-text third-party driver name), a vehicle and its capacity. Drivers who will use the driver applet need an e-mail that matches an existing login (Verify Email) or an invitation sent from the driver record.

• Return reasons are stored in one configuration record for the applet. The Return Reasons Settings screen appends to that record; it does not create it. If it does not exist for your tenant, the screen cannot save (see Troubleshooting).

• Printable formats are Jasper JRXML files uploaded under Printable Format Settings; the upload looks up the printable format list with code Jasper JRXML, which must exist.

• Server-side permissions. Creating, reading and updating jobs, trips, drivers, vehicles and regions is gated by the API_TNT_DM_DEL_* permission families (JOBS, TRIP, DRIVER, VEHICLE, DELIVERY_REGION, JOB_ATTACHMENT, JOB_CHECKLIST_LINE, DRIVER_VEHICLE_LINK, DRIVER_REGION_LINK, …), assigned through the Permission Set / User Permission / Role Permission screens under Settings. Start, complete, ready to ship, the trip actions (complete, cancel, start, re-arrange) and custom status require API_TNT_DM_DEL_JOBS_UPDATE or an admin permission.

  Two job actions check a different set: Cancel Job on the Job Sales Order / Job Sales Invoice / Job Delivery Order listings and Create Delivery Job from a document’s pick-pack queue accept the jobs owner, admin or create permission instead. So a dispatcher who can create jobs can also cancel them from the document listings even without the update permission — grant create with that in mind.

Applet settings

Settings live in applet-local screens (there is no shared field-configuration section for this applet and no inline gear). The Application Settings and Menu Containers screens save as the applet’s tenant-wide master settings; nothing here is per-branch or per-user. Every toggle starts with no value, so the default for every key is off: nothing hidden, every status button shown. The settings are grouped below by the screen and tab that hold them, in the order the screens list them.

Application Settings — Trips tab

Application Settings — Shipment tab

Fifteen HIDE_* toggles, each named after a column of the Shipment listing, all default off, tenant-wide. Most of them hide a different column from the one they name.

The toggles pick a column by its position in the grid, and the grid has since gained Arrival, Departure and Remarks columns, so only the first six — Shipment No, Date, From Location, Sender, Sender Address, Logistics Ref No — hide what their label says. From there on each one lands earlier in the grid: HIDE_TRACKING_ID hides Arrival, HIDE_RECIPIENT hides Departure, HIDE_RECIPIENT_ADDRESS hides Tracking ID, HIDE_QTY hides Remarks, HIDE_BAL_QTY hides Recipient, HIDE_ALLOCATE_JOB_QTY hides Recipient Address, HIDE_AVE_UNIT_CBM hides Qty, HIDE_CBM hides Bal Qty, and HIDE_PROCESS_STATUS hides Allocate Job Qty. No toggle hides Ave Unit CBM, CBM or Process Status.

The row that matters is the Bal Qty one: Bal Qty is the number that decides whether Create Jobs does anything at all (see What the Shipment listing will not show you below), and it is hidden by HIDE_CBM, not by HIDE_BAL_QTY. If Bal Qty is missing, look at HIDE_CBM first. A user’s own saved column layout is re-applied a moment after the listing opens and wins over all of these toggles. The Enable checkbox and the Process Status – Process Name Select dropdown above the toggles save nothing.

Application Settings — Jobs tab

• Hiding the job statuses tidies the listings; it does not stop a job being completed. The setting does not reach the other two places a job can be completed: the job editor on a trip’s Jobs tab always offers all four actions, and the Trips listing always offers Complete Trip, which completes every job on the trip. So it does not by itself stop the back office completing a job the driver has not done — that still rests on who is given this applet.
• The Delivery Job column toggles mostly hide some other column. As on the Shipment tab, the toggles pick columns by position and the grid has gained columns since, so apart from JS_HIDE_JOB_ID and JS_HIDE_JOB_TYPE the other seventeen each hide some other column — JS_HIDE_START_DATE hides Shipment ID, JS_HIDE_TRIP hides Departure, JS_HIDE_JOB_PROCESS_RESOLUTION hides Delivery Status. Trip, Vehicle, Driver and Qty are hidden only by other keys (JS_HIDE_JOB_SENDER_ADDRESS, JS_HIDE_JOB_LOGISTICS_REF_NO, JS_HIDE_JOB_TRACKING_ID, JS_HIDE_JOB_CBM), and CBM, Custom Status and Process Resolution by none. Switch one on, then look at the listing to see which column went. A user’s own saved column layout is re-applied after the listing loads and overrides all of them.

Menu Containers

Despite its name this screen does not configure the left menu. It holds the Advance Search field toggles for two listings; the Advance Search tab of Application Settings that used to hold them has been retired.

Twenty-four keys, all default off: the same twelve advanced-search fields — Delivery Region, Supplier, Customer, Vehicle, Trip, Branch, Branch From, Branch To, Location, Location From, Location To and Company — with a JS_ prefix for the Delivery Job listing and an SO_ prefix for the Job Sales Order listing. Only those two listings honour them: the Job Sales Invoice and Job Delivery Order searches ignore both prefixes and always show every field. That is the trap here — a search field you have switched off on two screens is still there on the other two, and there is no key that would switch it off.

Other settings screens

Keys read at runtime without a control

• ENABLE_CUSTOM_STATUS_LINE_1 … _5 and NAME_CUSTOM_STATUS_LINE_1 … _5: the job-item grids on the trip’s Jobs tab (Sales Order, Sales Invoice, Delivery Order sources) and the Job Sales Invoice listing build an extra column from them, but every one of those grids is drawn from its fixed column list, so no column is ever added, whatever the keys hold. No settings screen writes these keys either.
• DEFAULT_VEHICLE is not a setting: it is the name under which the driver form stores a driver’s default vehicle.

On the screen and doing nothing

Switching these changes nothing, and knowing that is the whole answer — the alternative is a dispatcher toggling them and concluding the screen is broken.

The Sub Process Status row above corrects what this page said until 2026-09-18 — that the key was “still declared and read”. It is not read.

Document behaviour settings

• Status flow is fixed in the backend (see Lifecycle); the applet only decides which buttons are visible (*_HIDE_JOB_STATUS, HIDE_BATCH_PRINT).
• Event time. Job status buttons stamp the event with the current time formatted dd MMM, HH:mm. Trip status buttons and Custom Status let the dispatcher enter a Trip Status Date / custom date instead, so a completion reported late can be back-dated. The stored description has no year.
• Printables. Trip Report and Batch Print on Trips; Batch Print (optionally with a custom delivery date) on Delivery Job; Generate Delivery Job Line Report on the report screen. All need a printable format of the matching document type.
• No e-Invoice, workflow or approval toggles exist in this applet.

Who can change what

• Client-side permissions: none are defined for this applet, and the applet’s own code checks none; hiding is done only through the master settings above.
• Server-side permissions: the API_TNT_DM_DEL_* families listed under Before you can use it. The Feature Visibility, Webhook and permission screens under Settings are the shared components every applet carries.

Fields

The forms are ordinary and you are looking at them, so this section names every field once and then tables only the ones that behave in a way the screen cannot show.

Trip — Create / Details tab. Trip Name; Driver Name, or instead of it Third Party Driver Name; Start Date with Delivery Start Time and End Date with End Delivery Time; Delivery Region; Vehicle Number and Vehicle Capacity. The Details tab adds read-only Delivery Status, Process Status and the created/modified stamps. Trip Name, both dates and Vehicle Capacity are required; everything else is not. Vehicle Capacity is read-only and filled only by picking a vehicle, so the vehicle is required in practice even though its own field has no required mark.

Shipment — Main tab. Shipment No, Tracking ID, Logistics Ref No; Shipment Delivery Date; Item Name, Item description, Item Type, Qty, Weight, CBM; From and To Branch, From and To Location; External Running No. and Additional Remarks, both of which are copied onto jobs created from the shipment. The Recipient and Sender tabs each pick an entity and one of its addresses. Nothing on this form is mandatory — including Qty, which has a consequence of its own (below).

Delivery Job — Details tab (Edit Job Shipment). Job Id, system-generated and read-only; Delivery Region, Job Type, Status; Arrival Date, Departure Date, Start Date, End Date, Duration (in minutes) — Arrival and Departure can also be set for many jobs at once with Bulk Date Edit; Ext Amount Fee and Ext Shipment Weight / Height / Length / Width, each hideable by its JS_FORM_HIDE_EXT_* setting; External Running No., Additional Remarks and Remarks, the last of which Bulk Remarks writes for many jobs at once.

Job line (Job Items tab). Recipient Name, Recipient IC, Recipient Contact, Remarks and Reason for Return (offered from the Return Reasons list), plus signature and photo attachments — the same fields the driver fills in on the driver applet.

Driver. Driver Name, Identity Number, License Number, Mobile, Joined Date, Status (ACTIVE by default, or INACTIVE), Emergency Name, Emergency Mobile and Relationship are all required. Email, and the Address 1–5 / City / Postal Code / State / Country block, are not.

Vehicle, Delivery Region, Logistic Hub and the settings forms. Vehicle: Vehicle Number, Vehicle Brand, Vehicle Model, Engine Capacity, Vehicle Capacity, Purchased Date, Status — all required. Delivery Region: Region Code, Delivery Region, Country, State, Google Location Name, Google Location URL, Radius — all required. Logistic Hub: Code and Name required, Phone, Status and Description optional, plus an Address tab; hubs are linked from and to each other on the edit screen. Custom Status: Code, Name and Description required, image optional. Return Reason: Reason Code and Reason Name. Printable Format: Format Code, Format Name and one uploaded file.

The fields that behave

Lifecycle and effects

This applet posts nothing to the General Ledger and moves no stock: there is no journal posting and no stock movement for trips or jobs. Its effects are delivery statuses, job events and pick-pack-queue balances.

Which queue am I looking at?

Four different queues in BigLedger are called “the queue”, and this applet touches three of them. The complete index — what each one is, who writes it and where you see it — is on the Warehouse Management applet page and is not repeated here. What that index leaves to this page is the delivery module’s own two:

• The shipment open balance holds the balance of a shipment — how much of it has not yet been turned into jobs. It is created when the shipment is created, reduced by Create Jobs, and increased again when a shipment-sourced job is cancelled.
• The delivery jobs themselves, which are their own queue.

The one to keep straight is the finance-side pick-pack queue, which is not this applet’s and which this applet nevertheless writes to: creating a document-sourced job consumes from it, and cancelling one puts the quantity back.

What a job save actually writes

Nothing about this is on the screen, and it is the difference between a delivery record you can defend and one you cannot.

There is no partial update. Saving a job sends the whole job record back, and the backend replaces every field from what it receives — a field absent from the request becomes empty, not “leave it alone”. The applet is therefore expected to send back the record it loaded, and it does: Save re-fetches the job and overlays the form on top of it.

The overlay is written for a form that only one of the two job editors actually has. There are two places to edit a job — Delivery Job listing → open a job (Edit Job Shipment) and Trips → open a trip → Jobs tab → open a job — and they carry different fields. The shared overlay assigns from both sets, so each editor blanks the fields only the other one has:

Two more things every job save does, from either editor:

• The job’s external-delivery record is overwritten with just the signature, taken from a signature control that is blank unless you re-drew the signature in that session. That record is where the delivery module’s third-party carrier integrations park their last response — consignment creation and cancellation, airway-bill tracking, last shipment status — so a back-office edit discards the carrier’s reply. The carrier consignment number and carrier status beside it are not touched and survive, which is why the loss is easy to miss.
• Every job extension’s created date is reset to now. A job extension’s Created Date is the date of the last save, not the date it was created.

Proof of delivery: where it lives, who can see it, what destroys it

The driver applet and the driver mobile app capture proof of receipt — recipient name, identity number, phone, remarks, a signature, and the cash collected — and write it onto the job. Two consequences a dispatcher will not guess:

• In the back office it is visible in exactly one place — open a trip, Jobs tab, open the job. It is on no listing, no report column and no batch function; the Delivery Job listing’s own edit form does not show it and wipes it on Save, as above.
• Cash collected on delivery never appears in the back office at all. The collected amount is written by the driver and is available through the jobs API and to a Jasper printable — but no screen in this applet shows it. If you take cash on delivery, the reconciliation has to come out of the API or a printable, not out of a screen.

What the Shipment listing will not show you

The Shipment listing is not a listing of shipments. It fetches a page from the API and then, in the browser, drops every row whose Qty is null or zero and every row whose Bal Qty is zero. So:

• A shipment that has been fully turned into jobs disappears from the screen. It is not archived and not filtered by a control you can clear; it is simply not rendered. The job it produced is the only trace left in the UI.
• A shipment imported or pushed in with no quantity never appears at all, which is the quiet answer to “the import said success and I cannot find it”.
• Bal Qty is not the shipment’s quantity. It is read from the shipment’s open balance and shows 0 if that balance record is missing; Allocate Job Qty starts equal to it and is capped at it when edited. Qty on the shipment record is what you keyed and never changes.
• The grid is told that the whole result set is only as long as the rows that survived the filter on the block it just fetched, so the listing does not page past the first block and the row count it reports is that block’s survivors.

Create Jobs, and what Path Optimization Mode does differently

Create Jobs on the Shipment listing fires one request per selected shipment, and only for rows whose Bal Qty is greater than zero; a row at zero is skipped in the browser with no message at all. That is the whole of “Create Jobs did nothing”.

Normal Mode creates one job per shipment and subtracts the allocated quantity from the open balance once, refusing with NEGATIVE BALANCE QUANTITY if that would go below zero.

Path Optimization Mode is a different shape of thing and the screen gives no hint of it. Given a logistic-hub network, the backend resolves a route and then creates one job per leg — origin to the first hub, a job for every hub-to-hub transit, and the last hub to the destination. Each leg carries the same quantity. Two things follow that are worth knowing before you use it:

• The open balance is reduced once per leg, not once per shipment, while the guard that would catch a negative balance is applied once, against the original balance. A three-leg route therefore takes three times the allocated quantity out of the shipment’s balance, and the guard cannot see it.
• Through the API the request accepts a list of shipments but persists only the first. The applet never sends more than one, so this reaches you only through the API.

The tracking lookup is not public

The shipment tracking lookup (look up shipment headers by tracking ID) is not open to the internet, despite being named as a public lookup: it requires a valid BigLedger login for the tenant, exactly like every other shipment request. You cannot hand this URL to your customers as a parcel-tracking page, and a page that says you can — as this one did until 2026-09-18 — sends an integrator down a dead end.

Delivery statuses: DELIVERY_ARRANGED, READY_TO_SHIP, OUT_FOR_DELIVERY, COMPLETE, CANCELLED, plus DELIVERY_REARRANGED / JOB_RE_ARRANGED for the re-arrange actions and the roll-up values PARTIALLY DELIVERED / FULLY DELIVERED that are written only to source documents and shipment headers.

Two things the product does not do: no action validates the order of transitions (a job can go from DELIVERY_ARRANGED straight to COMPLETE), and the cancelled-job guard looks for the upper-case CANCELLED while Cancel Job stores the title-case Cancelled, so only jobs cancelled through Cancel Trip (which writes CANCELLED) are actually blocked from completion. There is no VOID: a job is cancelled from its listing, deleted from the trip’s Jobs tab, or (shipment-sourced) removed by Cancel Job on the Delivery Job listing.

The delivery screens side by side

Several screens across BigLedger touch a delivery; this applet is one of them. The stock and the journal come from the sales invoice, whichever of these you use: its FINAL queues a primary job processor that fans out to the stock, journal and e-invoice jobs (what each sales document writes). A delivery document carries a quantity sign of zero, fixed by the server on every line, so its FINAL writes nothing to stock. A job and a trip are not documents at all: they have no finalise and no processor takes them.

There is no installer’s screen, and the customer’s screen is a storefront widget or nothing. An installation crew runs the same job as a delivery crew — the applet keeps no survey, checklist, technician or handover record (Installation Scheduling Workflow), and its one installation field, Installation Duration (minutes) on a job line, is a column on the trip’s job-items listing that no form in either applet fills in. A CP Commerce storefront can carry a goods tracker widget: the customer types a tracking number and sees the shipment’s jobs and their statuses as a timeline. It looks the number up as a job’s own tracking id or sender reference, and as the tracking id or sender reference of the shipment a job came from, so it answers only for a job that carries the number you gave the customer; the storefront calls BigLedger with its own tenant credentials. Both tracking lookups need a tenant login, exactly like every other shipment call, so outside that widget there is no URL you can hand to a customer: whoever answers the phone reads the job’s status and events.

Choosing a delivery screen

The path the guides teach — order, Send To Queue, job, trip, driver — is the right one for a branch with a dispatch desk, and it costs a driver record, a vehicle and a Send To Queue per document. Before you build a day around it, check whether the branch needs more than the invoice and the Delivery Details panel.

The delivery figures, and what makes each

A Saturday at GS-KV-01

Three stops like those in Delivery Trips: Run the Trip, Record the Proof and Close the Day, which walks a trip end to end: a 75-inch display that needs wall-mounting, a split-unit air conditioner and six laptops for a school office, all on invoices finalised on Thursday, so the stock left GS-KV-01’s location and the sale reached the ledger then. Seen from this applet, three things in that Saturday surprise a dispatcher.

Once Friday’s jobs are added to Saturday’s trip, all three invoices read Fully Delivered, and the van is still in the yard (The delivery figures, and what makes each). At the second stop the customer is out. The driver cancels the job: the air conditioner’s quantity goes back to the pick-pack queue, the invoice line no longer reads Fully Delivered, and Monday’s trip picks it up with no change to the invoice, the stock or the ledger. And the cashier counts the RM 450 the laptop customer paid the driver in cash against a printable format or the jobs API, because it is written on the job (What the delivery screens will not do).

Checking that a delivery arrived

Open Delivery Installation › Trips › the trip › Jobs tab › the job. Its status reads Complete, the Job Event tab lists each status change with its time, and the Job Items tab carries the recipient’s name and IC number the driver keyed. That is thirty seconds, and it is the only screen in the back office that shows the proof. Do not read the invoice’s Delivery Status for it. For the stock, the check is the invoice’s, not the job’s: how you know a document moved stock.

What the delivery screens will not do, and who does it instead

• Move stock or post a journal. The invoice does both; the accountant lists delivery orders dated in the period with no invoice before the close (what the sales documents will not do).
• Stop an overloaded van. Vehicle Capacity is a searchable note. Before Add to Trip the dispatcher adds up the CBM column of the jobs on the Delivery Job listing against the vehicle, by eye.
• Enforce the order of statuses, or stop the office completing a job the driver has not done. Hide Start Job and Complete Job trims four listings; the trip’s job editor and Complete Trip still complete jobs. The supervisor reads the Job Event tab for the chain, and who is given the dispatcher’s applet is the control.
• Show the customer where the parcel is, outside a storefront. The goods tracker is a CP Commerce widget and answers only for a job that carries the tracking number; both tracking lookups need a tenant login. For everyone else the office answers from the job’s status and events, or from the carrier’s own tracking id on the job.
• Show the office a picture. Photos and the signature taken on the web driver applet are stored as text. Treat the name, IC and quantities as the proof of delivery; where a picture matters, take the signature on the dispatcher’s job screen or keep a signed paper note.
• Reconcile cash on delivery on a screen. The cashier counts the driver’s cash against a printable format that prints the amounts, or a list from the jobs API, per trip, the same day.
• Keep installation records. Survey, checklist and handover live outside BigLedger; custom statuses with dates mark the milestones on the job.

Prerequisites, blast radius and siblings

• Must exist first: a driver record whose e-mail is verified against the driver’s login, a vehicle with a capacity (required on every trip), and on the document, lines with Require Delivery set and sent with Send To Queue. Missing, in that order, they look like Failed to retrive trips, a trip that will not save, and an empty Job Sales Order screen.
• Downstream: job events, the document’s delivery status, the trip and job printables. Nothing in finance or stock.
• Siblings, and when to choose which: Choosing a delivery screen above. The shortest version: trips and jobs when a driver confirms stops; the Delivery Details panel when a date on the document is enough; Goods Delivery Note when goods are handed over against an order; Warehouse Management when picking is a walk through a warehouse.
• Blast radius: a Save from the Delivery Job listing wipes the proof of delivery and the carrier’s last reply; Cancel Trip cancels every job on it and returns every quantity to the queue; a voided invoice’s queue rows are still offered for a job; a job added by someone without trip read permission is not added at all.
• Used together: Sales Invoice, Send To Queue, Delivery Installation and the driver app; Import Shipment and Create Jobs; Sales Order, Warehouse Management, the DRAFT delivery order and then the invoice.

Related applets

• Delivery And Installation Driver — the driver-facing half; consumes the trips planned here and drives the same start/complete/cancel actions from the driver’s side.
• Driver Delivery Order Applet — the lightweight alternative when a single driver field on the Delivery Order is enough.
• Sales Order (Internal), Sales Invoice (Internal), Delivery Order (Internal) — the documents whose pick-pack queue rows become jobs and whose delivery-tracking status this applet updates.
• Organisation — branches and locations referenced by shipments, jobs and searches.
• Employee — drivers are separate delivery-module records, but the Job Created By and login links resolve to platform users.

Troubleshooting

This applet’s own symptoms are grouped by where you meet them: starting, completing and cancelling jobs, trips, shipments and jobs, details that went missing and printing, settings and screens.

Troubleshooting: starting, completing and cancelling jobs

Troubleshooting: trips, shipments and jobs

Troubleshooting: details that went missing

Troubleshooting: printing, settings and screens

Delivery symptoms across the screens

The tables above are this applet’s own, including three that also span the screens: Create Jobs doing nothing, Added Jobs to Trip with no jobs linked, and proof of delivery wiped by a save. These are the other symptoms that span the delivery screens, from the dispatch desk to the invoice.

Related documentation

• Installation Scheduling Workflow and Partial Delivery Workflow — the sales-side guides whose orders feed this applet.
• Inventory module — outbound movements and delivery orders.
• Delivery And Installation Driver — the driver applet reference.