Transport execution guide

Operations Module Documentation

This guide explains how the Operations Module works from a customer transport request to truck nomination, trip creation, approval, dispatch, tracking, incident handling, document capture, delivery confirmation, closure, and reporting.

1. Purpose and Users

The Operations Module is the working area for transport execution. It connects customer demand, fleet allocation, dispatch control, tracking, cost capture, delivery evidence, and closure. The module is used by dispatchers, operations managers, transport managers, tracking officers, branch controllers, finance users, and management teams who need visibility on live and completed movements.

The workflow is designed to avoid creating uncontrolled trips. A transport request records the job required by the customer. A truck nomination reserves and validates the fleet combination. An approved nomination is converted into an execution trip. The trip then moves through approval, dispatch, live progress updates, delivery confirmation, billing readiness, and closure.

2. Transport Request Capture

The process starts with a transport request. This record captures the customer order, client, branch, allocated loading depot, route code, trip type, origin, pickup point, destination, delivery point, countries, cargo description, product, volume, distance, revenue, estimated cost, petroleum flag, POD requirement, planned departure, planned arrival, and notes.

If a request number is not entered, the system generates one automatically using the `TRQ` prefix. New requests normally start as awaiting nomination. The request remains editable until it is converted to a trip or cancelled. Once converted, the request becomes part of the trip trace and should not be changed as an open planning record.

3. Truck Nomination

After the request is created, operations nominates a truck. A nomination selects the truck, linked trailer, optional secondary trailer, driver, optional co-driver, branch, client, depot, expected loading date, transporter details, destination information, border point, consignee details, vehicle plate details, and compartment plan. The system can create one nomination at a time or create several nominations from the batch sheet.

During nomination, the system refreshes readiness. It checks capacity and availability so teams can resolve problems before submission. The nomination cannot be submitted while capacity is under requirement or availability is blocked. Pending approval and approved nominations reserve the selected truck and trailer combination, preventing accidental double allocation.

A nomination starts as draft. It can be submitted for approval, approved, rejected, cancelled, expired, or converted to trip. Once approved, it can be converted into the execution trip. The conversion carries the customer, route, branch, fleet assignment, driver assignment, product, schedule, and planning context forward.

4. Trip Planning and Creation

Trips can be created from an approved nomination. In this build, normal trip creation expects a nomination first, so users are redirected to the nomination board when they try to create a trip without one. This keeps dispatch aligned to the approved fleet reservation process.

The trip stores the order number, trip number, transport request, nomination, client, branch, depot, truck, trailers, driver, co-driver, route, trip type, transit SLA, origin, destination, cargo, product, revenue, estimated cost, planned costs, route legs, petroleum data, schedule, approval status, and document requirements. If trip or order numbers are missing, the system generates references automatically.

Route matrix and transit SLA services enrich planning. Multi-leg trips can store structured legs with sequence, pickup, delivery, countries, depot, distance, and notes. Planned costs can be attached so operations and finance can compare planned cost against actual workflow costs later.

5. Approval, Dispatch, and Progress Updates

Draft trips are submitted for approval before dispatch. The approval readiness check confirms that a customer exists, a route is captured, revenue is greater than zero, and assigned truck, trailer, driver, and co-driver records are compliant. Compliance uses documents, service schedules, asset status, and driver readiness checks.

After approval, operations can move the trip through workflow states such as assigned, dispatched, loaded, in transit, at border, delivered, closed, or cancelled, depending on the allowed transition from the current state. Dispatch is blocked if the assigned resources fail compliance. When dispatch succeeds, the system records the departure time and clears any previous dispatch block reason.

Every workflow update can capture location, event time, delay minutes, remarks, actual kilometres, delay reason, route deviation notes, delivery confirmation details, and cost entries. Cost entries captured during workflow updates become finance cost entries linked to the trip.

6. Live Tracking, Incidents, and Documents

The trip detail page can show tracker status and recent tracker history for the assigned truck. The tracking workspace gives teams a broader view of fleet location and signal health. Tracking is useful during dispatched, loaded, in-transit, border, and delivered stages because operations can compare planned progress with live movement.

Operational incidents can be linked to a trip, asset, and driver. They record category, severity, status, occurrence details, responsible team, corrective action context, and closure notes. Incidents allow the business to preserve operational risk history without hiding it inside free-text trip remarks.

Trip documents are uploaded against required categories. The POD category is special: when a POD is uploaded, the trip records the POD received time. Required document categories are used later by the closure gate.

7. Delivery, Billing Readiness, and Closure

A trip cannot be closed casually. Standard closure expects delivery data, actual kilometres, delivery confirmation date, at least one cost basis, billing readiness, and all required documents. If these requirements are missing, the system blocks closure.

Authorized users can close with an override when business reality requires it. The override requires permission and a reason. The system stores the missing requirements, authorizer, reason, and authorization time, then writes an audit entry. This keeps exceptions visible instead of silently bypassing controls.

Petroleum trips have extra volume controls. The trip stores loaded volume, delivered volume, loss allowance, actual loss, allowable loss, excess loss, volume gain, and loss status. Petroleum stage updates can capture loading, offloading, completed stage values, and related cost entries.

8. Reporting and Connected Modules

Operations connects to Fuel, Finance, Tracking, Workshop, Documents, Approvals, Audit Trail, and Reports. Fuel logs add fuel cost to the trip. Finance entries, mileage payments, invoices, receipts, credit notes, and billing status affect profitability and closure. Daily checklists and workshop records provide fleet readiness context. Audit logs preserve creation, update, approval, dispatch, reassignment, and closure activity.

Reports can use trip status, route, branch, client, delivery timing, petroleum loss, revenue, cost, gross profit, fleet allocation, and operational incidents. In short, the Operations Module starts with controlled demand capture, reserves compliant fleet through nomination, converts approved work into trips, manages dispatch and live progress, captures delivery and cost evidence, and finishes with controlled closure and reporting.