ГИС ЭПД, операторы, КЭП и МЧД: как связать ЭТрН с 1С с регламентированным процессом

Электронная транспортная накладная работает не сама по себе. Вокруг нее есть несколько обязательных участников: учетная система, оператор информационной системы ЭПД, ГИС ЭПД, подписанты, контрагенты и пользователи, которые отвечают за перевозку. Если не описать эту архитектуру заранее, внедрение превращается в набор разрозненных настроек: где-то подключили сервис, где-то выпустили подпись, но документ все равно не проходит рабочий цикл.

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

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

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

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

Третий вопрос — журнал обмена. Для поддержки важно видеть документ 1С, участника, текущий титул, внешний идентификатор, статус оператора, ошибку, дату последней отправки и ответственного пользователя. Без такого журнала любая проблема превращается в ручной поиск по письмам, кабинетам оператора и скриншотам. В хорошей архитектуре пользователь видит понятное действие: исправить адрес, проверить подпись, повторить отправку, дождаться титула от перевозчика или связаться с контрагентом.

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

Четвертый вопрос — границы интеграции. Небольшой компании может быть достаточно готового сервиса и типового сценария в 1С. Компании с несколькими базами, филиалами, WMS, TMS, сайтом или собственным личным кабинетом чаще нужен отдельный интеграционный слой. Тогда 1С должна обмениваться статусами с внешними системами, а не становиться единственным местом, где живет логистика.

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