Разработка EDI-интеграций для B2B: заказы, отгрузки и документы с партнёрами без ручного ввода

Что передаётся

EDIFACT, XML по схеме партнёра, JSON по API, CSV и Excel. Один и тот же заказ может прийти в любом из них, а в учёте должен оказаться одинаковым. Поэтому внутри мы приводим всё к собственной модели сообщения и только на границе превращаем в формат партнёра. Новый формат тогда добавляется как отдельный разборщик, не затрагивая учётную часть.

Как передаётся

• Оператор EDI или ЭДО. Он принимает и доставляет сообщения, у него есть роуминг с другими операторами. Договор и тарифы между вами и оператором. Нам нужен программный доступ или выгрузка.
• AS2. Прямая передача по HTTPS с подписью и квитанцией о получении, используется у части партнёров. Требует сертификатов и отдельной службы на вашей стороне.
• SFTP и почта. Партнёр кладёт файл, вы забираете по расписанию. Просто, но нет мгновенной квитанции, и приходится следить за зависшими файлами.
• HTTP API и вебхуки. Подходит партнёрам с современными системами и вашим дилерам. Требования к версиям и повторной доставке описаны в статье «Проектирование API для интеграций».

1. Профиль партнёра. Формат, канал, перечень сообщений, обязательные поля, правила нумерации, допустимое время ответа. Всё это записывается в конфигурации, а не в коде.
2. Таблица соответствия. Его артикулы и коды точек доставки против ваших, единицы измерения и упаковки. Это самая трудоёмкая часть: коды партнёра нигде не записаны, а в 1С один товар заведён дважды.
3. Тестовые сообщения. Партнёр присылает несколько обезличенных заказов, мы прогоняем весь путь до отгрузки на тестовой копии учёта. Особо проверяем частичную отгрузку, отмену и изменение заказа.
4. Параллельный прогон. Заказы идут и по старому каналу, и по новому. Сравниваем результат. Расхождения разбираем, не трогая боевой учёт.
5. Переключение. Старый канал отключаем после согласованного срока без расхождений. Откат на старый канал возможен до даты, записанной в плане.

Два вида подтверждений

Транспортное подтверждение отвечает «сообщение получено», прикладное — «заказ принят в учёт». Путать их нельзя: партнёр, получивший первое, считает, что заказ в работе, а учёт мог его отвергнуть. Поэтому на каждое входящее сообщение уходит ответ о результате разбора с причиной отказа.

Дубли и порядок

У каждого сообщения есть идентификатор партнёра, и повтор с тем же идентификатором не создаёт второй заказ, а возвращает прежний результат. Изменение или отмена заказа могут прийти раньше самого заказа: такое сообщение ждёт в очереди, а не выбрасывается. Когда сообщение не разобралось, оно уходит в карантин, а не блокирует остальные.

Экран разбора для человека

Менеджер видит список сообщений со статусами, причину отказа понятным языком и кнопки «исправить соответствие и повторить» и «ответить партнёру». Без этого экрана каждую ошибку обмена приходится разбирать программисту.

Подписанный документ должен ссылаться на тот же заказ и ту же отгрузку, что видит склад. Сквозным ключом служит номер заказа партнёра: он хранится в заказе, в отгрузке, в уведомлении и в документе, переданном оператору. Документ формируется только после проведения отгрузки, а статус подписи возвращается в учёт, и менеджер видит, подписал ли партнёр.

Статусы перевозки добавляются в ту же цепочку, если перевозчик отдаёт их по API или файлом; как это устроено, описано на странице про интеграцию ERP с B2B-платформой.

Если партнёру проще работать с вашим интерфейсом, а не принимать сообщения в чужом формате, проектируем его как любой интеграционный API: ключ на каждого партнёра, ограничение частоты, версии, вебхуки с повторной доставкой, описание в OpenAPI и тестовый стенд.

Если нужно связать платформу и учёт целиком: заказы, остатки, статусы, справочники, — начинайте со страницы «Интеграция ERP с B2B-платформой»: EDI там один из потоков. Если партнёрам нужен вход, чтобы самим смотреть цены и оформлять заказ, это B2B-портал. Если сначала нужно навести порядок в продажах, а не в обмене, B2B CRM.

Если партнёрам достаточно вашего API, а EDI не нужен, смотрите разработку API и бэкенда. Если обмен упирается в бумажные и сканированные документы, а не в структурированные сообщения, сначала нужно распознавание документов в закрытом контуре.