Transport order template: a checklist for gathering information before entry

Three statuses keep facts, rules and assumptions separate

Before entering an order, assign a status to each piece of information. Received data is visible in an identified request or attachment. A known rule comes from master data, a contract or an operating instruction that has been approved for this customer and flow. Information is missing when no sufficiently reliable answer exists in the authorised sources.

This distinction is more useful than a single “order complete” checkbox. It shows what can be carried over as received, what requires the explicit application of a rule and what must be clarified. It also preserves the origin of every value eventually proposed for the TMS.

• Received data: retain the source, date and document or message version where available.
• Known rule: identify its scope, version and the person or process that approved it.
• Missing information: name the blocked decision and the person who can provide clarification.

Blank transport order template

Copy this template for each new request. The text in square brackets is a working prompt: replace it with a sourced value, or leave the item explicitly in the “Needs clarification” column. A blank row should never be treated as implicit approval.

Complete the checklist in decision order

Completeness depends on the actual workflow. A field may be essential in one flow and irrelevant in another. Preparation and entry criteria should therefore be agreed with the people responsible for the TMS, customer commitments and operational execution.

1. 01
   Classify the request

   Determine whether this is a new order, amendment, cancellation or supporting update. If the intent is unclear, do not create a new order by default.

2. 02
   Identify the parties and sites

   Connect the ordering party, contacts, pickup and delivery sites to references that were actually provided or to authorised master data.

3. 03
   Structure dates and goods data

   Retain dates, time zones, time windows, quantities, units, weights and volumes as expressed, and flag every conversion that is applied.

4. 04
   Make operational constraints explicit

   Separate direct instructions from previously approved rules, including access, equipment, handling, advance contact or other flow-specific conditions.

5. 05
   Choose the next status

   If every necessary decision has a verifiable basis, the record can be prepared. Otherwise, ask a focused question or hand over the case with its context.

Completed examples: one actionable order and one request to clarify

The two rows below are fictional examples. They show how the same template makes the difference visible between an adequately supported order and a request for which a decision cannot yet be made.

Turn the template into controlled TMS entry

Once the checklist is complete, entry remains a separate action. Prepared values must be reviewed according to the chosen supervision level, written through the authorised method — API, file exchange or interface interaction — and compared with the state actually displayed in the TMS.

Vigilo can connect the request, documents, applicable rules and decision around the same record. Within a configured and validated scope, it can prepare or execute the authorised action, check the outcome and hand ambiguous cases to the team with their context. This does not imply instant compatibility with every TMS or the removal of human approval.

• retain the source of every prepared value;
• identify the rules that were actually applied;
• block ambiguous or out-of-scope fields;
• verify the identifier and status obtained after entry;
• link any later correction to the correct record version.