Shipper portals: reduce duplicate order entry into the TMS

Start with the flow, not the portal name

Two portals may expose different functions, and one portal may be used to receive an order, download a document, confirm a slot or report a status. Saying that a portal is “connected” therefore says nothing about what is read, what may be written or how the result is checked.

Useful scoping takes place at object and action level. For every flow, the team identifies the system of record, triggering event, available references, granted permissions and expected state in the TMS. This map separates what can be processed from what should remain in observation or be returned to operations.

• new orders and corrected versions;
• amendments, cancellations and confirmations;
• slots, constraints and operational statuses;
• documents to download or attach;
• acknowledgements, references and evidence of acceptance.

The matrix to complete for every portal and object

The following matrix is a fictional scoping example. Each row represents a distinct flow to be verified with the portal operator and the team responsible for the TMS; it does not describe integrations that have already been deployed.

A row is useful only when its terms can be tested. “Access the portal” is too vague; “read a new order, find its reference in the TMS and check the five defined fields” creates an observable scope. The matrix should also name the owner of the control and the response when an identifier is missing.

Combine APIs, files and the interface around the actual need

An API is useful when it exposes the required object, action and response with suitable permissions. A file works well for structured batches and deferred processing if versions, rejections and acknowledgements are controlled. Authorised interaction with the user interface can cover a function available only on screen, provided the journey, session and verification have been qualified. None of these access methods is automatically superior for every flow.

One workflow may combine them: a notification announces a new order, an API provides the data, a file carries the documents and the interface exposes a status that is unavailable elsewhere. The architecture should follow the source of truth and the level of risk instead of forcing every event through one channel.

1. 01
   Read

   Select the access method that supplies the useful data with its reference and version.

2. 02
   Decide

   Apply only the rules and permissions validated for this object.

3. 03
   Act

   Create or update the TMS through the method defined for that action.

4. 04
   Verify

   Reread the authoritative state and retain evidence of the outcome.

5. 05
   Hand over

   Return ambiguous, prohibited or unverifiable cases with their context.

Prevent duplicates and status discrepancies

The main risk is not limited to an incorrect field. The same order may appear in an export and later in the interface, be sent again in a second batch or be amended after it was first read. Without a matching key and version history, recovery can create two TMS orders or overwrite newer information.

Before creating anything, the workflow searches the TMS for the external identifier and any authorised secondary keys. Before an update, it compares the source version with the last processed version and current state. A similar route, date or customer may help propose a match, but it is not enough to merge two transports silently.

Plan for sessions, changes and recovery before deployment

Portal access changes over time: an expired session, stronger authentication, a revoked permission, a renamed label, a reorganised screen or a changed file format. These events must not be treated as an absent order or bypassed. The workflow stops when it no longer recognises the validated conditions or cannot prove the outcome.

Recovery begins by establishing whether an action has already occurred. The workflow rereads the portal and TMS using known identifiers, then classifies the case: no action observed, successful action, partial result or indeterminate state. Only the first case allows an automatic retry when the rule permits it. The others require controlled correction or a human decision to avoid creating a duplicate.

Within a qualified scope, Vigilo can connect a portal event to the transport record, apply authorised rules, prepare or execute the planned action and check its outcome. Deployment remains specific to the company’s sources, objects, identifiers, access methods and responsibilities; it is not a promise of instant compatibility with any particular portal or TMS.

• test normal session expiry and renewal without bypassing protections;
• detect a screen, field, format or permission that no longer matches the validated version;
• retain the last confirmed checkpoint and all identifiers already obtained;
• reread both systems before any new attempt;
• version the map and suspend only the affected flow;
• give the team the source, attempted action, observed state and required decision.