От Excel до API: как развивались интеграции склада
Что передают между ERP клиента и WMS склада
Клиент передаёт в WMS товары, заявки на приёмку и отгрузку, партии, сроки годности, изменения и отмены заказов.
Склад возвращает остатки, подтверждения приёмки, статусы заказов, результаты комплектации и отгрузки, расхождения и результаты инвентаризации.
1. Excel и email: интеграции ещё нет
Самая простая схема:
клиент → Excel → email → сотрудник склада → WMS.
Например, клиент прислал заявку на отгрузку 100 коробов. Менеджер склада открыл файл и вручную создал заказ в WMS.
После отгрузки сотрудник выгрузил результат и отправил клиенту новый Excel.
Информация уже электронная, но между системами по-прежнему стоит человек.
2. Личный кабинет: клиент работает с системой оператора через интерфейс
Следующий уровень — личный кабинет логистического оператора.
Клиент заходит в него сам, создаёт заявку или загружает XLS/CSV, смотрит остатки и получает результаты операций.
Менеджеру склада уже не нужно принимать файлы по почте.
Но ERP клиента и WMS оператора всё ещё напрямую не связаны: человек переносит данные из своей системы в личный кабинет и обратно.
Поэтому личный кабинет — уже удобный цифровой сервис, но ещё не полная интеграция двух систем.
3. Файловый обмен: системы работают без человека
Следующий шаг — автоматизировать то, что раньше делал сотрудник.
ERP клиента сама формирует файл с заказами и передаёт его на сервер оператора. WMS забирает файл и автоматически создаёт задания.
После выполнения операции WMS формирует ответный файл, который получает система клиента.
Получается:
ERP → CSV/XLS → SFTP → WMS
и обратно:
WMS → CSV/XLS → SFTP → ERP.
Это уже полноценный автоматический обмен между системами.
Он может происходить раз в несколько минут, раз в час или по другому расписанию.
Здесь важно различать:
- XLS, CSV, XML, JSON — форматы данных.
- FTP/SFTP — способы передачи файлов.
Поэтому выражение «интеграция через CSV» не совсем точное: CSV определяет содержимое файла, а SFTP — как этот файл передаётся.
4. EDI и XML: электронные документы становятся структурированными
По мере усложнения обмена обычных таблиц стало недостаточно.
Появились формализованные электронные сообщения: заказ, уведомление о поставке, подтверждение приёмки, остатки, результат отгрузки и другие документы.
Такой автоматический обмен структурированными бизнес-сообщениями между компаниями принято называть EDI — Electronic Data Interchange.
При этом EDI — не отдельный канал связи.
Сообщения могут передаваться разными техническими способами, а одним из распространённых форматов стал XML.
Например, вместо строки:
заказ 5678 / товар 12345 / количество 100
система получает структурированное сообщение, где однозначно указано, что является номером заказа, артикулом и количеством.
XML при этом тоже не является способом передачи данных. XML-файл можно отправить через SFTP или передать непосредственно между программами.
5. SOAP/XML: системы начинают обращаться друг к другу напрямую
Следующим шагом стал прямой обмен между программами.
Вместо того чтобы положить XML-файл в папку и ждать, пока WMS его заберёт, ERP может непосредственно обратиться к сервису WMS:
«Создай заказ №5678 на 100 коробов».
WMS принимает сообщение и возвращает ответ:
«Заказ принят».
Одним из распространённых корпоративных способов такого взаимодействия стал SOAP, обычно использующий XML.
Это уже прямое общение двух систем без человека и без обязательной промежуточной папки с файлами.
6. REST API и JSON: современный массовый вариант
Сегодня чаще всего говорят об интеграции через API.
Смысл для бизнеса остаётся тем же: одна система напрямую передаёт данные другой.
Например, ERP клиента отправляет в WMS:
«Создать заказ №5678 — 100 коробов».
WMS отвечает:
«Заказ принят».
После выполнения операции WMS может передать обратно:
«Собрано 98 коробов, 2 отсутствуют».
В современных системах очень распространена связка:
REST API + HTTP + JSON.
JSON здесь — всего лишь формат данных, примерно как XML в предыдущих поколениях интеграций.
Обмен может идти в обе стороны: ERP передаёт в WMS заказы, а WMS возвращает в ERP остатки, статусы и результаты операций.
Иногда система клиента сама запрашивает статус. В других случаях WMS автоматически сообщает о событии — например, что заказ собран или отгружен. Такой автоматический вызов часто называют webhook, но для бизнеса это всё тот же автоматический обмен между двумя системами.
Как выглядела эта эволюция на одном примере
Допустим, клиент хочет отгрузить со склада 100 коробов товара.
- Email: сотрудник клиента отправил Excel → менеджер склада вручную создал заказ.
- Личный кабинет: сотрудник клиента сам загрузил Excel или создал заказ в ЛК.
- Файловая интеграция: ERP автоматически отправила CSV/XLS через SFTP → WMS сама загрузила заказ.
- EDI/XML: ERP сформировала структурированное электронное сообщение → WMS автоматически его обработала.
- SOAP/XML: ERP напрямую вызвала сервис WMS и передала заказ.
- REST API/JSON: ERP напрямую передала заказ через API, а WMS вернула результат операции.
При этом старые способы не исчезли.
У одного современного 3PL-оператора один клиент может работать через личный кабинет, второй — через SFTP, третий — через XML/SOAP, а четвёртый — через REST API.
И это нормально.
Что легко перепутать
Самая простая шпаргалка:
- Личный кабинет — с системой работает человек.
- XLS, CSV, XML, JSON — форматы данных.
- FTP/SFTP, HTTP — способы передачи данных.
- SOAP и REST — способы организовать прямое взаимодействие программ.
- EDI — общий подход к электронному обмену структурированными бизнес-документами между компаниями.
Поэтому FTP, XML, EDI и API — не четыре конкурирующие технологии. Они относятся к разным уровням и могут использоваться вместе.
Например:
EDI → XML → SFTP
или:
REST API → HTTP → JSON.
Всегда ли API лучше
Нет.
Для небольшого клиента с несколькими заявками в день хороший личный кабинет может быть вполне достаточным.
Для стабильного пакетного обмена файловая интеграция через SFTP может работать годами и полностью решать задачу.
API особенно полезен при большом количестве заказов, необходимости быстро получать статусы и тесно связывать WMS с ERP, OMS, интернет-магазином, маркетплейсами или транспортными системами.
Поэтому при выборе 3PL-оператора важно не искать самый модный способ интеграции, а понять, соответствует ли его IT-контур вашим объёмам и бизнес-процессам.
Что важно проверить у 3PL-оператора
Наличие фразы «есть API» в презентации ещё не означает, что интеграция подойдёт конкретному клиенту.
Стоит заранее выяснить:
- есть ли личный кабинет;
- поддерживается ли загрузка XLS/CSV;
- возможен ли автоматический обмен через SFTP;
- какие XML- или EDI-сообщения поддерживаются;
- есть ли REST API;
- какие данные можно передавать через API;
- возвращает ли WMS остатки и статусы операций;
- можно ли передавать партии и сроки годности;
- как обрабатываются изменения и отмены заказов;
- как контролируются ошибки обмена;
- сколько времени и денег занимает подключение нового клиента.
Для крупного 3PL-проекта эти вопросы могут быть не менее важны, чем тариф на хранение или обработку товара.
Как 3PL Sklad может помочь
3PL Sklad помогает подобрать склад ответственного хранения, 3PL-оператора или фулфилмент с подходящими возможностями IT-интеграции.
При подборе учитываем не только географию, стоимость и складские операции, но и требования к обмену данными: личному кабинету, WMS, файловой интеграции, EDI или API.
Уточним требования, проверим подходящих операторов, соберём коммерческие предложения и поможем сравнить условия.
См. также: обзор WMS-систем, логистический консалтинг, серийный и партионный учёт, виды инвентаризаций.
