01
1С + TMS/WMS
Часть данных о рейсе, грузе или складе уже находится вне 1С и должна использоваться автоматически.
API-интеграция электронных перевозочных документов
Интеграция ЭПД по API с 1С в Москве
Проектируем автоматический обмен ЭПД и ЭТрН между 1С, TMS/WMS, корпоративными сервисами и поддерживаемым операторским контуром: справочники, документы, статусы, ошибки, повторная отправка, логирование и мониторинг.
Без двойного вводаданные передаются из систем-источников автоматически
Двусторонний обменотправка документов и возврат статусов/ошибок
Контролируемый APIлогирование, повторные попытки и мониторинг интеграции
API там, где он нуженНе заменяем типовой механизм разработкой без необходимости.
Через поддерживаемый контурУчитываем API конкретного оператора или сервиса, а не абстрактный «прямой ГИС».
С контролем ошибокИнтеграция должна уметь объяснить, почему документ не прошёл.
С расчётом эксплуатацииПроектируем не только отправку, но и дальнейшую поддержку.
Когда нужен API
Если стандартного обмена недостаточно для реального процесса
API-интеграция нужна, когда данные распределены между несколькими системами, документы должны формироваться автоматически или бизнесу важно получать статусы и ошибки без ручной проверки интерфейса оператора.
02
Доработанная 1С
Типовой модуль не соответствует внутренним документам, справочникам или бизнес-логике.
03
Массовый поток ЭПД
Ручная работа становится дорогой и создаёт риск задержек при большом объёме документов.
04
Автосоздание документов
ЭПД должны формироваться по бизнес-событию: отгрузке, рейсу, реализации или иному основанию.
05
Возврат статусов
Ответственный сотрудник должен видеть результат обмена в своей системе без ручного перехода в другой интерфейс.
06
Центральная интеграционная шина
Если компания уже использует корпоративный контур интеграции, ЭПД можно встроить в существующую архитектуру.
Архитектура
Как строится API-интеграция ЭПД
Точная схема зависит от оператора или сервиса, но архитектурно процесс обычно разделяется на систему-источник, интеграционный слой, операторский контур и возврат результата.
01
1С / TMS / WMS
Исходные данные о грузе, рейсе, сторонах и транспорте.
02
Интеграционный слой
Сопоставление, проверка и подготовка структуры данных.
03
API оператора
Передача документа через поддерживаемый сервисный контур.
04
Участники процесса
Действия сторон, подписи и изменение состояния документа.
05
Статусы и ошибки
Результат возвращается в 1С или систему, где работает пользователь.
Источники данных
API не должен создавать второй справочник рядом с уже существующим
Перед разработкой определяем мастер-систему по каждому объекту: контрагентам, адресам, грузам, транспорту, водителям и рейсам.
1С:ERP1С:УТ1С:КА1С:УАТTMSWMSКорпоративные сервисы
- Определяем мастер-систему для каждого справочника.
- Фиксируем ключи и правила сопоставления объектов.
- Не дублируем данные без необходимости.
- Разделяем обязательные и опциональные поля.
- Учитываем изменение данных после отправки документа.
Что передаём по API
Документы, справочники, статусы и служебные события
Конкретный набор методов зависит от выбранного оператора или платформы. На уровне проекта мы определяем, какие данные должны передаваться и возвращаться в бизнес-систему.
Из 1С или TMS наружу
- данные участников перевозки;
- адреса и маршрут;
- груз и товарные позиции;
- транспорт и водитель;
- данные рейса или основания;
- команды создания или изменения документа.
Из операторского контура обратно
- идентификатор документа;
- текущий статус;
- результат обработки;
- ошибки проверки;
- события подписания;
- состояние завершения процесса.
Надёжность обмена
Интеграция должна переживать временные сбои без потери документов
Для промышленного API важна не только успешная отправка, но и корректное поведение при таймаутах, недоступности сервиса и повторной обработке.
01
Идемпотентность
Повторный вызов не должен создавать дубликаты, если запрос уже был успешно обработан.
02
Повторные попытки
Временные ошибки обрабатываются по контролируемому сценарию, а не бесконечной отправкой.
03
Очередь
При большом потоке обмен отделяется от действий пользователя и выполняется устойчиво в фоне.
04
Логирование
По каждому запросу можно восстановить, что было отправлено и какой ответ получен.
05
Мониторинг
Повторяющиеся ошибки и зависшие документы должны быть видны ответственным сотрудникам.
06
Ручной сценарий
Для исключительных ситуаций предусматривается понятный способ повторной обработки или корректировки.
Безопасность
Доступ к API и подписи проектируются как разные уровни
Техническая авторизация интеграции не заменяет юридически значимые действия пользователей. Поэтому доступ к API, права в 1С и КЭП/МЧД рассматриваются отдельно.
Технический контур
- безопасное хранение учётных данных;
- ограничение доступа по ролям;
- защищённый транспорт;
- журналирование запросов;
- ротация ключей и секретов;
- разделение тестового и промышленного контуров.
Пользовательский контур
- роль сотрудника в процессе;
- КЭП и МЧД;
- доступ к нужным документам;
- проверка полномочий;
- сценарий замещения;
- контроль действий в 1С.
Этапы интеграции
От карты данных до промышленного мониторинга
Проект API-интеграции начинается не с написания кода, а с определения источников данных и правил обмена.
01
Обследование
Системы, документы, роли, объёмы и оператор.
02
Карта данных
Источники, поля, ключи и правила сопоставления.
03
Архитектура
Методы, направления обмена и обработка ошибок.
04
Разработка
Реализуем обмен и технические механизмы контроля.
05
Тестирование
Проверяем нормальные и ошибочные сценарии.
06
Запуск
Включаем мониторинг и сопровождаем первые рабочие документы.
Отраслевые сценарии
API нужен там, где документы должны следовать за реальным бизнес-событием
У разных компаний источники данных различаются: производство начинается с отгрузки, перевозчик — с рейса, торговля — с массового потока реализаций.
Производство
Автоматически связываем реализацию, складскую отгрузку и перевозочный документ без повторного ввода.
Оптовая торговля
Обрабатываем массовые отгрузки и поток документов с большим числом контрагентов.
Перевозчики
Связываем TMS, рейс, транспорт, водителя, ЭТрН и возврат статусов в диспетчерский контур.
Проектные поставки
Для нестандартных маршрутов проектируем гибкие правила создания и обновления документов.
Типовые ошибки архитектуры
Что делает API-интеграцию дорогой в эксплуатации
Плохо спроектированная интеграция может автоматизировать отправку, но создать ещё больше ручной работы при ошибках и изменениях.
Нет мастер-системы
Одни и те же справочники редактируются в нескольких местах и начинают расходиться.
Нет идемпотентности
Повторные запросы создают дубли документов или повторные операции.
Ошибки теряются
API возвращает ошибку, но пользователь в 1С не видит, что документ не прошёл.
Нет очереди
Пользовательская операция зависит от доступности внешнего сервиса в конкретную секунду.
Нет мониторинга
О проблеме узнают только после жалобы контрагента или водителя.
Нет тестового контура
Изменения приходится проверять сразу на рабочем потоке документов.
Результат проекта
Что должна давать компании API-интеграция
Цель — убрать ручной перенос данных и сделать обмен прозрачным для пользователя, а не просто «подключить API».
Пользователь не вводит повторно то, что уже есть в 1С, TMS или WMS.
Рабочая система отражает результат внешнего обмена.
По логам и ответам можно понять причину сбоя и восстановить обмен.
Новые документы и процессы добавляются в существующую архитектуру.
Стоимость интеграции
Цена зависит от количества систем, методов и сценариев
Стоимость API-проекта определяется не количеством экранов, а архитектурой обмена, качеством исходных данных и требованиями к надёжности.
Что влияет на стоимость
Основные факторы трудоёмкости.
- количество систем-источников;
- число видов ЭПД;
- количество API-методов;
- объём маппинга справочников;
- очереди, мониторинг и обработка ошибок.
Что считаем отдельно
Разделяем разработку и регулярную эксплуатацию.
- обследование и архитектура;
- разработка обмена;
- тестирование;
- тариф оператора или сервиса;
- сопровождение интеграции после запуска.
Связанные услуги
API — один из уровней общей архитектуры ЭПД
Если стандартный обмен подходит, отдельная разработка не нужна. Если требуется глубокая автоматизация — используем специализированный интеграционный проект.
Интеграция ЭПД с 1С
Общая страница по обмену между 1С и внешними системами.
Подробнее →Интеграция ЭТрН с 1С
Рейс, транспорт, водитель, TMS/WMS и статусы транспортной накладной.
Подробнее →Настройка ГИС ЭПД в 1С
Операторский контур, статусы, подписи и тестовый запуск.
Подробнее →СБИС ЭПД и ЭТрН — интеграция
Специализированный сценарий обмена с СБИС / Saby.
Подробнее →Контур.Логистика — интеграция
Отдельная страница по интеграционному контуру Контур.Логистика.
Подробнее →Сопровождение ЭПД
Мониторинг, инциденты и развитие интеграции после запуска.
Подробнее →Интеграция ЭПД по API
Когда API лучше типового модуля 1С
Интеграция ЭПД по API нужна компаниям, у которых данные о перевозке распределены между несколькими системами или стандартный механизм 1С не покрывает бизнес-процесс. API позволяет автоматически создавать документы, передавать сведения в операторский контур и возвращать статусы в рабочую систему.
При этом API не следует рассматривать как универсальную замену типовой интеграции. Если готовый модуль полностью закрывает задачу, отдельная разработка только увеличит стоимость эксплуатации. API оправдан там, где есть TMS/WMS, доработанная 1С, высокий объём документов или сложная корпоративная архитектура.
Для компаний в Москве проект обычно начинается с карты данных: определяется, где хранятся контрагенты, адреса, транспорт, водители, рейсы и сведения о грузе. Затем выбирается способ обмена с конкретным оператором или сервисом.
Если требуется общий интеграционный проект, используйте страницу «Интеграция ЭПД с 1С». Для транспортной накладной — «Интеграция ЭТрН с 1С». После запуска API-контур можно передать на сопровождение ЭПД.
Отдельное внимание уделяется очередям, повторной отправке, логированию и мониторингу. Именно эти механизмы определяют, насколько надёжно интеграция будет работать в ежедневной эксплуатации.
FAQ
Частые вопросы об интеграции ЭПД по API
Когда нужен API, что передавать и как обеспечить устойчивую работу.
Когда API действительно нужен?
Когда данные находятся в нескольких системах, стандартного модуля недостаточно, нужен автоматический обмен или большой объём документов делает ручные действия неэффективными.
Можно ли интегрировать 1С напрямую с ГИС ЭПД?
Архитектуру нужно строить через поддерживаемый операторский или сервисный контур. Возможность и формат API зависят от конкретного оператора и используемого решения.
Можно ли связать 1С, TMS и WMS одновременно?
Да. В этом случае сначала определяется мастер-система для каждого вида данных и правила обмена между системами.
Нужна ли очередь сообщений?
Для массового и критичного обмена очередь обычно помогает отделить пользовательскую операцию от временной недоступности внешнего сервиса.
Как избежать дублей ЭПД?
Нужно проектировать уникальные ключи, идемпотентность операций и проверку результата повторной отправки.
Можно ли получать статусы обратно в 1С?
Если API выбранного сервиса поддерживает необходимые события и методы, статусы можно возвращать в 1С или другую рабочую систему.
Сколько стоит API-интеграция ЭПД?
Стоимость зависит от количества систем, методов, справочников, видов документов, требований к очередям, мониторингу и обработке ошибок. Точная оценка возможна после обследования.
Спроектировать интеграцию
Свяжем ЭПД с 1С и вашими логистическими системами без двойного ввода
Опишите конфигурацию 1С, TMS/WMS, оператора и требуемые документы. Подготовим карту данных, архитектуру обмена и объём разработки.