Деякий час тому я поставив собі за мету з'ясувати, чи існує єдиний стандарт транспортного 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 Services або звичайного 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, вас, швидше за все, попросять впровадити API TNT Express Connect. Сама реалізація має середню складність. Недоліком є те, що цей API вважається застарілим і врешті-решт буде закритий. З іншого боку, API FedEx є більш складним і пропонує кілька варіантів залежно від регіону, в якому ви знаходитесь. У Cargoson ми впровадили FedEx Compatible API, який надає деякі дуже зручні додаткові функції, але доступний лише для партнерів FedEx Compatible.

UPS - використовує API на основі JSON та 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, старі протоколи EDI на основі EDIFACT або FORTRAS, або інтеграції електронної пошти, і зробив їх доступними через свій власний, стандартизований 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-хвилинну консультацію