ЭДО для грузоперевозок с 1 сентября 2026: что изменилось и как интегрировать с 1С

С 1 сентября 2026 года рынок грузоперевозок в России перешёл на новый этап электронного документооборота.

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

Документы направляются в государственную информационную систему электронных перевозочных документов — ГИС ЭПД — через операторов информационных систем электронных перевозочных документов.

Для бизнеса это означает не просто отказ от бумаги. Меняется сам процесс формирования, подписания, передачи, хранения и контроля перевозочного документа.

Что изменилось с 1 сентября 2026 года

Федеральный закон № 140-ФЗ от 7 июня 2025 года закрепил обязательный переход на электронные перевозочные и экспедиторские документы с 1 сентября 2026 года.

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

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

Что такое ГИС ЭПД

ГИС ЭПД — государственная информационная система электронных перевозочных документов.

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

Важный архитектурный момент: компания не подключается к ГИС ЭПД напрямую.

Обмен выполняется через оператора информационной системы электронных перевозочных документов — ИС ЭПД.

Грузоотправитель
   ↓
  1С
   ↓


Оператор ИС ЭПД
↓
ГИС ЭПД
↓
Государственные органы


   ↕


Перевозчик / водитель
↕
Грузополучатель

Поэтому в корпоративной архитектуре необходимо учитывать как минимум два внешних слоя: оператор ИС ЭПД и государственную систему ГИС ЭПД.

Можно ли подключить 1С напрямую к ГИС ЭПД

Нет.

Прямое подключение участников перевозочного процесса к ГИС ЭПД не предусмотрено. Участник заключает соглашение об электронном документообороте с оператором ИС ЭПД и взаимодействует с государственной системой через него.

Именно оператор становится технологическим посредником между корпоративной системой и ГИС ЭПД.

Как выглядит типовая архитектура ЭПД + 1С

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

                     1С / ERP
                     │
                     │ API / встроенный обмен
                     ↓
            ┌──────────────────┐
            │  Интеграционный  │
            │      слой        │
            └──────────────────┘
                     │
                     ↓
            ┌──────────────────┐
            │ Оператор ИС ЭПД  │
            └──────────────────┘
                     │
                     ↓
                ГИС ЭПД
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
     Перевозчик   Водитель   Получатель

В простом сценарии отдельный интеграционный сервис может и не потребоваться: часть решений 1С уже поддерживает работу с ЭПД и операторами.

Но в крупной компании, где 1С является только одной из систем, отдельный интеграционный слой позволяет не смешивать бизнес-логику предприятия с конкретным оператором ЭПД.

Как работает электронная транспортная накладная

Рассмотрим типовой автомобильный перевозочный процесс.

Шаг 1. Создание заказа

В 1С или транспортной системе создаётся заказ на перевозку. На этом этапе уже должны быть известны основные параметры: груз, отправитель, получатель, маршрут и участники перевозки.

Шаг 2. Формирование ЭТрН

На основании данных перевозки формируется электронная транспортная накладная.

Для автомобильной перевозки, если иное не предусмотрено договором, транспортную накладную составляет грузоотправитель.

Шаг 3. Подписание

Документ проходит необходимые этапы подписания участниками перевозочного процесса.

Шаг 4. Передача оператору

Сформированный электронный документ передаётся оператору ИС ЭПД.

Шаг 5. Передача в ГИС ЭПД

Оператор передаёт необходимые сведения в государственную систему.

Шаг 6. Изменение статусов

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

Шаг 7. Завершение перевозки

После завершения перевозки итоговое состояние документа должно быть отражено в корпоративной системе.

Почему интеграция с 1С сложнее, чем просто отправить XML

На первый взгляд задача выглядит простой: взять документ из 1С, сформировать XML и отправить оператору.

На практике электронная перевозка представляет собой последовательность связанных состояний.

Заказ


↓
Заявка
↓
Формирование ЭТрН
↓
Подписание
↓
Отправка оператору
↓
Передача в ГИС ЭПД
↓
Подтверждение
↓
Перевозка
↓
Приёмка
↓
Расхождения / корректировки
↓
Завершение

Если интеграция воспринимает ЭТрН как обычный файл, значительная часть бизнес-логики остаётся на пользователе.

Если же ЭПД рассматривается как конечный автомат состояний, большую часть процесса можно автоматизировать.

ЭПД как State Machine

Один из наиболее надёжных подходов — хранить состояние каждого электронного документа отдельно от самой 1С.

CREATED


↓
SIGNED
↓
SENT
↓
ACCEPTED_BY_OPERATOR
↓
REGISTERED_IN_GIS
↓
IN_TRANSPORT
↓
DELIVERED
↓
CLOSED


    ↘ ERROR
         ↓
      RETRY / MANUAL REVIEW

Такая модель позволяет точно определить, на каком этапе находится конкретная перевозка.

Например, если документ уже зарегистрирован у оператора, но ответ о передаче в корпоративную систему потерялся, сервис не должен создавать новый документ. Он должен восстановить текущее состояние.

Идемпотентность: как не создать две ЭТрН

Это одна из ключевых задач любой интеграции с внешней государственной или операторской системой.

Представим ситуацию: 1С отправила документ оператору, оператор его принял, но ответ не дошёл до интеграционного сервиса из-за сетевого сбоя.

Если после timeout просто повторить создание документа, можно получить дубликат.

Поэтому необходимо хранить внутреннюю связь:

1С document ID
  │
  ├── Internal integration ID
  │
  ├── Operator document ID
  │
  ├── UID / идентификатор ЭПД
  │
  └── Current status

При повторной обработке система сначала проверяет, существует ли уже операция с таким идентификатором.

Повторная доставка сообщения при этом не должна приводить к повторному созданию бизнес-документа.

Retry: что делать, если оператор или ГИС ЭПД недоступны

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

Поэтому отправку ЭПД лучше выполнять через очередь.

1С


↓
Создание сообщения
↓
Queue
↓
Integration Worker
↓
Оператор ИС ЭПД
↓
ГИС ЭПД

Ошибка?
↓
Retry
↓
Retry
↓
Retry
↓
Dead Letter Queue
↓
Ручной разбор

Важно разделять временные и постоянные ошибки.

Что происходит при отсутствии интернета

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

Минтранс отдельно разъяснял сценарии работы при перебоях связи. В частности, документы могут формироваться и храниться у оператора с последующей передачей в государственную систему после восстановления соединения.

Это ещё одна причина не строить бизнес-процесс по принципу «HTTP-запрос должен успешно завершиться прямо сейчас».

Надёжная архитектура должна учитывать временную недоступность внешних систем как штатное состояние.

Что делать при замене автомобиля или водителя

Реальная перевозка редко проходит идеально по первоначальному плану. Автомобиль может сломаться, водитель может быть заменён, а транспортное средство — изменено уже в пути.

Поэтому интеграция должна учитывать не только создание ЭТрН, но и последующие изменения документа.

В частности, Минтранс отдельно разъясняет сценарии продолжения электронного документооборота при замене автомобиля или водителя.

Для IT-системы это означает простую вещь: ЭТрН нельзя моделировать как неизменяемый PDF-файл.

Это объект, жизненный цикл которого продолжается на протяжении всей перевозки.

Расхождения при приёмке груза

Ещё один важный сценарий — фактическое количество груза отличается от данных в документах.

В электронной системе такие расхождения должны быть отражены в соответствующем этапе электронного документа.

Для интеграции это означает необходимость поддерживать не только «успешную перевозку», но и альтернативные ветки:

Что нужно изменить в 1С

Ответ зависит от конфигурации 1С и текущего процесса перевозок.

В экосистеме 1С уже существуют решения для работы с электронными перевозочными документами. Например, решения 1С поддерживают создание и обмен ЭТрН, заказами, заявками и другими ЭПД через операторов.

Поэтому далеко не каждому предприятию необходимо разрабатывать собственный API-клиент с нуля.

Но типовой функциональности может быть недостаточно, если перевозочный процесс связан с собственной ERP, WMS, TMS, CRM, системой управления заказами или несколькими юридическими лицами.

В таком случае возникает уже не задача «подключить ЭДО», а задача интеграции нескольких корпоративных систем.

Когда достаточно типового решения 1С

Когда нужен отдельный интеграционный слой

Отдельный сервис имеет смысл, когда 1С перестаёт быть единственной системой, участвующей в перевозочном процессе.

Архитектура интеграционного сервиса

Для крупного предприятия мы бы не помещали всю логику обмена непосредственно в регламентные задания 1С.

Более устойчивый вариант — выделить отдельный интеграционный сервис.

                         1С / ERP
                         │
                         ↓
                ┌─────────────────┐
                │ Integration API │
                └─────────────────┘
                         │
                         ↓
                ┌─────────────────┐
                │     Queue       │
                └─────────────────┘
                         │
                         ↓
                ┌─────────────────┐
                │ EPD Connector   │
                └─────────────────┘
                         │
                ┌────────┴────────┐
                ↓                 ↓
         Operator API       Monitoring
                │
                ↓
             ГИС ЭПД

Такой сервис можно реализовать на Symfony или Go, хранить состояние операций в PostgreSQL, использовать Symfony Messenger или другой брокер для очередей и Prometheus/Grafana для мониторинга.

При этом 1С остаётся системой учёта, а интеграционный сервис отвечает за надёжную доставку сообщений и преобразование данных.

Почему не стоит жёстко привязывать бизнес-логику к оператору ЭПД

Компания может взаимодействовать с одним оператором сегодня, но архитектура не должна предполагать, что его API никогда не изменится.

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

Лучше выделить внутренний контракт:

Internal Shipment
    │
    ├── create()
    ├── sign()
    ├── send()
    ├── getStatus()
    ├── amend()
    └── close()
            │
            ↓
    EPD Adapter
      /       \
     /         \


Operator A      Operator B

Тогда замена оператора или добавление нового подключения не требует переписывать бизнес-логику предприятия.

Мониторинг электронных перевозок

Внедрение ЭПД без мониторинга создаёт новую проблему: документы перестают теряться на столе бухгалтера, но начинают теряться в интеграционной очереди.

Поэтому необходимо видеть как минимум:

Как подготовить компанию к ЭПД

Подключение электронных перевозочных документов лучше начинать не с программирования, а с аудита текущего процесса.

Что будет, если компания не готова

Важно разделять две вещи.

Обязанность использовать электронные перевозочные документы действует с 1 сентября 2026 года. Дополнительного переходного периода для самой обязанности законом не установлено.

При этом Минтранс отдельно сообщал о периоде до 1 марта 2027 года, в течение которого предусмотрен нештрафуемый режим адаптации участников рынка.

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

Типичные ошибки при внедрении ЭПД

Ошибка №1. Считать ЭТрН просто электронным PDF

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

Ошибка №2. Подключить оператора, но не изменить бизнес-процесс

Если сотрудники продолжают вручную переносить данные из одной системы в другую, компания формально получила ЭДО, но не получила автоматизацию.

Ошибка №3. Делать всё внутри 1С

Для небольшой компании это может быть оправдано. Но при большом количестве интеграций очередь, retry, мониторинг и адаптеры внешних систем лучше вынести в отдельный сервис.

Ошибка №4. Не учитывать отрицательные сценарии

Тестировать только успешное создание и отправку ЭТрН недостаточно. В реальной перевозке происходят замены автомобиля, изменения данных, расхождения и временная недоступность сервисов.

Ошибка №5. Не хранить историю

Для спорной перевозки необходимо восстановить, кто, когда и на каком этапе подписал документ, какой статус вернул оператор и что произошло дальше.

Когда ЭПД становится задачей интеграционной шины

Если у компании только 1С и один оператор, отдельная интеграционная шина может оказаться избыточной.

Но в крупном предприятии перевозочный процесс обычно пересекает несколько систем:

                    Заказ
                  │
                  ↓
             CRM / ERP
                  │
      ┌───────────┼───────────┐
      ↓           ↓           ↓
     1С          TMS         WMS
      │           │           │
      └───────────┼───────────┘
                  ↓
           Integration Bus
                  ↓
            Оператор ЭПД
                  ↓
               ГИС ЭПД
                  ↓
      Перевозчик / водитель

Здесь интеграционная шина становится единым слоем, который соединяет внутренние системы предприятия с внешней инфраструктурой электронных перевозок.

Такой подход особенно полезен, если предприятие одновременно работает с ЭДО, маркетплейсами, 1С, CRM, WMS, TMS, государственными системами и собственными API.

Итог

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

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

Для небольшой компании задача может решаться средствами типовой 1С и подключённого оператора. Но для крупного предприятия ЭПД быстро превращается в полноценную интеграционную задачу.

Нужно связать 1С, ERP, TMS, WMS, операторов ЭПД, перевозчиков и ГИС ЭПД, обеспечить корректные статусы, идемпотентность, retry, журналирование и мониторинг.

Если перевозочный процесс уже выходит за пределы одной 1С, имеет смысл проектировать интеграционный слой отдельно. Тогда подключение ЭПД становится ещё одной интеграцией в общей архитектуре предприятия, а не новой точечной доработкой учётной системы.