NETZWERK · LOGISTIKPORTAL
Ihr Spediteur informiert Sie per E-Mail. Das Dispatch-Team trägt Meilensteine in eine gemeinsame Tabelle ein, die irgendjemand ständig vergisst zu aktualisieren. Zollabfertigungstermine kommen als PDF-Screenshots. Rate Cards liegen in einem SharePoint-Ordner. Wenn der Container sich verzögert, erfahren Sie es vom Importeur, der nachfragt warum. Ihr „Sendungsdatensatz" ist eine Fiktion, zusammengestückelt aus drei Postfächern und einem WhatsApp-Chat.
Das Logistikportal in TradeOS ist ein gebrandetes Cockpit, in dem Ihre Spediteure, Zollmakler und Carrier direkt arbeiten — gleiche Datenbank, auf das beschränkt, was sie sehen müssen. Strukturierte Inbox ersetzt Ad-hoc-E-Mails. Echte Meilensteine landen auf echten State Machines. Zoll, Dispatch, Rechnungsstellung und Kommunikation — alles auf einem Datensatz. Multi-Tenant-Identität: ein Login, viele Operator-Workspaces, jeder einzeln isoliert. Kostenlos für den Anbieter. Kein TMS-Ersatz.
Portalbereiche
7 · Inbox, Sendungen, Dispatch, Invoices und 3 weitere
Logistikmodi
See, Luft, Lkw, Schiene, Express und 3 weitere
Multi-Tenant-Identität
Ein Login, viele Operator-Workspaces
Kosten für den Spediteur
$0 · Operator zahlt für TradeOS
Das eigentliche Start-Dashboard — Begrüßungsleiste, Weltkarten-Widget mit aktiven Sendungen an ihren Positionen, zweispaltige Aktionswarteschlange. Ein einzelner Backend-Aufruf (GET /portal/logistics/home) liefert alles zurück. Das Operator-Brand-Chrome (Logo, Farbe, Arbeitsbereich-Bezeichnung) wird aus den Tenant-Einstellungen des Operators gerendert.
DER MEILENSTEIN, DER NIE AKTUALISIERT WIRD
Der Spediteur ist kompetent. Der Zollmakler ist schnell. Die Tracking-Seite des Carriers existiert. All das hilft nicht, wenn das System of Record für eine einzige Sendung auf drei Posteingänge, zwei Tabellen, einen SharePoint-Ordner und eine WhatsApp-Gruppe verteilt ist, in der niemand dieselbe Zeitzone hat.
01 · MEILENSTEINE LEBEN IN EINER GETEILTEN TABELLE
Ihr Spediteur aktualisiert ein Google Sheet in einem anderen Rhythmus als der Importeur, der Sie unter Druck setzt. Das Operations-Team hat zwei Quellen der Wahrheit – die Tabelle und die Tracking-Seite des Carriers – und sie weichen um drei Tage voneinander ab. Bis Sie die Antwort herausziehen, hat der Container die Zollabfertigung passiert, ohne dass es jemand bemerkt hat.
02 · ZOLLAKTUALISIERUNGEN LEBEN IN E-MAIL-THREADS
Der Zollmakler ist schnell, aber sein Kanal ist der Posteingang, der gerade offen war. Die Freigabebenachrichtigung kommt als PDF-Anhang. Sie leiten sie an die Buchhaltung weiter, die die Eintrags-Nummer nicht findet, weil sie im Screenshot steckt. Die Sendung geht drei Tage zu spät raus, weil niemand wusste, dass sie freigegeben war.
03 · EIN SPEDITEUR, FÜNFZEHN PORTALE
Sie richten „Ihr” Portal ein und bitten Ihren Spediteur, sich anzumelden und Meilensteine zu aktualisieren. Er hat eines für jeden Kunden. Keines davon prüft er konsequent. Ihre Daten veralten in dem Moment, in dem er den Browser-Tab schließt. Das Portal wird zu einem System, das der Spediteur als lästige Pflicht behandelt – bis es nicht mehr funktioniert.
7 BEREICHE · EIN PORTAL
Echter LOGISTICS_NAV.flatLinks aus client/src/lib/navConfig.ts. Die mobile Bottom-Nav verwendet die ersten vier: Start · Inbox · Sendungen · Dispatch.
Begrüßungsleiste + Weltkarte mit aktiven Sendungen + 2-spaltige Aktionswarteschlange (Needs Response, At Risk, Today, Money). Ein einziger Backend-Aufruf liefert alle Daten.
Die strukturierte Antwort-Warteschlange. 3 Unter-Tabs (Buchungen, RFQs, Disputes), jeweils mit den Abschnitten „Needs Action”, „Awaiting Response” und „Recently Decided”. Nicht beantwortete Gegenangebote werden nach 48 h automatisch hochgestuft.
5 Tabs — Tracking, Container, Kosten, Zoll, Verlauf. Ein einziger Backend-Aufruf (/shipments/overview/all) liefert alle Daten; die Tabs sind Projektionen.
11-Zustands-Automat für den Landtransport. assigned → accepted_by_driver → en_route_to_pickup → arrived → loaded → departed → en_route_to_delivery → arrived → unloaded → completed (+ Fehlerzweig). Abschluss ist POD-gesperrt.
Preislisten mit gültig-ab / gültig-bis / Version / abgelöst-durch. Positionsbezogene Zuschläge, Mengenstaffeln, Mindestentgelt. Massenimport von 1–500 Positionen atomar.
11-Zustands-Automat. 3 Typen: pro Sendung, monatlich konsolidiert, ad hoc. Dispute-Zweig mit Lösungsnachverfolgung.
Thread-basiertes Messaging, begrenzt auf die jeweilige Operatorverbindung. Verknüpft mit einer Entität (Buchung, RFQ, Sendung, Rechnung). Benachrichtigungen über dieselbe Infrastruktur wie die übrigen Portale.
DER POSTEINGANG · 1.252 ZEILEN UI
Drei Workflow-Typen teilen sich eine Queue, denn aus Sicht des Spediteurs gilt für alle dasselbe: „strukturierte Antwort, zeitkritisch, ich bin der Engpass” – Buchungsanfragen, Angebotsanfragen und Rechnungsreklamationen. Die Inbox-Oberfläche bündelt sie in einer Queue mit inline Aktionsformularen, sodass der Standardpfad ohne Navigation auskommt.
5 Angebote eingereicht · Operator-Entscheidung ausstehend · ältestes 18h
2 Angebote gewonnen · 1 Angebot verloren · zum Anzeigen aufklappen
SENDUNGEN · 5 TABS · EIN BACKEND-AUFRUF
Die primäre Arbeitsoberfläche des Spediteurs. GET /portal/logistics/shipments/overview/all liefert alles in einem Aufruf; die Seite hält die Daten im Speicher und projiziert sie je Tab. Kein Fan-out vom Browser, kein tab-spezifisches Nachladen.
Weltkarte + Liste mit Status, Route, letztem Meilenstein und offenen Ausnahmen. Klick auf eine Zeile → inline-Erweiterung mit vollständiger Meilenstein-Chronologie und offenen Ausnahmen für diese Sendung.
Jeder Container jeder Sendung – mit Typ, Auslastung (CBM / Gewicht vs. Container-Maximum), Plombennummer und Ladedatum. Die Ansicht „was ist wo geladen”.
Erlöse je Sendung aus Rechnungen, bezahlter Betrag, Ausstände. Aggregierte Summen oben. Aus jeder Zeile in das Rechnungsdetail navigieren.
Zollanmeldungen je Sendung: Jurisdiktion (ISO 3166), Anmeldungstyp (Import/Export/Transit), Status (7-stufige Zustandsmaschine), Anmeldungsnummer, angemeldete HS-Codes. Aggregierte Werte für „Abgefertigt / Ausstehend / Zurückgehalten” oben.
Chronologisch zusammengeführte Ereignisse, Meilensteine und Ausnahmen über alle Sendungen dieses Spediteurs. Zeitlich geordneter Feed. Die Audit-Log-Oberfläche.
ZUSTANDSAUTOMATEN · IN DB ERZWUNGEN
Jeder Workflow verfügt über eine explizite State Machine — Postgres-Enum-Typen oder CHECK-Constraints. Übergangsregeln auf Service-Ebene validieren, welche Zustände in welche übergehen können. Keine Magic Strings, keine UI-seitigen Zustände.
BUCHUNG · 6 ZUSTÄNDE
Terminale Alternativen: abgelehnt · storniert · abgelaufen. Die Annahme erstellt die verknüpfte Sendung.
ANGEBOTSANFRAGE · 7 ZUSTÄNDE
Verzweigungen: verloren · Angebot abgelehnt · abgelaufen · zurückgezogen. Das Backend erzwingt ein einzelnes offenes Angebot pro RFQ.
DISPOSITION · 11 ZUSTÄNDE
Aus jedem aktiven Status ist ein Übergang zu failed mit Angabe eines Grunds möglich. Der Abschluss setzt voraus, dass der POD zuvor erfasst wurde (im UI per Tooltip gesperrt).
RECHNUNG · 10 ZUSTÄNDE
Verzweigungen: überfällig · strittig · ausgebucht. Drei Rechnungstypen: pro Sendung · monatlich konsolidiert · ad hoc.
ZOLLANMELDUNG · 7 ZUSTÄNDE
Verzweigungen: zurückgehalten (Dokumente / Zahlung / Inspektion ausstehend) · angefragt (Zoll hat eine Rückfrage gestellt) · abgelehnt (terminal). Je Rechtsgebiet × Deklarationstyp.
AUSNAHMEN · 3+3 ENUM
Schweregrad × Status. Der Status durchläuft offen → in Bearbeitung → behoben. Getrennt von Meilensteinen — deklariert, Maßnahmen nachverfolgt, Lösung auditiert.
8 LOGISTIKMODI · MODUSSPEZIFISCHE MEILENSTEINVORLAGEN
Der logistics_mode-Enum hat acht Werte, jeder mit einer eigenen modusbasierten Meilenstein-Vorlage (serverseitig validiert, nicht über DB-Enum, sodass neue Meilensteine ohne ALTER TYPE hinzugefügt werden können).
EIN SPEDITEUR · VIELE BETREIBER
Ein Spediteur, der Pendrew Energy, AcmeCorp, BioMed Global und sieben weitere Kunden betreut, erhält eine Benutzerzeile, einen Login und zehn Betreiber-Workspaces über die external_memberships-Tabelle (Migration 121). Wechsel per Klick. Buchungen, Preisblätter, Meilensteine, Rechnungen und Kommunikation jedes Betreibers sind durch connection_id isoliert — es gibt keinen API-Pfad, über den Daten zwischen Betreibern ausgespielt werden.
Ihre Carrier-API-Zugangsdaten liegen auf Ebene der external_organization (Migration 289) — einmalig eingerichtet, über das KMS-Plugin verschlüsselt und in jedem Betreiber-Arbeitsbereich wiederverwendet.
VERTRAULICHKEIT · ARCHITEKTUR
Architektur, kein Handschlag. Echtes redactFor(entity, row, viewerRole) in server/src/modules/portal-shell/redaction.ts — dasselbe Muster wie bei den Lieferanten- und Kundenportalen.
VERBINDUNGSSPEZIFISCHER SCOPE
Es gibt keinen Pfad durch die Logistics-Portal API, der über Betreiber hinweg auffächert. Betreiberübergreifende Zugriffe liefern 404 (nicht 403), sodass die Existenz der Ressource verborgen bleibt — verifiziert in der Projektionstest-Suite (portal-logistics/__tests__/projector.test.ts).
FELDBASIERTE SCHWÄRZUNG
Einkaufspreis, Verkaufspreis, Marge, Kostenbasis — vor dem Verlassen der Datenbank entfernt. Echte redactShipmentForClient- und redactFor('shipment', raw, 'logistics')-Funktionen erzwingen dies. Ausnahme ist das BOL: gesetzlich vorgeschriebene Empfängerdaten erscheinen im BOL-Dokument, gesteuert durch Incoterm-basierte Sichtbarkeit (nächster Abschnitt).
RATEN-PRIVATSPHÄRE
Ratenblätter sind pro logistics_connection_id beschränkt. Der betreiberseitige Raten-Marktplatz dient dem Vergleich zwischen Anbietern (Solo+-Feature), nicht umgekehrt — Spediteure können nicht ermitteln, „wer sonst noch bessere Konditionen erhält als ich.” RFQ-Ergebnisse (gewonnen / verloren) werden dem Spediteur selbst angezeigt, aber nie über Spediteure hinweg aggregiert.
INCOTERMS · SICHTBARKEITSKONFIGURATION
Die visibility_config JSON der Verbindung (Migration 122, Spalte; Schema-Dokumentation in 291) legt die Sichtbarkeit pro Incoterm für Ursprung und Ziel fest — Land / Hafen / Stadt / factory_name / factory_address / full_address. Zusätzlich sind Overrides pro Incoterm sowie Label-Overrides möglich.
DDP · CIF · CFR
Die Identität des Herstellers wird auf den Versanddokumenten abstrahiert. Der Spediteur sieht die Adresse des Operators als Ursprung; die Tenant-Einstellungen des Operators steuern das BOL-Absenderfeld. Der Herstellername wird dem Spediteur nur dann angezeigt, wenn dies explizit überschrieben wurde.
FOB · EXW · FCA
Der Hersteller ist aus rechtlichen Gründen der rechtliche Versender im BOL. Herstellername und Abholadresse sind für den Spediteur sichtbar; die visibility_config kann dennoch einschränken, was der nachgelagerte Kunde des Operators sieht (die Schwärzung im Client-Portal gilt separat).
FAHRER · PWA
Fahrer installieren das Logistikportal auf ihrem Startbildschirm — manifest.webmanifest + Service Worker — melden sich einmalig an und erhalten die Disponierungswarteschlange, gefiltert auf Aufträge, bei denen sie als zugewiesener Fahrer eingetragen sind. Keine Tarife, keine Rechnungen, keine anderen Sendungen. Meilensteine erfassen GPS-Koordinaten (Breiten- und Längengrad) sowie Foto-Uploads; POD erfordert Unterschrift, Name und Titel des Unterzeichners, bevor der Übergang zu completed zugelassen wird.
Pro Ereignis werden sechs Meilenstein-Quellwerte erfasst: user (manuelle Eingabe durch Ops), driver (mobile Erfassung), carrier_api, ocr, scheduled_auto_advance, operator_override. Die Meilenstein-Tabelle ist append-only — UPDATE wird per Trigger abgewiesen; Korrekturen fügen neue Zeilen mit supersedes_milestone_id ein, das auf den ursprünglichen Eintrag verweist.
Geofence-gesteuerte Auto-Übergänge, eine OCR-Pipeline für den BOL-Upload sowie native iOS- und Android-Apps sind im Fahrplan vorgesehen — der Meilenstein-Quell-Enum reserviert ihre Plätze bereits.
STUFENZUGANG · 15 FUNKTIONSSCHLÜSSEL
Das echte tier_features-Register (Migration 291) definiert fünfzehn Logistics-Portal-Feature-Gates. Logistikanbieter sehen keine Zahlungsschranke; der Tier des verbindenden Betreibers entscheidet, was in Ihrem Arbeitsbereich für diesen Betreiber verfügbar ist.[Fahrplan] Tags kennzeichnen Funktionen, deren tier_feature-Schlüssel existiert, deren Implementierung jedoch nach dem Launch erfolgt.
Fahrplan = tier_features-Schlüssel, registriert in Migration 291 (siehe db/migrations/291_logistics_tier_features_and_visibility_overrides.sql); Engine-, Aggregations- und UI-Implementierung erfolgt nach dem Launch gemäß Logistics Spec §19, §14, §25.
AUF DEM FAHRPLAN
v1 liefert sieben Bereiche, sechs State Machines, ein append-only Meilenstein-Log, Multi-Tenant-Identität, feldgenaue Schwärzung, Incoterm-gesteuerte Sichtbarkeit und Tier-Gating über fünfzehn Feature-Keys. Mehrere Funktionen, die das Marketing-Team gern bereits beanspruchen würde, sind hier ehrlich als Fahrplan gekennzeichnet.
01
Migration 290 liefert das Tabellenschema consolidation_groups. Der Suggestion-Engine, der diese Tabelle befüllt, läuft als Hintergrundprozess nach dem Launch; die v1-Oberfläche zeigt noch nichts an. Tier-Feature-Key logistics.ai_consolidation_suggestions für Business+ registriert.
02
Tier-Feature-Keys logistics.cross_tenant_insights und logistics.network_reputation_display für Business+ registriert. Aggregations-Engine und Anti-Inference-Schwellenwert ab ≥3 Operatoren werden nach dem Launch bereitgestellt.
03
Die operatorübergreifende Konsolidierung erfordert Einwilligungsmechanismen, die noch nicht spezifiziert sind. Migration 290 schiebt dies explizit auf — „intentionally NOT modelled here.” Tier-Feature-Key reserviert.
04
Der Milestone-Source-Enum-Wert 'ocr' ist registriert; der OCR-Dienst, der ein BOL-Bild einliest, Container-/Schiffs-/Siegel-/Voyage-Felder extrahiert und den entsprechenden Milestone übermittelt, wird nach dem Launch bereitgestellt.
05
Dispatch-Zustandsübergänge bei Geofence-Eintritt/-Austritt (arrived_at_pickup, arrived_at_delivery) — derzeit nicht implementiert. v1 erfasst GPS zum Zeitpunkt, an dem der Fahrer den Milestone bestätigt; die automatische Weiterschaltung per Geofence folgt später.
06
v1-Integrationsverzeichnis: project44 (live), Freightos Baltic / Xeneta / Drewry / MarineTraffic / Vizion (Frachtrate + AIS-Sichtbarkeit). Direktintegrationen mit Maersk / MSC / CMA CGM / ONE / HMM / Hapag-Lloyd, IATA Cargo IQ für Luftfracht sowie FedEx / UPS / DHL / USPS für Expressland werden schrittweise angebunden. logistics_carrier_api_credentials.carrier_name ist ein freies TEXT-Feld, sodass das Hinzufügen eines Carriers keine Schema-Änderungen erfordert.
07
Die PWA ist die v1-Fahrerschnittstelle (Manifest + Service Worker live in client/public/). Native Apps mit biometrischer Authentifizierung, nativen Kamera-APIs und Push-Benachrichtigungen folgen nach dem Launch.
08
Die Tabelle logistics_carrier_api_credentials enthält eine Spalte last_polled_at. Der geplante Job, der jeden verbundenen Carrier gemäß seiner Kadenz abfragt (täglich für Ocean, stündlich bei kritischen Luftfrachtabschnitten, alle 12 Stunden für Rail), wird nach dem Launch bereitgestellt.
FAQ
Nein. Wir stehen nicht im Wettbewerb mit CargoWise, Magaya, Descartes oder Project44. Wir sind die Koordinationsschicht zwischen Ihrem TMS und dem Operator, der Sie beauftragt hat. Nutzen Sie Ihr TMS weiterhin für interne Abläufe; verwenden Sie das Logistikportal für den operatorseitigen Workflow, der außerhalb davon liegt — Buchungen, die der Operator initiiert, Meilenstein-Transparenz, die der Operator benötigt, Zollanmeldungen gegen die Sendungen des Operators, Preislisten und RFQs, die der Operator abfragt, und Frachtrechungen, die der Operator bezahlt. TMS-Integration für Operatoren mit CargoWise / Magaya / Descartes ist im Enterprise-Tier verfügbar.
Senden Sie eine CSV mit Ihren wichtigsten Spediteuren und einer offenen Sendung. Wir richten ein Sandbox-Logistics-Portal mit dem Branding Ihres Tenants ein, Ihre Spediteuliste als external_organizations, und führen einen echten Spediteur durch das Annehmen eines RFQ, das Setzen von Meilensteinen, die Zollanmeldung und die Rechnungsstellung. Keine Demo-Daten. Ihre Spediteure, Ihre Sendung.
Demo buchenMit dem Vertrieb sprechen
Das vollständige Netzwerk ansehen — 4 Portals, ein Datensatz →