TRADLINX

Most “visibility problems” aren’t satellite problems—they’re data problems: mismatched identifiers, fuzzy locations, and competing clocks for the ETA. This guide gives enterprise teams a clean, non-technical playbook to fix the root causes and publish one ETA everyone can use—across regions, partners, and ERPs.

---

Part A — Master data alignment that removes most visibility errors

1) Lock the three core identifiers (and their formats)

• Container ID: store the full ISO 6346 code in uppercase, no spaces (e.g., MSCU1234567), and validate the check digit on ingest.
• B/L number: keep the exact carrier format (prefix + serial). Strip whitespace on ingest; preserve the original for auditing.
• PO / Shipment ID: use your internal primary key as the parent; link downstream B/Ls and containers as children (1→many allowed).

2) Normalize the reference data once—use it everywhere

• Locations: standardize on UN/LOCODE for ports/places (e.g., CNSHA), and keep a companion human name for UI.
• Vessels: store the IMO number (7 digits) as the canonical vessel key; treat voyage numbers as carrier-specific labels.
• Timestamps: store events in UTC ISO 8601 (2025-10-21T08:00:00Z); convert to local timezones only at display/report time.

3) Build “guardrails” at ingest

• Container check: run the ISO 6346 check-digit test; reject or quarantine failures.
• Location check: verify UN/LOCODE exists and is active; map legacy names to codes via your reference table.
• Time sanity: prevent future/past impossibilities (e.g., ATA < ETD, time zone offsets that move arrivals to the wrong day).

4) Match data in a deterministic order (and stop guessing)

1. Direct match: container ID + B/L number.
2. Fallback: B/L + consignee + port pair + date window (±3–5 days).
3. Escalate: PO + supplier + sailing window; flag for human review if still ambiguous.

5) Give each field an owner and a fix-path

• Who owns what: assign teams to container IDs, B/Ls, locations, timestamps (one owner per field).
• How to fix: document “where to correct it” (carrier portal vs. ERP master vs. partner EDI) and the SLA for re-publishing.

Common failure modes (and quick fixes)

• Typos in container IDs: enforce check-digit validation; add auto-correct for common OCR swaps (O↔0, I↔1, B↔8).
• Free-text locations: replace with UN/LOCODE; keep a one-time mapping table for legacy names.
• Time zone drift: store UTC; display with IANA time zones; never store “local time” without its zone.
• Duplicate shipments: de-duplicate on (B/L, container) and suppress events that only rename the same thing.

30-day cleanup plan (lightweight)

1. Week 1: freeze formats (container, B/L, PO), load UN/LOCODE reference, enable UTC timestamps.
2. Week 2: turn on container check-digit validation; quarantine bad IDs; map top 50 free-text locations to UN/LOCODE.
3. Week 3: switch your joins to the deterministic matching order; publish the fix-path playbook.
4. Week 4: measure: % containers failing validation, % events without UN/LOCODE, # of duplicate shipments removed.

---

Part B — Standardize ETAs across regions, partners, and ERPs

1) Decide which ETA you will promise

ETA type	Definition	Primary use
Vessel ETA @ POD	When the vessel is expected to arrive (berth/first line ashore).	Planning transshipment and onward legs.
Container Availability ETA	When the box is expected to be available for pickup (post-discharge & customs/holds).	Dray & warehouse appointments; fee risk.
Final Delivery ETA	Expected delivery to consignee/DC.	Customer-facing promises.

Pick one “customer promise ETA” for external use (usually Availability or Final Delivery) and keep the others as operational clocks.

2) Agree on one event vocabulary

• Use a standard event set for milestones (e.g., EstimatedArrival, ActualArrival, Discharged, AvailableForPickup, GateOut) with clear definitions.
• Publish the status ladder (which event replaces which) so ERPs and partners don’t show conflicting states.

3) Establish a source-of-truth hierarchy for ETA

1. Terminal availability (when present) overrides carrier schedule for Availability ETA.
2. Carrier/line updates drive Vessel ETA and transshipment windows.
3. Predictive ETA fills gaps, but yields to either of the above when authoritative data arrives.

4) Add confidence bands instead of single-point promises

• Publish ETA as a window (e.g., Feb 23–24) based on recent lane error—tight for directs, wider for transshipment/chokepoints.
• Escalate automatically when a change exceeds a set threshold (e.g., >24h slip inside 7 days of arrival).

5) Time discipline (so ETAs don’t drift)

• Store events in UTC ISO 8601; convert to local on display; annotate the time zone shown.
• Trigger updates on berth/anchorage change, port omission, transshipment re-plan, customs/hold release.
• Version ETAs: keep a change log (old → new, timestamp, reason) so audits and QBRs are objective.

Governance checklist

• One definition per event; one owner per field; one playbook for changes.
• A weekly 10-minute review: top exceptions, top bad fields, top partners causing rework.
• KPIs to watch: % shipments with a single customer ETA; % ETA changes >24h in the last 7 days; % events failing validation.

---

30-minute worksheet (copy/paste to kick off)

1. Identifiers: Are container IDs validated? Are B/L formats consistent? Is PO → B/L → container linkage 1→many?
2. Locations: Are all ports stored as UN/LOCODE? Do we still accept free text? Who maps new codes?
3. Timestamps: Are we storing UTC ISO 8601? Which UIs convert to local time?
4. Events: Do we have one vocabulary? Which systems still use synonyms?
5. ETA promise: Which ETA is customer-facing? What’s the confidence band by lane?
6. Hierarchy: What beats what (terminal vs. carrier vs. predictive)? Is it coded or tribal knowledge?

---

One last thought

Clean identifiers + a shared event vocabulary + a single promised ETA = fewer escalations, fewer “where’s my box?” threads, and fewer avoidable fees. The setup work is small; the payoff is daily.

---

References

1. DCSA — Track & Trace standard (event definitions & API foundation)
2. DCSA — Information Model (entities & relationships, 2024.Q3)
3. BIC — ISO 6346 container check digit (validation and rationale)
4. UN/LOCODE — Code system for trade and transport locations
5. UN/LOCODE — Current code lists by country/territory
6. W3C — Working with time and time zones (best-practice guidance)
7. GS1 — Logistic Label Guideline (SSCC for logistic units)
8. DCSA — Shipping glossary (arrival/berth terminology)

---

If you’re ready to make this stick at scale, use a single live view of each B/L and container, share a no-login status page with teams and partners, and embed a simple tracking widget on your portal—so everyone acts on the same ETA without extra back-and-forth.

Prefer email? Contact us directly at min.so@tradlinx.com (Americas), sondre.lyndon@tradlinx.com (Europe) or henry.jo@tradlinx.com (EMEA/Asia)