Интеграция 1С с Контур.Логистикой для ЭТрН: инструкция без лишней разработки

Правильнее говорить не “электронные ТТН”, а электронная транспортная накладная, или ЭТрН. Она входит в более широкий контур электронных перевозочных документов, ЭПД. Для проекта это важная терминологическая правка: если в ТЗ смешать ТТН, ЭТрН, ЭПД и обычный ЭДО, команда быстро начнет спорить о разных документах и разных сервисах.

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

Практичный путь для большинства компаний на 1С — не писать всю интеграцию с нуля, а начать с Контур.Логистики для 1С. Такой вариант закрывает рабочий сценарий ЭТрН внутри учетной системы: подготовка титула, отправка, подписание, получение статусов, QR-кодов и задач пользователям. Собственный API-контур нужен, если у компании несколько баз, нестандартная маршрутизация, собственный кабинет или строгая интеграционная архитектура.

Базовый сценарий ЭТрН строится вокруг обязательных титулов Т1-Т4. Т1 формирует грузоотправитель на этапе погрузки, Т2 подписывает перевозчик при приеме груза, Т3 оформляет грузополучатель на выгрузке, Т4 подписывает перевозчик при выдаче груза. Т5-Т8 нужны только при специальных событиях: изменение стоимости, переадресация, замена транспортного средства, прицепа или водителя.

Перед внедрением нужно описать текущий процесс в 1С. Откуда берется основание для ЭТрН: реализация, транспортная накладная, заказ, заявка, задание перевозчику или другой документ? Где хранятся водитель, транспортное средство, маршрут, адреса, грузовые места, вес, договор и контрагент? Какие данные сейчас ведутся в отдельных таблицах, переписке или у логиста вне 1С?

Первый этап проекта — подготовка НСИ. Нужно привести в порядок организации, контрагентов, договоры, точки маршрута, адреса, водителей, транспортные средства, номенклатуру и грузовые характеристики. Без этого модуль можно установить, но пользователи будут вручную исправлять каждый титул перед отправкой.

Второй этап — настройка оператора и подписания. У участников должны быть КЭП, а для сотрудников, которые подписывают не как руководитель или ИП, нужна МЧД. Это лучше проверять до технической настройки: интеграция может быть готова, но документооборот остановится на полномочиях подписанта.

Третий этап — установка и настройка модуля. Проверяется совместимость 1С, способ установки, права пользователей, соответствия организаций и контрагентов, конвертация документов и справочников, фоновые задания, роботы и сценарии автоподписания. Автоматизацию включают только после ручной приемки базового потока.

Четвертый этап — тестирование Т1-Т4 на реальных, но ограниченных сценариях. Нужен один понятный маршрут, один грузоотправитель, один перевозчик, один грузополучатель и заранее согласованный набор документов. На тесте проверяют не только отправку, но и возврат статусов, QR-код, задачи пользователям, печатные формы, архив и повторную отправку после исправлений.

Если компания выбирает прямую интеграцию по API Диадока, архитектура становится сложнее. 1С должна получать токен, читать доступные типы документов через GetDocumentTypes, формировать XML титулов через GenerateTitleXml, отправлять документы и ответные титулы, читать события и статусы, хранить BoxId, LetterId, DocumentId, mt-id и внутренние связи с документами 1С.

Для production-интеграции обязательно нужен журнал обмена. В нем должны быть документ 1С, участник, титул, идентификаторы Диадока, идентификатор Минтранса, текущий статус, ошибка, время последнего запроса и признак повторной обработки. Без такого журнала поддержка быстро превращается в ручной поиск “где зависла накладная”.

Отдельно проектируются ошибки и повторные отправки. Нужно заранее описать, что делать при ошибке авторизации, отсутствии прав, недоступности API, ошибке схемы XML, отказе контрагента, проблеме ГИС ЭПД, смене водителя или транспортного средства. Пользователь должен видеть понятное действие, а не технический стек из API.

BSG-IT ведет такой проект как интеграцию бизнес-процесса, а не как “подключение кнопки”. Мы фиксируем целевой сценарий ЭТрН, проверяем НСИ, роли, КЭП и МЧД, настраиваем обмен, делаем журнал статусов, тестируем Т1-Т4 и только после приемки включаем автоматизацию.