Преди известно време си поставих за цел да разбера дали съществува унифициран транспортен API/EDI стандарт, който се използва от няколко логистични компании. Със сигурност в днешно време трябва да съществува нещо подобно, нали? Универсален API формат за доставки?

Е, накратко, такъв не съществува.

Най-близкото, до което можете да стигнете, е някой доставчик на API, който е изградил множество API връзки с превозвачи и след това предлага собствена API крайна точка за достъп до различни доставчици на транспортни услуги.

В тази статия ще разгледам няколко различни API на превозвачи, накратко ще опиша техните възможности и ще обсъдя начините за тяхното внедряване.

Забележка! Ако просто търсите универсален транспортен API протокол, ето връзка, където можете да запишете бърз разговор с мен.

Така или иначе, нека започнем с...

Първо, нека дефинираме целта.

Представете си среден производител с местни и международни клиенти и доставчици. Стоките трябва да бъдат взети от доставчиците и доставени до производствения обект, докато крайните продукти трябва да бъдат изпратени до клиентите.

За да установи надеждна верига на доставки, типичният производител със среден размер би се нуждаел от 10-20 транспортни партньора:

Управлението на всички тези взаимоотношения е достатъчно сложно. Но истинското забавление започва, когато се опитате да интегрирате техните ИТ системи! (тъй като няма унифициран API протокол за товари)

Второ, трябва да се споразумеем за обхвата.

Не всички логистични компании предлагат едно и също ниво на обслужване. Някои имат много сложни API, предоставящи моментално ценообразуване на товари, резервации, етикети, проследяване, заявки за куриер и т.н., докато други може да имат само портал, в който можете да влезете и да подадете резервация. Някои изобщо нямат ИТ системи - само имейл. За нашия целеви сценарий, нека да опростим нещата и просто да се стремим към:

Звучи достатъчно просто, нали? О, ако само беше така...

Ръчният начин за обработка на нещата, който изглежда е индустриален стандарт за повечето компании, включва използването на портали на превозвачи, където е възможно, и комуникация чрез имейл с останалите транспортни партньори. В нашия пример приемаме, че ценовите листи за транспорт, графиците, сроковете за доставка и обработката на фактурите се управляват отделно. За подаване на резервации целим да изградим API връзка от нашата ERP система.

Нека приемем, че сме избрали следния списък с транспортни компании и трябва да изградим директна API връзка към техните системи от нашия ERP софтуер. Този избор е произволен и обхваща само част от различните API на превозвачи, които съществуват.

DHL Express – използва портал, наречен MyDHL, който също има API възможности. Въпреки това, той използва различни API за клоновете Freight, Express и Global Forwarding, както и различни API подходи в различните региони. Достъпът до уеб услугата изисква SOAP протокол, RESTful услуги или обикновен XML, а разработчиците трябва да са запознати с XML/JSON и да имат основно разбиране за уеб услуги. Само API спецификацията е дълга 457 страници. Тя е задълбочена, но вашият разработчик ще ви таксува за часовете, прекарани само в четенето й. След внедряването ще трябва да задействате средно 5-12 заявки за пратка, започвайки от удостоверяване до валидиране на адреси, проверки за наличност и заявки за етикети.

Schenker – използва различни API/EDI решения в различните региони. Най-често използва SOAP протокол с XML формат. Самото съобщение е просто, при условие че всички възможни грешки са обработени правилно. Разработчиците се нуждаят от персонализиран достъп за внедряване на API. В зависимост от вашето местоположение, може да бъдете помолени да внедрите EDIFACT решение вместо това, което ще разгледам по-късно.

DSV – наскоро премина към своя портал с API възможности, наречен MyDSV. Като се има предвид, че API е доста ново, то се възползва от някои от най-новите и най-модерни подходи в света на API. Въпреки сложността при удостоверяване и навигиране в техния продуктов каталог, подходът е прост. Отново, в зависимост от вашето местоположение, може да се предпочита EDIFACT.

FedEx и TNT – това може да бъде забавно. Първо, трябва да определите дали използвате услугите на TNT или FedEx. Въпреки че би трябвало да са една и съща компания от доста години, миграцията все още предстои. Ако договорът ви е с TNT, най-вероятно ще бъдете помолени да внедрите TNT Express Connect API. Самото внедряване е със средна сложност. Недостатъкът е, че това API се счита за остаряло и в крайна сметка ще бъде спряно. От друга страна, FedEx API е по-сложно и предлага няколко опции в зависимост от региона, в който се намирате. В Cargoson сме внедрили FedEx Compatible API, което предоставя някои много добри допълнителни функционалности, но е достъпно само за FedEx Compatible партньори.

UPS – използва JSON-базирано API и OAuth за удостоверяване, което означава, че има доста заявки, които трябва да задействате, преди да направите резервация и да получите етикетите обратно.

След това имаме EDIFACT, използван от много транспортни компании като DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics и др. Това е много стар стандарт и дори ако може да изглежда, че бихте могли да се справите с една API интеграция за няколко логистични компании, помислете отново. Най-големият недостатък е, че това е връзка, базирана на обмен на файлове, което означава, че трябва да генерирате действителен физически файл, след това да го предадете чрез FTP и буквално да се надявате, че всичко е наред, защото има много сложна обратна връзка за грешки и предупреждения.

Подобно на EDIFACT е FORTRAS, връзка базирана на файлове със същите недостатъци. Той се използва повече в Германия и съседните страни. Не само обменът на файлове е предизвикателство, но самият формат на файла е труден за четене и следователно отнема много време за отстраняване на грешки. Някои добре известни компании, които го използват, включват Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss и др.

Дори след внедряването на всички споменати по-горе интеграции, остава въпросът:

Какво правите с компаниите превозвачи, които нямат никаква ИТ система или портал, да не говорим за API за приемане на транспортни поръчки?

Най-простото решение е да изпратите обикновен имейл. Въпреки че това може да звучи просто, нека да навлезем по-дълбоко. Настройването на техническата връзка с вашия пощенски сървър е едно нещо, но какво да кажем за контактите? Обикновено различните посоки се обработват от различни лица за контакт, а хората променят позициите си. Така че ще трябва да изградите доста изчерпателна контактна матрица във вашата ERP система.

И така, какви са алтернативите на борбата с различните API и EDI протоколи на превозвачите?

Един вариант за разглеждане е мулти-превозвачески API. По същество, това е доставчик на услуги, който е изградил всички връзки с превозвачи, независимо дали са модерни API, стари EDIFACT- или FORTRAS-базирани EDI протоколи или имейл интеграции, и ги е направил достъпни чрез свой собствен, стандартизиран API за доставки. Вместо да внедрявате различни API на превозвачи и да ги поддържате актуални, можете да внедрите само един мулти-превозвачески API стандарт и да задействате всичките си транспортни поръчки чрез него.

Но ние сме отишли още по-далеч.

Различните логистични компании предлагат различни нива на обслужване. Някои предоставят API за резервации, докато други не; някои предлагат възможности за проследяване, докато други нямат тази функция. В Cargoson сме внедрили всички функции, които запълват пропуските за всяка транспортна компания.

Например, когато даден превозвач не предлага онлайн резервации, ние предоставяме портал за това. Ако им липсва проследяване, ние го добавяме. Имаме системи за качване на доказателство за доставка (POD) и други документи, пълнофункционален мулти-превозвачески API, оценки за ETA, изчисления на транспортни цени, статистика за изпълнението и дори данни за емисиите на CO2 от транспорта. По същество, каквото и да липсва на даден превозвач, ние сме го изградили, така че не трябва да се притеснявате за разликите в ИТ или нивото на обслужване между вашите превозвачи.

Вижте как Cargoson прави вашите съществуващи превозвачи по-добри

Ето пример от реалния свят: Големи играчи като FedEx, TNT и DHL Express предлагат API за ценообразуване. Това означава, че когато задействате заявка за цена от Cargoson, цените се извличат директно от системата на превозвача. Обаче, в случаи, когато компания като DSV не предоставя API за ценообразуване, Excel или PDF ценовата листа, предоставена от DSV, се качва в Cargoson и изчислението на цената се извършва в нашата система. Имаме мощен механизъм за качване и изчисляване на цени за товари за тази цел. Същият подход може да се приложи за всички други транспортни компании и е приложим и за други функции.

Нашата цел е проста: да ви предоставим последователно, висококачествено изживяване с всички превозвачи, дори ако те не започват всички със същите възможности. De facto универсален стандарт за API на превозвачи и мулти-превозваческа платформа в едно.

Ако търсите по-добър начин за управление на вашите интеграции с превозвачи, Cargoson може да помогне. Нашата платформа предоставя единен, стандартизиран транспортен API, който ви свързва с всички ваши превозвачи, независимо от техните индивидуални възможности. Това означава, че можете да получите достъп до всички ваши услуги за доставка чрез един унифициран интерфейс, без да се притеснявате за основните технически разлики.

Искате ли да видите как би могло да работи за вашия бизнес? Нека да проведем бърз разговор, за да обсъдим вашата текуща настройка и конкретни предизвикателства за интеграция. Можем да разгледаме някои примери от реалния свят за това как Cargoson е помогнал на компании в подобни случаи като вашия:

Планирайте безплатна 30-минутна консултация