С 1 сентября 2026 года электронная транспортная накладная (ЭТрН) переходит в разряд обязательных сопроводительных документов для всех участников грузоперевозок (Федеральный закон от 07.06.2025 № 140-ФЗ). Речь идет не просто о новом правиле, а о формировании цифровой среды, где перевозочный документ существует внутри прозрачного операционного цикла и сопровождает каждого участника логистической цепочки. Это ставит перед компаниями архитектурную задачу.
Многие ошибочно полагают, что работать с ЭПД можно только через личный кабинет оператора или доработанный под эти цели бухгалтерский модуль. Для фирм с пятью рейсами в неделю такой вариант еще подходит. Но если у перевозчика каждые сутки по сотни рейсов, есть собственная TMS и десятки партнеров, дополнительный интерфейс превращается в параллельный процесс, отвлекающий на себя ресурсы и время.
То же самое касается компаний, которые создают логистические платформы, маркетплейсы перевозок или модули для учетных систем: выстраивать с нуля собственный регуляторный контур (форматы, связь с ГИС ЭПД, электронную подпись) долго и дорого. Интеграция через API решает проблему в обоих случаях: ЭПД становится естественной частью текущей архитектуры, а не внешней надстройкой.
Когда имеет смысл использовать API вместо отдельного интерфейса
На рынке есть три типовых способа перехода на ЭПД:
-
веб-кабинет оператора;
-
модуль внутри учетной системы (например, в 1С);
-
внедрение через API.
Ни один из них нельзя назвать универсально лучшим. Выбор продиктован масштабом компании и уровнем развития ее IT-ландшафта.
Кому подходит API
API-подключение актуально для трех типов организаций.
-
Крупный и средний бизнес со своей командой разработчиков. В таких компаниях уже работают ERP, WMS и другие учетные системы. Заводить новые процессы в стороннем кабинете неэффективно: это двойной ввод информации, дополнительное обучение персонала, сверка данных между системами вручную. При использовании API накладная создается там же, где диспетчер планирует маршрут. Водитель видит документ в том же мобильном приложении, которое использует для маршрутизации и отчетности.
-
SaaS-платформы в логистике, агрегаторы перевозок, системы с WMS/TMS. Биржи грузоперевозок и логистические агрегаторы стремятся предложить клиентам работу с ЭПД как встроенную опцию своего продукта. Разрабатывать с нуля собственный регуляторный контур (форматы, связь с ГИС ЭПД, электронную подпись) долго и дорого. API позволяет добавить всю регуляторику как внешний сервис, а платформа продолжает заниматься своей основной бизнес-логикой.
-
Крупные перевозчики и грузоотправители с интенсивным трафиком. Сотни ежедневных рейсов, множество водителей, маршруты с перегрузкой — здесь критична автоматизация. Документ должен появляться по событию, подписываться без ручного участия оператора, а статусы должны возвращаться в систему для дальнейшей обработки. При таких объемах ручные операции порождают поток ошибок. В то же время кастомизированная интеграция с 1С, SAP и другими корпоративными системами позволяет работать с электронными документами бесшовно.
Как устроена связь с ГИС ЭПД и зачем нужны операторы
ГИС ЭПД — это государственная система, которая обеспечивает создание, обработку, хранение и обмен электронными перевозочными документами между участниками перевозок и государством.
Коммерческие компании не могут подключаться к ГИС ЭПД напрямую. Для этого существуют операторы ИС ЭПД, аккредитованные Минтрансом. Оператор берет на себя техническую маршрутизацию: передачу титулов между сторонами, отправку в ГИС ЭПД, контроль форматов.
Для компании, подключающейся через API, это означает, что ей не нужно самостоятельно заниматься:
-
проверкой форматов ЭПД (они периодически обновляются ФНС и Минтрансом);
-
протоколом обмена с ГИС ЭПД;
-
маршрутизацией между контрагентами, работающими через разных операторов.
Какие возможности открывает интеграция через API
Через API становится доступен полный жизненный цикл перевозочных документов:
| Операция | Как работает | Польза для бизнеса |
|---|---|---|
| Подписание | В зависимости от роли применяются разные сценарии: сотрудники юрлиц используют УКЭП, водители и физлица — мобильные сценарии подписания (например, через Госключ) | Водителю не нужен токен, сотрудникам не требуется оформлять КЭП на каждого |
| Отправка | Подписанный титул уходит контрагенту и в ГИС ЭПД | Все участники видят статус в реальном времени |
| Получение статусов | Событийная модель: система получает уведомления о любых изменениях | Диспетчер видит всю цепочку в одном окне |
| QR-коды | Через API можно получить QR-код с данными о перевозке для контроля на дорогах | Проще проходить проверки, ниже риск штрафов |
| Исправление ошибок | При обнаружении неточности создается корректирующий титул, привязанный к исходному документу; аннулировать ЭТрН нельзя | Ошибка исправляется без остановки перевозки, но требуется согласование сторон |
| Печатные формы | Через API можно запросить печатную версию документа и получить файл из хранилища сервиса | Печатные формы доступны прямо из корпоративной системы, без ручной выгрузки |
Архитектура API построена на событийной модели. Это не просто «залить PDF на сервер». Каждое действие генерирует событие с новым статусом, и внешняя система может подписаться на эти события для автоматического реагирования.
Почему платформенный подход выгоднее: одна интеграция решает много задач
Компании, внедряющие ЭПД через API, часто сталкиваются с тем, что параллельно нужны другие сервисы: выпуск и проверка машиночитаемых доверенностей (МЧД), управление сертификатами подписи, мобильное подписание, обмен счетами-фактурами или УПД. Если каждую задачу подключать отдельной интеграцией с отдельным вендором, архитектура быстро становится «лоскутной»: разные способы авторизации, несовместимые модели событий, несогласованная обработка ошибок.
Платформенный подход означает единый API-слой для всех регуляторных сервисов. После первой интеграции (например, ЭПД) уже готовы базовые механизмы: авторизация, подписание, события, логирование, работа с файлами. Каждая следующая интеграция ложится поверх предыдущей без необходимости перестраивать инфраструктуру.
«Астрал.Платформа» как раз предоставляет такое решение: единый API для работы с ЭПД, МЧД, электронной подписью и другими регуляторными сервисами. API построен на событийной модели и использует стандартные HTTP-методы. Базовый набор операций:
-
GET /events и POST /events — получение и отправка событий (смена статуса, подписание, отклонение);
-
GET /files/{file_uuid} и POST /files — работа с файлами титулов;
-
статусная модель документа с четкими переходами между состояниями.
Ключевые отличия API Астрал.Платформы от типичных решений конкурентов:
| Аспект | API Астрал.Платформы | Другие вендоры |
|---|---|---|
| Модель получения событий | Асинхронная: подписка + long-polling. Клиент держит соединение открытым — события приходят без повторных запросов. Идентификаторы событий и цепочки связанных событий. | Периодический опрос статусов (polling). Веб-хуки — не всегда. Корпоративная шина (JMS) — избыточно и сложно |
| Формат ошибок | Единый стандарт RFC 7807 (Problem JSON): клиентские и серверные ошибки разделены, есть отдельные события ошибок | Нестандартизированные форматы (XML, произвольные структуры), единый подход отсутствует |
| Тестирование и песочница | Бесплатная тестовая среда (sandbox) с готовыми сценариями. Выделенная поддержка на этапе интеграции | Доступ к песочнице — «по запросу», качество и наличие не гарантированы |
| Авторизация и доступ | Взаимная аутентификация на уровне транспорта (mTLS) + токены платформы. Единая модель доступа для всех сервисов: УКЭП, Госключ, МЧД, ЭДО подключаются без смены схемы авторизации. | Разрозненные ключи, комбинации вроде «assistant-key + integrator-id», либо модель не раскрыта |
| Статус оператора и связь с ГИС ЭПД | Первый оператор, зарегистрированный в ГИС ЭПД. Нет роуминга через 1С — меньше задержек и рисков. Постоянное участие в рабочей группе ГИС. Есть реализованные проекты с крупными игроками | В ряде сценариев обмен идет через дополнительные контуры или роуминговые механизмы |
Как водитель подписывает ЭТрН без токена: мобильное подписание
Одно из главных опасений при переходе на ЭПД: «Водитель в дороге, у него нет компьютера с криптопровайдером и токена. Как ему подписать накладную?»
Решение — мобильные средства электронной подписи. Водитель подписывает свои титулы (Т2 при приемке груза и Т4 при доставке) простой электронной подписью (ПЭП) в мобильном приложении. А логист или диспетчер перевозчика подписывает те же титулы усиленной квалифицированной электронной подписью (УКЭП) — это так называемая двойная схема. Водителю не нужны ни токен, ни криптопровайдер, ни личная КЭП.
Отдельный случай — когда грузополучатель является физическим лицом. Он может подписать накладную неквалифицированной электронной подписью через мобильное приложение «Госключ» от Минцифры. Для этого физлицу нужна подтвержденная учетная запись на Госуслугах и установленное приложение.
Как это выглядит через API:
Еще один вариант мобильного подписания — приложение «Моя подпись ФНС» для руководителей юрлиц и ИП. Оно позволяет выпускать КЭП ФНС прямо на смартфон и подписывать документы без токена и компьютера. Приложение доступно в RuStore, Google Play и App Store.
Процесс выпуска сертификата в «Моей подписи»:
В этом сценарии подписание выглядит так: система партнера формирует документ (договор, акт, ЭТрН, путевой лист) и через API Астрал.Платформы отправляет его в «Мою подпись», пользователь получает push-уведомление на смартфон, видит документ в читаемом виде и подтверждает подписание, после чего результат возвращается в систему партнера.
Один запрос может содержать до 50 файлов общим объемом до 100 МБ. Поддерживаются PDF, JPEG, TXT, DOC, DOCX. Сценарий востребован для удаленного согласования договоров, тендеров, кадровых бумаг и транспортных накладных, когда руководитель или ИП не в офисе.
Опциональные титулы и особые сценарии
ЭТрН — это не только четыре основных титула: оформление (Т1), погрузка (Т2), разгрузка (Т3) и передача груза (Т4). В реальной логистике часто меняются условия: стоимость доставки, адрес, водитель или транспорт. API поддерживает такие изменения через опциональные титулы.
Если итоговая стоимость доставки отличается от предварительной, перевозчик формирует титул Т5 и подписывает его УКЭП. Грузоотправитель подтверждает новую цену титулом Т6.
-
При изменении адреса доставки грузоотправитель создает титул Т7.
-
При замене водителя или машины перевозчик оформляет титул Т8.
Все эти титулы передаются через API и проходят полный цикл подписания, включая мобильные сценарии.
Как внедрить API ЭПД через Астрал.Платформу
Для компаний со своей IT-командой внедрение API ЭПД в среднем занимает до четырех недель и включает несколько стандартных шагов.
Выводы и рекомендации
ЭПД затрагивает не только бухгалтерию и документооборот. Это сквозной процесс, проходящий через диспетчерскую, склад, кабину водителя и бухгалтерию контрагента. Для компаний с десятками и сотнями перевозок в день управление этим процессом вручную через отдельный веб-кабинет создает избыточную нагрузку.
Интеграция через API не противостоит другим сценариям. Для небольших компаний веб-кабинет или модуль в 1С полностью закрывают задачу. Но для организаций с собственной IT-инфраструктурой API дает три конкретных преимущества:
-
сотрудники работают в привычных для себя системах;
-
создание и обработка документов встраиваются в существующие процессы TMS/ERP и другие корпоративные ИС;
-
первая интеграция создает основу для быстрого последующего подключения МЧД, мобильной подписи и других регуляторных сервисов без повторной настройки инфраструктуры.
Новость
Новость
Дарья Алексеева
Виталий Михейкин
Виталий Михейкин
Сергей Феоктистов
Феоктистова Екатерина
Феоктистова Екатерина
Феоктистова Екатерина
Астрал Отчет 5.0
1С-Отчетность
1С-УП
Астрал Доверенность
МЧД
Астрал.Маркировка
Продукты 1С
Внесение изменений
Астрал.Торги
Регистрация бизнеса
1С:БО
1С-ЭТП
Подпись ФНС
Корпоративный УЦ
КриптоПро
КриптоАРМ
JaCarta LT
JaCarta-2 SE
Рутокен Lite
Рутокен ЭЦП 3.0
Доки
1С-ЭДО
Астрал.ЭДО
Астрал iКЭДО
Найми
Роуминг
Астрал.СКРИН
Астрал.ОФД
Онлайн-кассы
Астрал.Безопасность
152DOC