P0 · Before the ramp

Transport Data
Preflight Engine

Sprawdź, czy przesyłka przejdzie cały cyfrowy workflow zanim kierowca pojawi się na rampie: właściwe dane, właściwa rola, właściwy etap, spójny czas i jawny kontrakt providera.

  • Role-aware
  • Lifecycle-aware
  • Provider-aware
EXECUTION MODELocal fixture · no provider connection
Pobierz fixture JSON ↓
Dane zostają w tej przeglądarce. Publiczny moduł nie wysyła fixture do eFTI Compliance ani providera.max 2 MB
CONTROLLED TRANSPORT RECORDSHP-2026-0917
transport_preflight_demo_v1
przykład obliczony przy otwarciu
CARRIER HANDOFF READINESS

handoff blocked

2 pola, które przewoźnik musi uzupełnić przed przekazaniem.

92%
stage fields22/24ramp fields2temporalreview requiredprovider fixture83%
PRE-SIGNATURE APPROVALproposed → reviewed jest dozwolone przez politykę fixture.
allowed
  1. draft
  2. 02proposed
  3. 03reviewed
  4. 04approved
  5. 05signed
  6. 06amended
Podgląd ocenia politykę przejścia. Nie zmienia stanu dokumentu i nie wykonuje podpisu.
ROLE / STAGE COMPLETENESSPola do uzupełnienia przed handoffem
vehicle.registration_numberNumer rejestracyjny pojazdusource: TMS
owner: carrieraktor może uzupełnić
vehicle.trailer_numberNumer naczepysource: TMS
owner: carrieraktor może uzupełnić
TEMPORAL CONSISTENCYŹródło → UTC → Europe/Warsaw
review required
Utworzenie przekazaniaTMS · 2026-09-08T00:30:00+02:00
UTC2026-09-07T22:30:00.000Z
LOCAL08.09.2026, 00:30:00
day shift
Początek okna odbioruWMS · 2026-09-08T08:00:00+02:00
UTC2026-09-08T06:00:00.000Z
LOCAL08.09.2026, 08:00:00
Planowany przyjazd przewoźnikaTMS · 2026-09-08T08:30:00+02:00
UTC2026-09-08T06:30:00.000Z
LOCAL08.09.2026, 08:30:00
Początek okna dostawyTMS · 2026-09-09T09:00:00+02:00
UTC2026-09-09T07:00:00.000Z
LOCAL09.09.2026, 09:00:00

handoff_created: dzień źródłowy 2026-09-08, dzień UTC 2026-09-07. Sprawdź reprezentację w dokumencie.

PROVIDER-SPECIFIC CONFORMANCEProvider Sandbox Profile A2026.09-demo · fixture_only
10/12fixture fields
blocked
EVIDENCE BOUNDARYFixture result ≠ provider acceptanceBez realnego API, zmiany workflow, podpisu i potwierdzenia zgodności eFTI.

Cztery bramki przed wysłaniem

Schema valid to za mało, jeśli błąd ujawni się dopiero przy pickupie.

Preflight wiąże pole z momentem procesu, odpowiedzialną rolą, prawem edycji i wymaganiem kontraktu. Reguły czasu są wersjonowanymi warunkami procesu, a nie ukrytą logiką interfejsu.

  1. 01Role / stage completeness

    field_owner, required_at_stage, required_by_role i wskazanie danych pozostawionych na rampę.

  2. 02Approval lifecycle

    draft → proposed → reviewed → approved → signed → amended z jawnymi przejściami i prawem edycji.

  3. 03Temporal consistency

    Offset ISO 8601, UTC i czas lokalny, kolejność zdarzeń oraz ostrzeżenie o przesunięciu dnia.

  4. 04Provider conformance

    Wersjonowany profil wejściowy i brakujące pola bez deklaracji produkcyjnej kompatybilności.

Dlaczego ten zakres

Problemy są już opisane w realnych backlogach eCMR.

Open Logistics Foundation opisuje zarówno brakujące pola pojazdu ukryte w widoku mobile i niedziałający przycisk podpisu, jak też potrzebę review przed pierwszym podpisem oraz niespójne konwersje dat do UTC. To uzasadnia preflight przed handoffem, nie budowę kolejnej aplikacji kierowcy.

Pozycja B2B2B

Warstwa dla TMS i providerów — nie własny eCMR.

TransFollow rozwija partnerstwo z IRU i integracje osadzone w istniejących TMS-ach. Nasz defensywny zakres to kontrola danych przed tymi workflow: mapping, reguły kraju, monitoring wersji, conformance tests i preflight.

Linki dokumentują kierunek rynku. Nie potwierdzają integracji ani partnerstwa tych firm z eFTI Compliance.

Pre-production integration testing

Przetestuj jeden prawdziwy handoff, zanim stanie się problemem kierowcy.

Zaczynamy od zanonimizowanego fixture, właścicieli pól, jednego etapu operacyjnego i profilu docelowego API. Produkcyjny zakres wymaga dostępu do sandboxa i właścicieli procesu.

Sprawdź zakres audytu