Terminal dispatch software: define commercial readiness before integration

Topics: terminal management system; oil terminal dispatch documents; terminal ERP integration; dispatch exception workflow.

A road tanker arrives at a distribution terminal gate at 06:40 with a printed loading advice for 24 kilolitres (KL) of high-speed diesel. Inside the ERP, commercial operations amended the underlying sales order at 06:25 to 18 KL after a customer credit review, but the terminal scheduling board still displays the earlier 24 KL request. If the interface between the ERP and the terminal management system passes order lines without version checks or revocation rules, the bay supervisor discovers the mismatch only when the post-load bill of lading fails to post against the reduced order limit.

The core implementation question is which commercial records must agree before a dispatch request reaches the authorised operating workflow, and what happens when one of those records changes after the initial check. A commercial dispatch-readiness pilot should verify order status, credit release, nomination slot, vehicle reference and required administrative document references in a staged interface, then hand off a versioned readiness record to terminal operations. Commercial readiness never grants physical permission to enter a hazardous area or initiate loading; qualified terminal and safety roles retain operational release under the facility's technical and regulatory procedures.

Bound the pilot to commercial readiness, not physical loading control

A petroleum distribution terminal operates across two distinct control domains. The commercial domain—typically managed in an ERP and a transport or order-scheduling module—governs customer orders, credit exposure, tax or excise registration references, product allocation and carrier nomination. The operational domain—governed by terminal operating procedures, physical access checks, bay instrumentation and safety interlocks—controls vehicle inspection, earthing verification, bay assignment and product custody transfer.

Regulatory frameworks for petroleum terminals and installations, including the Petroleum and Natural Gas Regulatory Board (PNGRB) technical standards and specifications for petroleum installations (PNGRB T4S Regulations) and the Petroleum Rules administered by the Petroleum and Explosives Safety Organisation (PESO Petroleum Rules), address physical facility layout, hazardous-area precautions, licensed storage and safe handling operations. Those technical and statutory controls belong to qualified engineering, safety and terminal operations authorities.

A software pilot for dispatch readiness should establish a clean architectural boundary between business IT systems and operational technology (OT) environments, consistent with industrial control system segmentation principles described in NIST SP 800-82 Rev. 3. Specifically, the commercial readiness layer:

• Reads or receives staged extracts of sales orders, credit status, carrier nominations and administrative document indices from the ERP.
• Evaluates whether the commercial packet is complete, current and internally consistent for one bounded product group and order type (such as domestic road-tanker dispatches of a single bulk fuel grade).
• Publishes a read-only or staged Commercial Readiness Status with an explicit version number and freshness timestamp for the terminal dispatch desk.
• Issues zero commands to barrier gates, preset flow controllers, Permissive/Interlock loops or safety instrumentation.

Trace an order amendment across the ERP-to-terminal boundary

Illustrative example. Consider a single morning dispatch wave of 40 scheduled road-tanker requests at a bulk fuel terminal, representing 880 KL of requested volume across three compartment sizes. During pre-arrival screening between 05:30 and 07:00, the staged readiness check evaluates each request against five administrative criteria: active sales order status, valid credit release covering the order quantity, matching nomination slot ID, matching vehicle registration reference and active customer tax/receiving registration record.

Out of the 40 scheduled requests (880 KL total):

• 33 requests (726 KL) pass all five checks on their initial revision (rev 1) with an ERP timestamp fresher than 15 minutes, moving to Commercially Ready — Handed to Terminal Desk.
• 3 requests (66 KL) fail credit-release currency because an overnight payment clearing batch did not settle before the 05:30 extract (Hold — Credit Release Expired).
• 2 requests (44 KL) carry a carrier vehicle substitution submitted by the transporter that has not yet been linked to the customer's nomination record (Hold — Vehicle Reference Mismatch).
• 2 requests (44 KL) initially pass at 05:45 on rev 1, but receive commercial amendments in the ERP at 06:25 before the vehicles reach the terminal check-in desk.

Focus on one of those amended orders, Dispatch Request DR-4092:

1. At 05:45, Sales Order SO-88410 (rev 1) is approved for 24 KL across three 8 KL compartments (8 + 8 + 8 = 24 KL). At an illustrative contract price of ₹78,500 per KL, the order value is 24 × ₹78,500 = ₹1,884,000, within the customer's available credit headroom of ₹2,000,000. Readiness token RT-4092-v1 is marked Commercially Ready.
2. At 06:15, an earlier invoice from a separate depot posts for ₹550,000, reducing the customer's remaining credit headroom to ₹2,000,000 − ₹550,000 = ₹1,450,000.
3. At 06:25, the commercial controller amends SO-88410 to rev 2 for 18 KL (two 9 KL compartments, or two 8 KL compartments plus one 2 KL compartment depending on calibrated vehicle configuration: here 16 KL across two 8 KL compartments, 16 × ₹78,500 = ₹1,256,000, leaving ₹1,450,000 − ₹1,256,000 = ₹194,000 of remaining credit headroom).
4. At 06:26, the staged interface receives SO-88410 rev 2. Because RT-4092-v1 was tied to rev 1 (24 KL), the readiness service immediately transitions RT-4092-v1 to Invalidated — Superseded by SO-88410 rev 2.
5. Before RT-4092-v2 can be issued for 16 KL, the system checks whether the nominated vehicle's approved compartment table on the nomination record matches the revised 16 KL allocation. Until the commercial desk confirms the compartment revision from three 8 KL compartments (24 KL) to two 8 KL compartments (16 KL), the request remains in Hold — Amendment Pending Compartment Alignment.

Notice how the arithmetic reconciles every kilolitre: 726 KL (33 unamended) + 16 KL (1 re-aligned amendment) = 742 KL cleared for terminal desk intake, while 66 + 44 + (24 − 16) + 20 = 138 KL is accounted for across credit holds (66 KL), vehicle mismatches (44 KL), the 8 KL volume reduction on DR-4092, and the 20 KL cancellation on DR-4095 (742 + 138 = 880 KL). When post-dispatch inventory and movement records are later compared during terminal inventory reconciliation, DR-4092 carries a single unambiguous link between SO-88410 rev 2, readiness token RT-4092-v2 and the resulting 16 KL movement record.

Define ownership, exception states and stale-feed behaviour

A dispatch readiness interface fails most often when system unavailability or delayed batch jobs tempt staff to bypass commercial checks without an auditable trail. Before integrating the ERP and the terminal management system, define explicit state behaviour and role authority for every failure mode:

Keep the contingency rule strict: if the ERP connection drops during the morning peak, the staging screen must display the exact timestamp of the last confirmed extract and flag unverified requests as Stale Status. If business continuity procedures permit a manual commercial sign-off for pre-verified contract deliveries during an ERP outage, record the authorising commercial officer, the paper or offline order reference and a mandatory reconciliation flag so every offline release is matched to its ERP posting once connectivity returns.

What an acceptance test should verify before live cutover

Do not measure a dispatch readiness pilot by claiming it speeds up physical bay loading or replaces terminal safety checks. Evaluate the pilot on administrative record integrity and exception containment across a representative sample of dispatch requests:

1. Version-match coverage: Verify that every request handed to the terminal desk carries a current sales order revision, credit release reference, slot ID and vehicle registration that match the ERP at the handoff timestamp.
2. Amendment revocation latency: Inject a test order amendment, quantity reduction and cancellation after initial readiness clearance, and confirm that the staged readiness token transitions to Invalidated or Cancelled within the specified polling or event window without overwriting the historical v1 log.
3. Stale-feed detection: Simulate an interrupted ERP extract and confirm that the interface shifts pending requests to Stale Status — Confirmation Required rather than displaying outdated credit or order statuses as current.
4. Zero operational command assertion: Inspect the interface schema and network permissions to confirm that the readiness service has no write path to bay control equipment, physical gates or safety interlocks.

Summary and next actions

Defining commercial dispatch readiness before building a deep ERP-to-TMS integration prevents order revisions, credit holds and carrier substitutions from surfacing at the loading bay. By keeping the interface staged, versioned and strictly separated from physical terminal authorisation, commercial and operations teams each retain clear accountability for their own domain.

1. Select one bulk product group and dispatch mode (such as domestic road-tanker sales orders) and list the exact commercial fields required before terminal check-in.
2. Map the state transitions that must revoke an existing readiness token when an order quantity, compartment split, vehicle registration or credit status changes.
3. Define the freshness threshold for ERP extracts and the logged commercial contingency procedure for periods when the ERP is unreachable.
4. Run a shadow pilot across two weeks of morning dispatch waves to measure amendment revocation, mismatch capture and post-dispatch reconciliation rework before enabling live handoffs.

To scope a commercial dispatch-readiness pilot, start with an anonymised sample of recent dispatch exceptions, the current ERP order fields and the handoff sheet used by the terminal desk. The assessment should define the staged readiness record and exception owners while leaving terminal safety and loading control systems untouched.