DCSA API-Standards für den globalen Zugriff auf Versanddaten

DCSA-API-Standards: Datenzugänglichkeit in der globalen Schifffahrtsindustrie

Implementieren Sie DCSA-APIs jetzt: Priorisieren Sie die Endpunkte für Buchungen, Ereignisse und Nachverfolgung und übernehmen Sie standardisierte Payloads innerhalb von 12 Wochen, um manuelle Berührungspunkte um ~40 % zu reduzieren und nahezu Echtzeit-Updates für jeden Benutzer bereitzustellen.

Beginnen Sie mit drei praktischen Schritten: Ordnen Sie bestehende Schnittstellen zu, exponieren Sie eine dünne API-Schicht für Altsysteme, die noch EDI verwenden, und pilotieren Sie satellitengestützte Positionsdaten, um Ereignisdatensätze anzureichern. Dieser Ansatz bewahrt den aktuellen Betrieb und schafft gleichzeitig einen nahtlosen Weg für automatisierte Benachrichtigungen und ETA-Korrekturen.

Messen Sie die Ergebnisse, um den Wert nachzuweisen: Verfolgen Sie die durchschnittliche Bestätigungszeit für eine Buchung, die prozentuale Reduzierung von E-Mail-Threads, die Häufigkeit von Statusaktualisierungen pro Reise und die Auslastung von API-Aufrufen pro Kunde. Diese Kennzahlen zeigen, wie die Transformation Beschaffung und Betrieb in der gesamten Lieferkette verändert und wie Teams zusammenarbeiten, um Liegezeiten und Fehlroutungen auf einem Schiff zu reduzieren.

Folgen Sie klaren Plänen: Führen Sie ein dreiteiliges Pilotprojekt mit einem Spediteur, zwei Verladern und einem Terminal durch; veröffentlichen Sie SLA- und Versionierungsregeln; stellen Sie SDKs und Beispiel-Payloads bereit; und planen Sie wöchentliche Integrationsprüfpunkte. Diese konkreten Schritte liefern heute wiederholbare Ergebnisse und machen standardisierte Daten für nachgelagerte Systeme, Analysen und Partnerintegrationen verfügbar.

DCSA-API-Standards: Datenzugänglichkeit in der globalen Schifffahrt – Abgleich von Ankunftszeiten von Containerschiffen und Plattformbereitstellung für die Digitalisierung

Implementieren Sie DCSA-API-Standards innerhalb von 12 Monaten, um die Veröffentlichung von Schiffs-ETAs, die Liegeplatzzuweisung und die Plattformbereitstellung zu synchronisieren, manuelle Übergaben zu reduzieren und automatische betriebliche Aktualisierungen zu ermöglichen.

Fordern Sie APIs auf, ETA- und Statusaktualisierungen in 15-Minuten-Intervallen zu veröffentlichen, und unterstützen Sie ereignisgesteuerte Webhooks für die sofortige Kommunikation zwischen Spediteuren, Terminals und Agenten. Integrieren Sie AIS- und Satellitenfeeds, damit Position und Geschwindigkeit auf der Route erfasst und in Hafensysteme übertragen werden; standardisieren Sie Payloads mit ISO 8601-Zeitstempeln und UN/LOCODEs, um Mapping-Fehler während der Übertragung zu vermeiden. Planen Sie drei Hauptversionen pro Jahr mit semantischer Versionierung und klar veröffentlichten Fenstern für Abwärtskompatibilität, um Benutzern vorhersehbare Upgrade-Zyklen zu bieten.

Optimieren Sie Liegezeitfenster, indem Sie operative Daten von Terminalbetriebssystemen und Speditionsplanungssystemen kombinieren; Pilotprojekte mit Maersk und Terminalpartnern zeigen eine Reduzierung der Liegezeitwartezeiten um bis zu 20 % und eine höhere Liegeplatznutzungsrate als bei manueller Terminplanung. Verwenden Sie automatische Liegeplatz-Neuzuweisungsregeln und Kommunikationsbenachrichtigungen, um Liegeplatz-Leerlaufminuten zwischen Schiffsabfahrten zu reduzieren und den Durchsatz weiter zu verbessern, als es ad-hoc-Nachrichten können.

Integrieren Sie Umweltkennzahlen in jede API-Payload: Kraftstoffverbrauch, Betriebsstunden von Hilfsmotoren und satellitengestützte Emissionsschätzungen. Leiten Sie diese erfassten Kennzahlen an Dashboard des Hafen- und Speditionsmanagements weiter, um CO2 pro TEU zu quantifizieren und messbare Ziele für eine nachhaltige Entwicklung festzulegen. Sie ermöglichen es Betreibern, Routen- und Liegeplatzwahlkriterien in Bezug auf Emissionen und Betriebskosten zu vergleichen, was strategische Entscheidungen ermöglicht, die bessere Nachhaltigkeitsergebnisse liefern.

Etablieren Sie eine Governance, die die Konformität der Standards mit vertraglichen SLAs verknüpft, Kommunikationsprotokolle klärt und die Verantwortung für die Datenqualität zuweist. Fördern Sie Entwickler-Toolkits, Sandbox-Umgebungen und offene Dokumentationen, um die Entwicklung und Einarbeitung neuer Benutzer zu beschleunigen. Überwachen Sie KPIs – Genauigkeit der Ankunftszeit, Erfolg des automatischen Transfers und Reduzierung manueller Eingriffe – und veröffentlichen Sie vierteljährliche Berichte, damit Stakeholder den Fortschritt messen und weitere Integration planen können.

Operativer Blueprint: Anwendung von DCSA-APIs zur Abstimmung von Schiffsankunftsdaten

Implementieren Sie einen standardisierten Prozess zur Abstimmung des Ankunftszustands mithilfe der DCSA Event-, Voyage- und Port Call-APIs mit einem 24-Stunden-SLA, um Schiffsankünfte zwischen Spediteuren, Häfen und Terminals abzustimmen.

Erfassen Sie Ankunftsdaten aus drei Hauptquellen: Spediteursmanifeste über die DCSA Voyage API, Terminalsysteme über die Port Call API und AIS-Feeds. Verwenden Sie Event API Webhooks für schnelle Updates und greifen Sie bei fehlgeschlagenen Webhooks auf periodische Abfragen in Intervallen von 5 Minuten zurück. Kennzeichnen Sie jeden Datensatz mit einem SOURCE-Feld (Quelle) und einem capture_timestamp, um die Herkunft zu erhalten und Audit-Trails zu unterstützen.

Normalisieren Sie eingehende Payloads auf ein einziges operatives Modell mit den folgenden spezifischen kanonischen Feldern: vessel_imo, voyage_id, eta_utc, ata_utc, berth, status_code, bunker_onboard_mt, estimated_fuel_burn_mt, customs_status und event_origin. Konvertieren Sie alle Zeiten in UTC, runden Sie auf die nächste Minute und ordnen Sie unterschiedliche Statuscodes einer 7-Phasen-Ankunfts-Taxonomie zu (geplant, ETA aktualisiert, unterwegs, angekommen, Längsseits, angelegt, abgefahren).

Verwenden Sie deterministische Abgleichregeln: Exakter Abgleich von vessel_imo + voyage_id, falls verfügbar; andernfalls Abgleich von vessel_imo + eta-Fenster ±72 Stunden unter Verwendung einer Scoring-Funktion, die Event API = 0,5, AIS = 0,3, Terminalnachrichten = 0,2 gewichtet. Kennzeichnen Sie Abweichungen mit einem Score <0,6 zur menschlichen Überprüfung. Definieren Sie eine Abweichungsschwelle von 60 Minuten für ETA vs. ATA; behandeln Sie größere Lücken als operative Ausnahmen, die den Kraftstoffverbrauch und die Zollhaltezeit erhöhen können.

Integrieren Sie die Ausnahmebehandlung gleichzeitig in Benutzeroberflächen und Maschinenschnittstellen. Leiten Sie Ausnahmen mit hoher Schwere über API-Benachrichtigungen an die Speditionsbetriebsteams und über UI-Dashboards an die Terminalplaner weiter. Bieten Sie Benutzern vorgeschlagene Korrekturmaßnahmen: Umleitung zu einem alternativen Liegeplatz, Aufforderung zur sofortigen Bunkeranpassung oder Vorabfertigung von Zolldokumenten. Erfassen Sie Bedienerentscheidungen und die Lösungsdauer für spätere Analysen.

Messen Sie die Leistung mit den folgenden KPIs und Zielen: discrepancy_rate (<5 % innerhalb von 6 Monaten), mean_time_to_align (<4 Stunden), SLA_adherence (≥98 %), bunker_variance (±3 % des gemeldeten Bunkers an Bord) und economic_impact_estimate pro Ankunft. Verwenden Sie die letzten drei Monate als Basislinie und führen Sie im Oktober ein Pilotprojekt auf einer führenden Asien-Europa-Route mit 500 erfassten Ankünften durch, um Einsparungen und Modellgenauigkeit zu validieren.

Wenden Sie Transformationsregeln an, die Duplikatereignisse reduzieren und die Nutzung von Systemschnittstellen verbessern: Löschen Sie Duplikate innerhalb von 2 Minuten von derselben Quelle, fügen Sie Ereignisse mit identischem vessel_imo+event_origin+timestamp zusammen und speichern Sie Rohe-Payloads für die Herkunftsnachverfolgung. Annotieren Sie Datensätze mit einem events_history-Array, damit Analysten die zeitlichen Muster verstehen können, die zu Abweichungen während der Reise geführt haben.

Verwalten Sie Datenflüsse mit versionierten API-Verträgen, OAuth2-Token pro Partner, Ratenbegrenzungen, die auf Spitzenbetrieb abgestimmt sind (empfohlen 1.200 Aufrufe/Min. für Event-Abonnements) und Aufbewahrungsrichtlinien (Rohdaten für 12 Monate, aggregiert für 36 Monate). Pflegen Sie ein branchenweites Schema-Repository, damit Partner sich auf Feldsemantiken einigen und die Mapping-Aufwände über die anfängliche Integration hinaus reduzieren können.

DCSA API	Erfasste Schlüsselfelder	Aktion	SLA / Ziel
Event API	event_type, timestamp, location, vessel_imo, voyage_id	Echtzeit-Erfassung, zuerst Webhook, Debounce 2 Min	Webhook-Lieferung <30s; zweimal erneut versuchen
Voyage API	voyage_id, eta_utc, planned_port_calls, cargo_manifest	Kanonsches Voyage-Datensatz befüllen, Manifest-Abweichungen kennzeichnen	Alle 4 Stunden synchronisieren; Updates innerhalb 1 Stunde
Port Call API	port_call_id, berth, alongside_time, berthed_time, customs_status	Hafen-seitigen Status abgleichen, Zoll-Holds melden	Update <15 Min nach lokalem Ereignis
Reference Data API	locations, terminals, carrier_codes	Namen/IDs auflösen, Mapping-Fehler reduzieren	Wöchentliche Aktualisierung; Hotfixes innerhalb 24h
Location / AIS	lat, lon, sog, cog, timestamp	ETA/ATA ergänzen, Schätzung des Kraftstoffverbrauchs	Stream-Latenz <60s

Führen Sie ein dreimonatiges Pilotprojekt mit diesen Schritten durch: Implementieren Sie Integrationen auf einer führenden Route im Oktober, nehmen Sie 500 vergangene und Live-Ankünfte zur Schulung des Abgleichmodells auf, wiederholen Sie Regeln, um falsch-positive Ergebnisse auf <8 % zu reduzieren, und messen Sie die wirtschaftlichen Auswirkungen monatlich. Melden Sie Ergebnisse an Zollpartner, um die Abfertigungsfenster zu verkürzen, und an OPS-Teams, um Wartezeiten zu reduzieren, die den Bunkerverbrauch erhöhen. Nutzen Sie die Erkenntnisse aus dem Pilotprojekt, um branchenweit zu expandieren und Schnittstellen zu skalieren, damit Benutzer abgestimmte Ankunftsdaten über lokale Silos hinaus sehen.

Identifizieren Sie den kritischen Endpunktsatz für die Abstimmung von Schiffsankünften: erforderliche DCSA-APIs und Payloads

Implementieren Sie diesen minimalen Endpunktsatz, um Schiffsankünfte abzustimmen: Port Call (voyage/eta), Event Notifications (webhook), Transport/Movement, Booking, Equipment/Container, Terminal Interface, Reference/Location und Party APIs.

Port Call Payload: enthält voyageId, vesselIMO, vesselName, voyageNumber, portCode (UN/LOCODE), scheduledArrival (ISO-8601), estimatedArrival, scheduledDeparture, berthingWindowStart, berthingWindowEnd, berthCode, draftMeters, nextPortCode und sequenceVersion. Verwenden Sie numerische Felder für TEU und Tiefgang und geben Sie sourceSystem und lastUpdatedBy an. Beispielsweise: scheduledArrival: "2026-03-10T14:00:00Z". Übertragen Sie den vollständigen Voyage-Schnappschuss bei der ersten Synchronisierung und Deltas danach.

Event Notifications Payload: eventType, eventTimestamp, relatedId (voyageId, containerNumber, bookingReference), locationCode, statusCode, details, sequenceNumber und idempotencyKey. Senden Sie POST-Anfragen im application/vnd.api+json JSON:API-Format an Subscriber-Endpunkte mit Retry/Backoff und exponentiellen Fenstern. Kennzeichnen Sie Ereignisse als automatisch oder manuell und nehmen Sie eventProvenance auf, um das System zu identifizieren, das das Ereignis generiert hat.

Transport/Movement Payload: transportId (GUID), shipmentId, bookingReference, carrierBookingReference, billOfLadingNumber, originUNLOC, destinationUNLOC, mode, containers:[{containerNumber,sizeType,status}], cargoType, weightKg, loadedOnVoyageId und currentStatusTimestamp. Stellen Sie manifestReference und estimatedOnboardTime bereit, wenn verfügbar, um die Terminalplanung zu unterstützen.

Booking Payload: bookingReference, shipperPartyId, consigneePartyId, commodities, totalTEU, containerRequirements, portCutoffTimes:{terminalCutoff,gateCutoff,docsCutoff} mit Zeitzone, requestedPickupDate und confirmedStatus. Verwenden Sie diese Werte, um Terminal-Slotting- und Terminbuchungssysteme zu steuern; speichern Sie bookingVersion zur Abstimmung.

Equipment/Container Payload: containerNumber, isoSizeType, tareKg, grossKg, currentLocationCode, lastFreeTime, containerStatus und sealInfo. Verbinden Sie diese Datensätze mit transportId und voyageId, sodass Terminalsysteme und Kunden eine einzige Wahrheitsquelle sehen.

Terminal Interface Payload: terminalCode, berthCode, availableCraneCount, plannedBerthStart, plannedBerthEnd, gateSlots (Zeitfenster), yardOccupancyPercent und serviceLevels. Entwerfen Sie das Modell so, dass Terminals Bestätigungen von Liegeplätzen und Slot-Zuweisungen zurück in die Port Call- und Booking-Domänen übertragen können.

Reference und Party Payloads: partyId (Spediteur, Terminal, Verlader, Empfänger), Namen, Rollen, Kontaktmethoden und locationList. Stellen Sie UN/LOCODE und standardisierte Rollenbegriffe bereit, um konsistente Abgleiche im gesamten Ökosystem der am Versand beteiligten Systeme zu fördern.

Protokoll- und Implementierungsregeln: Übernehmen Sie den JSON:API-Inhaltstyp, fordern Sie RFC3339-Zeitstempel an, erzwingen Sie die obligatorischen Schlüssel, die oben aufgeführt sind, unterstützen Sie PATCH für Delta-Änderungen und versionieren Sie Endpunkte. Verwenden Sie Webhooks für die automatische Ereignisbereitstellung und stellen Sie eine Pull-API für die vollständige Synchronisierung bereit. Ratenbegrenzungsrat: Erlauben Sie 5 Anfragen/Sek. pro Client für Synchronisierungs-Endpunkte und 1.000 Webhook-Ereignisse/Min. mit Backoff bei 429-Antworten.

Operative Empfehlungen: Übertragen Sie ETA-Updates häufiger, je näher sich ein Schiff befindet – zum Beispiel alle 15 Minuten, bis zu 48 Stunden vor Ankunft, alle 5 Minuten innerhalb von 6 Stunden und sofort bei tatsächlicher Ankunft/Anlegen. Fügen Sie sequenceNumber und lastProcessedEvent in Antworten ein, damit konsumierende Systeme ohne Duplikate und unter Beibehaltung der Idempotenz fortfahren können.

Überwachung und Inbetriebnahme: Stellen Sie Metriken für deliverySuccessRate, averageLatencyMs und processingErrors pro Endpunkt bereit. Führen Sie eine Checkliste zur Inbetriebnahme durch, die Schema-Validierung, Webhook-Wiederholversuche, Authentifizierung (mTLS oder OAuth2) und End-to-End-Tests zwischen Spediteur-, Terminal- und Kundensystemen umfasst. Weisen Sie ein funktionsübergreifendes Team zu, das diese Elemente während des ersten Sprints entwickelt und überwacht.

Mapping- und Datenmodellierungsanleitung: Ordnen Sie lokale Felder kanonischen Namen (voyageId, portCode, scheduledArrival) in einer Integrationsschicht zu; bewahren Sie ursprüngliche Quellkennungen in einem sourceRef-Array. Verwenden Sie ein changeLog-Modell, das aufzeichnet, wer was wann geändert hat, um nachgelagerte Abgleiche und Kundenbenachrichtigungen zu steuern.

Sicherheit und Governance: Fordern Sie Token-Scopes pro Endpunkt an und beschränken Sie die von der Rolle zurückgegebenen Daten. Erfassen Sie Einverständniserklärungen und vertragliche Bedingungen für den Datenaustausch und nehmen Sie auditTrail-Einträge für übertragene Ereignisse auf, damit Kunden und Terminals die Herkunft überprüfen können.

Beginnen Sie die Implementierung mit einer priorisierten Checkliste: 1) Port Call und Event Webhooks, 2) Transport und Booking Sync, 3) Terminal Interface und Equipment, 4) Reference und Party Konsolidierung, 5) Überwachung und Inbetriebnahme-Tests. Diese Reihenfolge reduziert den Integrationsaufwand im Vergleich zu Ad-hoc-Ansätzen und ermöglicht es dem Team, innerhalb weniger Wochen sichtbare Ankunftsabstimmungen für Lieferungen zu erzielen.

Übersetzen Sie Hafenrufereignisse in eine kanonische Ankunftszeitachse: Mapping-Regeln und Zeitstempel-Priorität

Wenden Sie einen fünfteiligen Satz von Mapping- und Zeitstempel-Prioritätsregeln an, um eine einzige kanonische Ankunftszeitachse für jedes Schiff und jede Lieferung zu generieren: Ordnen Sie rohe Ereignisse kanonischen Phasen zu, wählen Sie den Zeitstempel mit der höchsten Priorität für jede Phase aus, weisen Sie die Quellzuverlässigkeit zu und kennzeichnen Sie Konflikte zur menschlichen Überprüfung.

Definieren Sie kanonische Phasen als: Annäherung (Schiff innerhalb von 24 NM vom Hafen), Pilot an Bord, Längsseits/Anlegen, Beginn der Ladeoperationen (Empfang der ersten Containerbewegung), Abschluss der Ladeoperationen und Abfahrt. Ordnen Sie Quellereignisse diesen Phasen zu: AIS-Positionsberichte, Lotsen-/Hafenbehördenmanifeste, TOS-Anlegeereignisse (Terminal Operating System), Betriebsmitteilungen der Reederei (SOC/COC), Gate-In/Gate-Out-Container-Scans und Logbucheinträge des Schiffes. Speichern Sie einen kanonischen Zeitstempel pro Phase und bewahren Sie ursprüngliche Ereignislisten für Audit und Abgleich auf.

Zeitstempel-Priorität (höchste zu niedrigste): 1 – Hafenbehörden-/Lotsenzeitstempel für Pilot an Bord- und Anlegegenehmigungen (maßgeblich). 2 – TOS-Zeitstempel für Längsseits/Anlegen und Beginn der Ladeoperationen. 3 – Terminal-/Container-Gate-Scans für Empfang und Containerbewegungen. 4 – Betriebsmitteilungen der Reederei (ETA/ATA, SOC/COC) für geplante und vom Betreiber bestätigte Meilensteine. 5 – AIS-abgeleitete Zeitstempel (Position überquert X NM, im Anleger gestoppt) für automatische Erkennung. Immer normalisieren Sie in UTC ISO 8601 und ordnen Sie Quellkennungen und Konfidenzwerte zu.

Lösen Sie Konflikte mit deterministischen Regeln: Wenn ein Zeitstempel mit höherer Priorität existiert, verwenden Sie ihn für die kanonische Phase. Wenn niedrigere Prioritätsdaten einen höheren Prioritätszeitstempel um mehr als die Schwelle T1 = 30 Minuten für Anlegen/Längsseits oder T2 = 120 Minuten für Annäherung/ETA übersteigen, behalten Sie beide Zeitstempel bei, kennzeichnen Sie die kanonische Phase als "verdächtig" und setzen Sie sourceConfidence = low. Wenn AIS Längsseits früher als TOS um <30 Minuten anzeigt, bevorzugen Sie TOS, aber zeichnen Sie AIS als unterstützende Beweise auf. Bei fehlenden höher priorisierten Daten fördern Sie die nächste verfügbare Quelle, zeichnen aber einen promotionReason und eine erwartete Genauigkeit (%) basierend auf dem Quelltyp auf.

Uhr- und Zeitzonensteuerung implementieren: Fordern Sie von allen Quellen die Übermittlung von Zeitstempeln in UTC an. Bei bekannten Uhr-Offsets wenden Sie quellenspezifische Offsets an, die aus historischen Vergleichen berechnet wurden (speichern Sie last-offset und stdev). Lehnen Sie Zeitstempel ab, die älter als 7 Tage für Ankunftsphasen sind, es sei denn, sie werden von einer signierten Hafenbehördenaufzeichnung begleitet. Wenden Sie eine automatische Korrektur von maximal 60 Minuten an; größere Korrekturen erfordern eine manuelle Überprüfung.

Empfohlenes kanonisches Ereignisschema (Beispiel felder): eventType, canonicalTimestampUTC, sourceType, sourceId, sourceConfidence (0-1), rawTimestamps [Listen], berthId, portUNLocode, vesselIMO, containerCount, affectedContainers [], phaseDurationMinutes. Verwenden Sie diese Felder, um KPI-Ergebnisse wie die Reduzierung der ETA-Varianz, frühere Kundenbenachrichtigungen und messbare Bewegungszeitreduzierungen pro Container zu erzielen.

Operative Anleitung für Anwender und Allianzen: Integrieren Sie diese Regeln in Spediteur- und Terminal-APIs, um konsistente Nachrichten über DCSA-ausgerichtete Endpunkte zu ermöglichen. Teilen Sie geförderte Regeln mit Verladern und Kunden, damit Systeme automatisierte Workflows erweitern und die Liegeplatzplanung optimieren können. Verfolgen Sie fünf Adoptionsmetriken: Prozentualer Anteil der Phasen mit autoritativer Quelle, durchschnittliche Beförderungsfrequenz, prozentualer Anteil verdächtiger Flags, die innerhalb von 24 Stunden behoben wurden, mittlere Abweichung zwischen kanonischer und Spediteur-ETA und Reduzierung von Früh-/Spätbenachrichtigungen. Die Digitalisierung dieser Mappings erhöht die Sichtbarkeit branchenweit, hilft bei der Optimierung von Containerbewegungen und bringt die Branche über fragmentierte Zeitstempel hinaus, sodass Spediteure, Terminals und Verlader frühere, zuverlässigere Sendungsinformationen neben Container-Level-Bestätigungen und Ergebnissen erhalten.

Container- und Spediteur-Identifikatoren vor der Erfassung validieren: Prüfziffern, Code-Listen und Ablehnungsbehandlung

Validieren Sie Container-Nummern und Spediteur-Codes am API-Gateway mithilfe der ISO 6346 Prüfziffer-Logik und maßgeblicher Code-Listen, bevor irgendeine nachgelagerte Erfassung erfolgt.

Genaues Containerformat und Prüfziffernprüfung
- Akzeptieren Sie nur ISO 6346-Einträge mit 11 Zeichen: Eigner-Code (3 Buchstaben) + Ausrüstungskategorie (1 Buchstabe, typischerweise U/J/Z) + Seriennummer (6 Ziffern) + Prüfziffer (1 Ziffer).
- Berechnen Sie die Prüfziffer: Ordnen Sie Buchstaben numerischen Werten zu (A=10, B=12, C=13 ... Z=38 mit Lücken bei 11, 22, 33), multiplizieren Sie jeden Zeichenwert mit 2^Position (Position 0 für das erste Zeichen), summieren Sie, nehmen Sie die Summe modulo 11; wenn der Rest 10 ist, setzen Sie die Prüfziffer = 0. Lehnen Sie sofort bei Abweichung ab.
- Lehnen Sie Einträge mit falscher Länge, nicht-ASCII-Buchstaben, führenden Nullen im Eigner-Code oder Seriennummern außerhalb von 000001–999999 ab; protokollieren Sie den genauen Fehlergrund und die Quelle (API-Aufruf-ID oder Tabellenzeile).
Spediteur-Code-Validierung und Code-Listen-Verwaltung
- Gleichen Sie Spediteur-Identifikatoren mit einem maßgeblichen Register ab (BIC für Eigner, SCAC für US-Betriebe oder Ihre vereinbarte Spediteurliste). Behandeln Sie unbekannte Codes als unter Quarantäne gestellt, bis sie gelöst sind.
- Implementieren Sie Echtzeit-Nachschlagevorgänge, wenn Internetzugang verfügbar ist; greifen Sie bei Offline-Betrieb auf einen signierten, zeitgestempelten gespeicherten Schnappschuss zurück. Erlauben Sie eine gespeicherte Gültigkeit für ein konfigurierbares Fenster (Standard 24–72 Stunden) und speichern Sie die Schnappschussversion in jedem Ereignis.
- Wenden Sie Mapping für Allianzen und Schiffsbetriebspartner an: Pflegen Sie eine kanonische Spediteur-zu-Betriebsspediteur-Tabelle, die von APMS und nachgelagerten Systemen verwendet wird; aktualisieren Sie das Mapping bei jeder Allianzänderung und erfassen Sie, wer die Überschreibung angewendet hat.
Prüfungen vor der Erfassung für Tabellen und Massenimporte
- Bieten Sie einen Client-seitigen Validator (Excel-Makro oder leichtgewichtiges JS), der Zeilen vor dem Upload kennzeichnet und eine CSV-Datei der abgelehnten Zeilen mit Fehlercodes zurückgibt; dies reduziert manuelle Korrekturen und beschleunigt die Digitalisierung von Alttabellen.
- Führen Sie für Massenimports einen schnellen Vorabscan durch, der gültige, Soft-Fail (unbekannter Spediteur) und Hard-Fail (Prüfziffer-Abweichung) Zeilen trennt. Nehmen Sie nur gültige Zeilen auf; geben Sie eine strukturierte Ablehnungsdatei zurück, die der Absender nach Korrekturen erneut hochladen kann.
Ablehnungsrichtlinie und Fehlerklassifizierung
1. Verwenden Sie standardisierte Fehlercodes, damit Integrationen automatisch handeln können:
  - ERR01 – FORMAT_INVALID (Länge/Zeichensatz)
  - ERR02 – CHECKDIGIT_MISMATCH
  - ERR03 – CARRIER_UNKNOWN
  - ERR04 – MAPPING_OVERRIDE_REQUIRED
2. Definieren Sie automatische Aktionen pro Code:
  - ERR02: Harte Ablehnung, Absender benachrichtigen, blockieren bis zur Korrektur.