Jakiś czas temu postawiłem sobie za cel znalezienie ujednoliconego standardu API/EDI dla transportu, który byłby używany przez kilka firm logistycznych. Z pewnością w dzisiejszych czasach coś takiego musi istnieć, prawda? Uniwersalny format API do wysyłek?

Cóż, krótko mówiąc, nie istnieje.

Najbliżej tego jest dostawca API, który zbudował wiele połączeń API z przewoźnikami, a następnie oferuje własny punkt końcowy API do dostępu do różnych dostawców usług transportowych.

W tym artykule omówię kilka różnych API przewoźników, krótko opiszę ich możliwości i omówię sposoby ich implementacji.

Uwaga! Jeśli szukasz uniwersalnego protokołu API dla transportu, oto link, gdzie możesz umówić się na szybką rozmowę ze mną.

W każdym razie, zacznijmy od...

Najpierw zdefiniujmy cel.

Weźmy pod uwagę przeciętnego producenta z klientami i dostawcami zarówno krajowymi, jak i międzynarodowymi. Towary muszą być odbierane od dostawców i dostarczane do zakładu produkcyjnego, podczas gdy gotowe produkty muszą być wysyłane do klientów.

Aby ustanowić niezawodny łańcuch dostaw, typowy średniej wielkości producent potrzebowałby 10-20 partnerów transportowych:

Zarządzanie wszystkimi tymi relacjami jest wystarczająco skomplikowane. Ale prawdziwa zabawa zaczyna się, gdy próbujesz zintegrować ich systemy informatyczne! (ponieważ nie ma ujednoliconego protokołu API dla frachtu)

Po drugie, musimy uzgodnić zakres.

Nie wszystkie firmy logistyczne oferują ten sam poziom usług. Niektóre mają bardzo zaawansowane API zapewniające natychmiastową wycenę frachtu, rezerwację, etykiety, śledzenie, żądania kuriera itp., podczas gdy inne mogą mieć tylko portal, gdzie można się zalogować i złożyć rezerwację. Niektóre w ogóle nie mają systemów informatycznych - tylko e-mail. W naszym scenariuszu docelowym uprośćmy sprawy i dążmy tylko do:

Brzmi wystarczająco prosto, prawda? Och, gdyby tylko...

Ręczny sposób obsługi, który wydaje się być standardem branżowym dla większości firm, obejmuje korzystanie z portali przewoźników tam, gdzie to możliwe, i komunikację za pośrednictwem poczty elektronicznej z pozostałymi partnerami transportowymi. W naszym przykładzie zakładamy, że cenniki transportowe, harmonogramy, czasy realizacji i obsługa faktur są zarządzane oddzielnie. W przypadku składania rezerwacji dążymy do zbudowania połączenia API z naszego systemu ERP.

Załóżmy, że wybraliśmy następującą listę firm transportowych i musimy zbudować bezpośrednie połączenie API z ich systemami z naszego oprogramowania ERP. Ten wybór jest losowy i obejmuje tylko ułamek różnych API przewoźników dostępnych na rynku.

DHL Express – korzysta z portalu o nazwie MyDHL, który ma również możliwości API. Jednak używa różnych API dla oddziałów Freight, Express i Global Forwarding oraz różnych podejść do API w różnych regionach. Dostęp do usługi internetowej wymaga protokołu SOAP, usług RESTful lub zwykłego XML, a programiści powinni znać XML/JSON i mieć podstawową wiedzę o usługach internetowych. Sama specyfikacja API liczy 457 stron. Jest dokładna, ale twój programista naliczy ci za godziny spędzone na samym jej czytaniu. Po wdrożeniu trzeba by uruchomić średnio 5-12 zapytań na przesyłkę, zaczynając od uwierzytelnienia, przez walidację adresów, sprawdzanie dostępności, aż po żądania etykiet.

Schenker – używa różnych rozwiązań API/EDI w różnych regionach. Najczęściej wykorzystuje protokół SOAP z formatem XML. Sama wiadomość jest prosta, pod warunkiem, że wszystkie możliwe błędy są odpowiednio obsługiwane. Programiści potrzebują spersonalizowanego dostępu do implementacji API. W zależności od lokalizacji, możesz zostać poproszony o wdrożenie rozwiązania EDIFACT, które omówię później.

DSV – niedawno przeszedł na swój portal z możliwościami API o nazwie MyDSV. Biorąc pod uwagę, że API jest dość nowe, korzysta z niektórych najnowszych i najbardziej nowoczesnych podejść w świecie API. Mimo złożoności podczas uwierzytelniania i nawigacji po ich katalogu produktów, podejście jest proste. Ponownie, w zależności od lokalizacji, EDIFACT może być preferowany.

FedEx i TNT – to może być zabawne. Najpierw musisz ustalić, czy korzystasz z usług TNT czy FedEx. Chociaż powinny być tą samą firmą od kilku lat, migracja jest nadal w toku. Jeśli twoja umowa jest z TNT, najprawdopodobniej zostaniesz poproszony o wdrożenie API TNT Express Connect. Sama implementacja jest średnio skomplikowana. Minusem jest to, że to API jest uważane za przestarzałe i ostatecznie zostanie wyłączone. Z drugiej strony, API FedEx jest bardziej złożone i oferuje kilka opcji w zależności od regionu, w którym się znajdujesz. W Cargoson wdrożyliśmy FedEx Compatible API, które zapewnia bardzo przydatne dodatkowe funkcje, ale jest dostępne tylko dla partnerów kompatybilnych z FedEx.

UPS – używa API opartego na JSON i OAuth do uwierzytelniania, co oznacza, że musisz uruchomić dość sporo zapytań, zanim przeprowadzisz rezerwację i otrzymasz etykiety zwrotne.

Następnie mamy EDIFACT, używany przez wiele firm transportowych, takich jak DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics itp. Jest to bardzo stary standard i nawet jeśli może się wydawać, że można by uniknąć jednej integracji API dla kilku firm logistycznych, pomyśl jeszcze raz. Największą wadą jest to, że jest to połączenie oparte na wymianie plików, co oznacza, że musisz wygenerować rzeczywisty, fizyczny plik, następnie przesłać go przez FTP i dosłownie mieć nadzieję, że wszystko jest w porządku, ponieważ informacje zwrotne o błędach i ostrzeżeniach są bardzo uciążliwe.

Podobny do EDIFACT jest FORTRAS, połączenie oparte na plikach z tymi samymi wadami. Jest bardziej używany w Niemczech i sąsiednich krajach. Nie tylko wymiana plików jest trudna, ale sam format pliku jest trudny do odczytania i dlatego bardzo czasochłonne jest debugowanie błędów. Niektóre znane firmy, które go używają, to Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss itp.

Nawet po wdrożeniu wszystkich wyżej wymienionych integracji, pozostaje pytanie:

Co zrobić z firmami przewozowymi, które nie mają żadnego systemu informatycznego ani portalu, nie mówiąc już o API do przyjmowania zleceń transportowych?

Najprostszym rozwiązaniem jest wysłanie prostego e-maila. Chociaż może to brzmieć prosto, zagłębmy się głębiej. Skonfigurowanie technicznego połączenia z serwerem pocztowym to jedno, ale co z kontaktami? Normalnie różne kierunki są obsługiwane przez różne osoby kontaktowe, a ludzie zmieniają stanowiska. Dlatego musisz zbudować dość kompleksową matrycę kontaktów w swoim ERP.

Jakie są zatem alternatywy dla zmagania się z różnorodnymi API przewoźników i protokołami EDI?

Jedną z opcji do rozważenia jest API dla wielu przewoźników. W zasadzie jest to dostawca usług, który zbudował wszystkie połączenia z przewoźnikami, czy to nowoczesne API, stare protokoły EDI oparte na EDIFACT lub FORTRAS, czy integracje e-mailowe, i udostępnił je za pośrednictwem własnego, znormalizowanego API do wysyłek. Zamiast implementować różne API przewoźników i utrzymywać je na bieżąco, możesz zaimplementować tylko jeden standard API dla wielu przewoźników i uruchamiać wszystkie swoje zlecenia transportowe za jego pośrednictwem.

Ale poszliśmy jeszcze dalej.

Różne firmy logistyczne oferują różne poziomy usług. Niektóre zapewniają API do rezerwacji, podczas gdy inne nie; niektóre oferują możliwości śledzenia, podczas gdy inne nie mają tej funkcji. W Cargoson wdrożyliśmy wszystkie funkcje, które wypełniają luki dla każdej firmy transportowej.

Na przykład, gdy przewoźnik nie oferuje rezerwacji online, zapewniamy portal do tego. Jeśli brakuje im śledzenia, dodajemy je. Mamy systemy do przesyłania potwierdzenia dostawy (POD) i innych dokumentów, w pełni funkcjonalne API dla wielu przewoźników, szacunki ETA, kalkulacje cen transportu, statystyki wydajności, a nawet dane dotyczące emisji CO2 w transporcie. Zasadniczo, cokolwiek czego brakuje przewoźnikowi, zbudowaliśmy to, abyś nie musiał martwić się o różnice w poziomie IT lub usług między swoimi przewoźnikami.

Zobacz, jak Cargoson ulepsza twoich obecnych przewoźników

Oto przykład z życia: Duzi gracze, tacy jak FedEx, TNT i DHL Express, oferują API do wyceny. Oznacza to, że gdy uruchamiasz zapytanie o cenę z Cargoson, ceny są pobierane bezpośrednio z systemu przewoźnika. Jednak w przypadkach, gdy firma taka jak DSV nie zapewnia API do wyceny, arkusz Excel lub cennik PDF dostarczony przez DSV jest przesyłany do Cargoson, a kalkulacja ceny jest wykonywana w naszym systemie. Mamy do tego potężny silnik do przesyłania i obliczania cen frachtu. To samo podejście można zastosować do wszystkich innych firm transportowych i ma ono również zastosowanie do innych funkcji.

Nasz cel jest prosty: zapewnić ci spójne, wysokiej jakości doświadczenie w pracy ze wszystkimi przewoźnikami, nawet jeśli nie wszyscy zaczynają z tymi samymi możliwościami. De facto uniwersalny standard API dla przewoźników i platforma dla wielu przewoźników w jednym.

Jeśli szukasz lepszego sposobu zarządzania swoimi integracjami z przewoźnikami, Cargoson może pomóc. Nasza platforma zapewnia pojedyncze, znormalizowane API transportowe, które łączy cię ze wszystkimi twoimi przewoźnikami, niezależnie od ich indywidualnych możliwości. Oznacza to, że możesz uzyskać dostęp do wszystkich swoich usług wysyłkowych za pośrednictwem jednego ujednoliconego interfejsu, nie martwiąc się o podstawowe różnice techniczne.

Chcesz zobaczyć, jak to mogłoby działać w twojej firmie? Umówmy się na szybką rozmowę, aby omówić twoją obecną konfigurację i konkretne wyzwania integracyjne. Możemy przejrzeć kilka przykładów z życia wziętych, jak Cargoson pomógł firmom w podobnych przypadkach do twojego:

Zaplanuj bezpłatną, 30-minutową konsultację