TMSshipment · status
Integracja eCMR · TMS / ERP / WMS
Integracja eCMR z TMS bez mnożenia interfejsów.
Jedno kontrolowane wejście danych. Osobne, wersjonowane adaptery do zweryfikowanych providerów. Ownership, mapping i testy zmian pozostają pod kontrolą Twojej organizacji.
- Provider-neutral
- Standards-aligned
- Evidence-first
Model docelowy · nie lista gotowych adapterówControlled integration path
Systemy źródłoweTM ER WM
ERPparty · order
WMSgoods · quantity
Warstwa kontroliINTERNALCanonical Transport Record
- field_owner
- source_system
- schema_version
- mapping_version
Osobne kontraktyA B EU
Provider Aadapter · tests
Provider Badapter · tests
Warstwa eFTIosobna weryfikacja
Wspólny rekord ogranicza duplikację po stronie TMS. Każdy interfejs zewnętrzny nadal wymaga dokumentacji, dostępu testowego i dowodów.
Sygnały rynku
Interoperacyjność stała się problemem operacyjnym.
To nie jest deklaracja popytu ani gotowej kompatybilności. To publiczne źródła, które definiują problem do zweryfikowania w pilocie.
Różne modele i mechanizmy
Rohlig SUUS wskazuje różnice modeli danych, uwierzytelniania, podpisywania i przekazywania dokumentów jako wyzwanie interoperacyjności.
Rzeczpospolita / Rohlig SUUSOtwarta interoperacyjność
IRU uruchomiła grupę techniczną z vendorami i organizacjami branżowymi, wskazując fragmentację rozwiązań eCMR i potrzebę otwartego podejścia B2B.
IRU · technical expert groupPełne stosowanie od 9 lipca 2027
Komisja Europejska podaje, że od tej daty organy mają przyjmować informacje udostępniane elektronicznie przez certyfikowane platformy eFTI.
Komisja Europejska · eFTIKiedy ma to sens
Jedna warstwa. Trzy częste punkty bólu.
Producent TMS lub ERP
Klienci oczekują połączeń z różnymi providerami, ale rdzeń produktu nie powinien kopiować ich modeli ani cykli wydawniczych.
Operator logistyczny lub 3PL
W jednym procesie uczestniczą strony używające różnych systemów, a niejasny owner pola potrafi szybciej propagować błędne dane.
Retailer lub producent
Wielu przewoźników i dostawców eCMR oznacza powtarzające się mappingi, autoryzacje i obsługę zmian w integracjach punkt-punkt.
Architektura
Najpierw kontrakt danych. Potem adapter.
Canonical Transport Model to wewnętrzna warstwa normalizacyjna — nie kolejny proprietary standard. Mapowanie powinno pozostać zgodne z aktualnymi wymaganiami i istniejącymi standardami.
- 01
Intake contract
Opisujemy formaty wejściowe, wymagane operacje i granice odpowiedzialności.
- 02
Ownership
Dla każdego pola zapisujemy ownera, źródło prawdy i regułę rozstrzygania konfliktu.
- 03
Normalizacja
Stabilny rekord wewnętrzny oddziela semantykę firmy od modeli poszczególnych providerów.
- 04
Adapter contract
Każdy provider dostaje osobny mapping, auth, lifecycle i jawnie wersjonowaną konfigurację.
- 05
Change control
Schema diff, testy kontraktowe i evidence pack pokazują, co zmieniło się przed wydaniem.
Punkt odniesieniaNie tworzymy zamkniętego standardu transportowego.
Wewnętrzny model służy normalizacji. Adaptery należy mapować do aktualnych specyfikacji providerów oraz odpowiednich standardów, m.in. publikowanych przez UN/CEFACT.
Zobacz standardy UN/CEFACTIntegration Readiness Audit
Decyzja o pilocie oparta na danych, nie na liście logo.
Wynikiem jest kontrolowany baseline integracji i zakres pilota z dwoma adapterami. Nie certyfikat ani obietnica produkcyjnej interoperacyjności.
Uruchom bezpłatny assessmentSystem & schema inventory
Formaty, API, pliki, zdarzenia i rzeczywiste miejsca powstawania danych.
Field ownership map
field_owner, source_system, konflikty i luki decyzyjne.
Provider requirements matrix
Porównanie wyłącznie wymagań potwierdzonych w źródłach i dokumentacji.
Version baseline
schema_version, mapping_version i kryteria breaking change.
Two-adapter pilot plan
Jeden rekord testowy, dwa adaptery, osobne testy i jawne kryteria wyniku.
FAQ
Najważniejsze granice integracji.
Technologia redukuje duplikację, ale nie usuwa różnic prawnych, procesowych ani kontraktowych.
Porównaj zakres eCMR i eFTICzy ta warstwa zastępuje dostawcę eCMR?
Nie. Porządkuje dane i kontrakty po stronie organizacji, a następnie przekazuje je przez osobny adapter do wybranego dostawcy. Obsługa dokumentu, podpisu i jego cyklu życia nadal zależy od zweryfikowanego rozwiązania eCMR.
Czy jedna integracja oznacza automatyczną obsługę każdego providera?
Nie. Każdy provider wymaga osobnego, wersjonowanego adaptera opartego na jego aktualnej dokumentacji, dostępie testowym i testach kontraktowych. Wspólne wejście ogranicza duplikację po stronie TMS, ale nie usuwa różnic zewnętrznych interfejsów.
Jakie materiały są potrzebne na start?
Wystarczy zanonimizowany eksport pól, OpenAPI, JSON Schema, próbka CSV lub opis źródeł w ERP, TMS i WMS. Nie należy wysyłać danych osobowych, sekretów API ani poufnych dokumentów w pierwszej wiadomości.
Czy eCMR i eFTI to ten sam zakres?
Nie. eCMR dotyczy elektronicznego listu przewozowego i procesu B2B, a eFTI reguluje elektroniczne udostępnianie wymaganych informacji właściwym organom przez certyfikowane platformy. Dane mogą się nakładać, ale wymagania i role trzeba weryfikować osobno.
Pierwszy krok
Zacznij od schematu, nie od wdrożenia.
Przeanalizuj zanonimizowany eksport lokalnie w przeglądarce albo wypełnij assessment i przygotuj zakres rozmowy dla właścicieli danych i integracji.
W pierwszej wiadomości nie wysyłaj danych osobowych, sekretów API ani poufnych plików.