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