Все вопросы по ЭПД и ЭТрН в 1С

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

ЭТрН — электронная транспортная накладная для автомобильной перевозки груза.

ЭПД относится к специальному транспортному документообороту с отдельными форматами, ролями, статусами и взаимодействием с ГИС ЭПД.

В зависимости от процесса это ЭТрН, заказ или заявка на перевозку, электронный путевой лист, сопроводительная ведомость, заказ-наряд, договор фрахтования и экспедиторские документы.

Нет. ЭПД — структурированный электронный документ установленного формата.

Состав зависит от документа. Для ЭТрН ключевые стороны — грузоотправитель, перевозчик и грузополучатель; в рейсе также участвует водитель.

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

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

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

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

Минтранс разъясняет, что дополнительного общего переходного периода после этой даты не установлено.

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

Только в случаях, прямо предусмотренных нормативными актами для конкретного документа и ситуации.

Минтранс разъясняет, что смешанный бумажно-электронный документооборот по одной и той же перевозке не предусмотрен.

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

Ключевые изменения установлены Федеральным законом № 140-ФЗ от 07.06.2025.

Для автомобильных перевозок базовым актом является Федеральный закон № 259-ФЗ, включая статью 18.1 об электронных перевозочных документах.

Для транспортно-экспедиционной деятельности применяется Федеральный закон № 87-ФЗ.

Нет. Для практического внедрения учитываются отраслевые законы, постановления Правительства, приказы Минтранса, форматы ФНС и правила электронной подписи.

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

Они определяют порядок обмена, направление документов в государственную систему и отдельные правила функционирования контура.

Да. Технические форматы и отдельные требования могут обновляться.

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

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

Оператором государственной системы является Министерство транспорта Российской Федерации.

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

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

В Реестре операторов ИС ЭПД на сайте Минтранса России.

Да. Формальное наличие в реестре и фактическая готовность к рабочему обмену — разные практические вопросы.

Да, при корректном межоператорском обмене.

Это обмен ЭПД между участниками, подключёнными к разным операторам.

Сравнивать официальный статус, совместимость с 1С, виды документов, роуминг, мобильный сценарий, API, тарифы и поддержку.

Нет. Выбор зависит от архитектуры, конфигурации 1С, контрагентов, объёма документов и требований к интеграции.

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

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

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

Да, перевозчик является одной из ключевых сторон транспортной накладной.

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

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

Масса автомобиля сама по себе не освобождает от ЭТрН при наличии договора перевозки.

Нужно определить, кто фактически перевозит груз и есть ли договор перевозки. Сам термин «самовывоз» недостаточен.

Нет. Это разные документы с разными функциями.

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

Это отдельный файл обмена внутри одной электронной транспортной накладной.

В стандартном сценарии титул 1 формирует грузоотправитель.

Титул 2 формирует и подписывает перевозчик после проверки фактических данных.

Титул 3 формирует грузополучатель при приёмке.

Перевозчик оформляет выдачу груза и завершает стандартный четырёхтитульный маршрут.

Актуальные форматы предусматривают дополнительные титулы для отдельных событий перевозки.

Нет. Дополнительные события могут потребовать других файлов обмена.

Да. Исходные данные можно брать из учётных документов, а ответные титулы и статусы возвращать в рабочий контур.

Чаще всего из-за ошибок данных, идентификаторов участников, полномочий подписи, роуминга или несинхронизированных статусов.

МЧД подтверждает полномочия физического лица действовать от имени организации в соответствующем сценарии подписания.

Нет. Электронная подпись и МЧД решают разные задачи.

Нет. Нужно различать работу с документом и юридически значимое подписание.

Когда сотрудник подписывает от имени организации и его полномочия должны подтверждаться доверенностью.

Не автоматически. Это зависит от роли и способа подписания в конкретном сценарии.

Да. В поддерживаемых сценариях доверенность связывается с пользователем и сертификатом.

Срок действия, владельца, организацию, роль подписанта, доступность сертификата и соответствие полномочиям.

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

Техническое прохождение документа не заменяет внутреннюю проверку полномочий.

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

Да, в поддерживаемых конфигурациях и сценариях.

Это зависит от конфигурации, релиза, сервиса и доработок.

Не всегда. Иногда достаточно обновления и настройки, иногда нужен модуль, расширение или интеграция.

Поддержка зависит от решения и релиза; используются как учётные, так и транспортные конфигурации 1С.

Да. Это один из главных способов снизить повторный ручной ввод.

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

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

Определить источник истины — TMS, WMS или другую систему — и построить интеграцию.

Актуальность релиза обязательно проверяется в рамках аудита готовности.

Подключение — операторский и технический контур; настройка — роли, права, справочники, подписи и статусы.

Внедрение шире и включает аудит, проектирование, настройку, интеграции, тестирование, обучение и запуск.

С аудита текущего процесса.

Проверка 1С, справочников, документов, пользователей, КЭП/МЧД, оператора, роуминга и интеграций.

Да. Сквозной тест позволяет проверить всю цепочку участников и статусов.

Лучше сначала провести пилот на типовом сценарии, затем масштабировать.

Зависит от конфигурации, ролей, организаций, оператора, подписей и интеграций.

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

Разбор ошибок, помощь пользователям, контроль форматов и релизов, корректировка настроек и интеграций.

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

Когда данные находятся в нескольких системах, есть нестандартные документы или требуется автоматический обмен.

Да, если оператор и архитектура проекта предоставляют подходящий API.

Обычно документы, ответные титулы, статусы, идентификаторы и ошибки.

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

Да, если WMS содержит необходимые складские события или реквизиты.

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

Хранить идентификаторы операций, тексты ошибок, повторные попытки и различать технические и бизнес-ошибки.

Да. Это критично для статусов, повторной обработки и диагностики.

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

Модуль удобнее для типовой архитектуры, API — для глубокой интеграции и нестандартного контура.

Водителю нужен поддерживаемый мобильный сценарий для действий в рейсе.

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

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

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

Не автоматически; зависит от роли и способа подписания.

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

Такой случай нужно заранее тестировать в конкретном операторском сценарии.

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

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

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

Нет, при корректном межоператорском обмене.

ЭПД имеет специальные транспортные форматы, статусы и взаимодействие с ГИС ЭПД.

Да, особенно по ключевым перевозчикам, отправителям и получателям.

Провести сквозной тест: отправка, получение, подписание ответного титула и возврат статуса.

Проверить идентификаторы, маршрутизацию, формат документа и настройки операторов.

Не обязательно. Сначала стоит проверить роуминг и экономику текущего решения.

Зависит от готовности 1С, оператора, числа пользователей, документов, организаций и интеграций.

Есть тариф оператора и проектные работы по подключению, настройке или интеграции.

Тариф — регулярные расходы на сервис, внедрение — проектные работы по подготовке системы.

От модели оператора, объёма документов, пакета или постоплаты и дополнительных сервисов.

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

Тарифы, внедрение, доработки, интеграции, подписи, обучение, сопровождение и масштабирование.

Зависит от систем, методов, документов, статусов, ошибок и сложности архитектуры.

Да. Это позволяет быстрее закрыть обязательные процессы и позже наращивать автоматизацию.

У отдельных сервисов есть демонстрационные режимы; их наличие и условия нужно проверять в актуальной документации.

Это функциональность и сервисы для работы с электронными перевозочными документами в экосистеме 1С.

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

В текущих материалах 1С указываются «Калуга Астрал» и «Такском». Перед проектом нужно сверять актуальную документацию.

Да, при поддерживаемом сценарии интеграции.

Конфигурацию 1С, виды документов, источник данных, модуль или API, статусы, мобильный сценарий и роуминг.

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

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

Модуль проще для типовой архитектуры, API гибче для нестандартных процессов.

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

Логистов, диспетчеров, склад, подписантов, водителей и специалистов поддержки — по их ролям.

Создание и получение документов, титулы, подписи, статусы, ошибки и действия водителя.

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

Да, если водитель участвует в мобильном процессе ЭТрН.

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

Да, при изменении форматов, оператора, интерфейса, процесса или состава сотрудников.

Диагностика ошибок, помощь пользователям, обновление настроек и поддержка интеграций.

Дать понятные инструкции по ролям и настроить в 1С прозрачные статусы и сообщения об ошибках.

Связываются реализация, складская отгрузка, грузоотправитель, перевозчик и получатель.

Массовые отгрузки, качество справочников, контрагенты, роуминг и минимум ручного ввода.

Рейс, транспорт, водитель, мобильный сценарий, титулы и статусы.

Разделить перевозки для собственных нужд и договорные перевозки, а также проверить водительский процесс.

Нестандартные маршруты, разные участники и заранее определённый порядок действий при изменениях.

Разделить роли, подключения, сертификаты, МЧД и настройки по каждой организации.

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

Сегментировать перевозчиков по объёму и операторам, протестировать ключевых партнёров и затем масштабировать.