

На практике переход на ЭТрН редко сводится к подключению нового сервиса. Документ должен сопровождать фактическую перевозку: от оформления рейса и погрузки до приёмки груза. В этот момент сходятся процессы грузоотправителя, перевозчика, грузополучателя, экспедитора, склада, бухгалтерии и ИТ-систем. Если сначала выбрать оператора, а реальные сценарии перевозок разбирать потом, компания быстро сталкивается с ручной работой и спорными ситуациями: данные о рейсе уже изменились, водитель не может подтвердить этап, получатель видит не те характеристики груза, а ответственные сотрудники не понимают, кто должен вносить исправления.
Электронная транспортная накладная — юридически значимый электронный документ, который используется при оформлении перевозки груза автомобильным транспортом. Обмен происходит через оператора информационной системы электронных перевозочных документов, а сведения направляются в ГИС ЭПД.
В отличие от бумажной накладной, ЭТрН не создаётся один раз в начале рейса. Документ дополняется по мере движения груза, а действия участников подтверждаются электронными подписями. Поэтому важно не только корректно заполнить исходные реквизиты, но и обеспечить последовательность действий всех сторон.
Для большинства процессов достаточно рассмотреть четыре ключевых этапа:
Между этими этапами могут возникать изменения: замена машины или водителя, корректировка адреса, частичная выгрузка, отмена рейса. Для системы это не «договорённость по телефону», а событие, которое должно быть отражено в электронном документообороте по согласованному сценарию.
У компании редко бывает один тип перевозки. Одни поставки выполняются собственным транспортом, другие — с привлечением перевозчика, третьи проходят через экспедитора, четвёртые включают несколько точек выгрузки или нескольких получателей. При этом роли в договоре и в фактической логистике могут не совпадать.
Прежде чем планировать интеграцию, стоит составить перечень сценариев: регулярные межскладские рейсы, доставка клиентам, перевозки с привлечённым транспортом, возвраты, сборные грузы, работа через экспедитора и другие значимые случаи.
Применимость ЭТрН зависит от модели перевозки, статуса участников и действующих требований к конкретному виду документов. Не стоит переносить один шаблон на все поставки или делать выводы только по названию договора. Конкретный сценарий следует проверить с учётом действующих требований и договорной схемы.
Именно на этом этапе становится понятен реальный объём изменений: где достаточно настроить передачу данных, а где нужно пересматривать справочники, правила согласования рейса или действия сотрудников на складе.
1. Кто участвует в каждом сценарии
Для каждой перевозки нужно определить, кто выступает грузоотправителем, перевозчиком, экспедитором и грузополучателем. Важно описать не только юридические роли, но и фактических исполнителей: кто формирует рейс, кто передаёт груз водителю, кто принимает его на площадке.
Без этого документ может быть создан от имени неверного участника, а обязанность по формированию или подписанию очередного этапа останется «между» отделами и контрагентами.
2. Кто формирует, проверяет и подписывает сведения
Полезно разложить процесс по шагам: кто создаёт черновик, кто проверяет груз и маршрут, кто отправляет документ перевозчику, кто подписывает его на погрузке и кто закрывает рейс после приёмки.
Если ответственность не закреплена, сотрудник может увидеть документ слишком поздно — уже после фактической погрузки или прибытия машины. Тогда исправление данных превращается в срочную ручную операцию, а груз и документы начинают двигаться в разном ритме.
3. Откуда берутся данные
ЭТрН использует данные о грузе, адресах, контрагентах, маршруте, транспорте и водителе. Они могут находиться в 1С, ERP, TMS, WMS, CRM, таблицах диспетчера или системе перевозчика. Нужно заранее определить систему-источник для каждого реквизита и правило его актуализации. Если этого не сделать, интеграция будет передавать формально заполненные, но устаревшие данные. Сотрудникам придётся проверять и дополнять каждый документ вручную, а разные системы начнут хранить разные версии одного рейса.
4. У кого есть право подписи
Отдельный блок — полномочия подписантов. Руководитель действует от имени организации без доверенности, а сотруднику, который подписывает электронные документы от имени компании, требуется собственная КЭП физического лица и машиночитаемая доверенность с соответствующими полномочиями.
Нужно проверить не только наличие КЭП и МЧД, но и реальную операционную схему: кто доступен в момент погрузки или приёмки, как заменяется отсутствующий сотрудник, как контролируется срок действия доверенности. Иначе документ может зависнуть на этапе, когда груз уже находится в пути.
5. Как компания действует в нестандартных ситуациях
В перевозках постоянно возникают отклонения от плана: водитель заболел, машина сломалась, адрес изменился, груз приняли частично или рейс отменили. Для каждого такого события должны быть понятны инициатор, порядок согласования, данные для внесения изменений и ответственный за коммуникацию с контрагентом.
Без заранее согласованного сценария решение принимается ситуативно. Это создаёт риск повторного оформления документов, несогласованности между участниками и потери времени на выяснение, какая версия данных считается актуальной.
В документ попали неверные данные о водителе, адресе или машине
Такая ошибка часто появляется из-за разрыва между планированием и фактическим назначением рейса. Заявку оформили заранее, а транспорт или водитель изменились перед погрузкой. Операционный риск здесь не в самой ошибке, а в том, что участники могут продолжить процесс с разными данными. Нужен понятный маршрут: кто замечает расхождение, кто вправе инициировать изменение и на каком этапе документ можно передавать дальше.
В пути меняются водитель или транспортное средство
Поломка, подмена машины или пересадка водителя — нормальные рабочие ситуации для логистики. Но для ЭТрН это не просто корректировка в диспетчерской системе: изменения должны быть синхронизированы с электронным документом. Компаниям стоит заранее определить, какие данные диспетчер передаёт в систему, кто оформляет изменение и как водитель получает актуальные сведения о перевозке. Иначе фактический рейс продолжится, а электронный контур останется в прежнем состоянии.
Груз выгружается в нескольких точках
Многоточечный маршрут требует заранее спланировать порядок действий всех получателей и перевозчика. Нужно понимать, какие данные подтверждаются на каждой точке, кто отвечает за приёмку и как система отражает остаток груза для следующего адреса. Если воспринимать такую перевозку как обычную доставку «из точки А в точку Б», проблемы проявятся уже на первой частичной выгрузке: склад не понимает, что подписывать, а диспетчер вручную собирает подтверждения по телефону.
Рейс отменяется после оформления документа
Отмена может произойти до погрузки, после передачи груза водителю или уже в пути. Для каждого случая нужен свой процесс: кто фиксирует отмену, кто уведомляет участников, что происходит с грузом и какие данные должны остаться в связанных системах. Когда такого правила нет, один отдел считает рейс отменённым, другой — открытым, а бухгалтерия и логистика получают противоречивые статусы.
Фактические характеристики груза отличаются от заявки
Вес, объём, количество мест или состав груза могут уточняться на погрузке. Заявка и ЭТрН при этом решают разные задачи: одна описывает договорённость сторон, другая должна отражать сведения о конкретной перевозке. Нужно определить, какие отклонения допустимы в бизнес-процессе, кто их подтверждает и требуется ли обновить внутреннюю заявку, чтобы тарифы, лимиты и учётные данные не расходились с фактом.
Подготовка к ЭТрН начинается не с технического подключения, а с предпроектного разбора логистики. Результатом такого консалтинга становится рабочая модель обмена, понятная и бизнесу, и ИТ-команде.
Обычно она включает:
Такой разбор помогает отделить обязательные изменения от желательных улучшений. Например, может оказаться, что интеграция технически возможна, но справочник водителей ведётся вручную и не содержит необходимых атрибутов. В другом сценарии проблема будет не в данных, а в отсутствии сотрудника, который может оперативно подписать документ со стороны склада.
Рациональная последовательность выглядит так:
У компаний, которые заранее разобрали логистические сценарии, роли и исключения, ЭТрН становится рабочим инструментом, встроенным в привычный цикл перевозки. У тех, кто начинает только с подключения сервиса, слабые места обычно проявляются уже в первом нестандартном рейсе.
Если вы готовитесь к переходу на ЭТрН и хотите понять, какие процессы и доработки потребуются именно в вашей логистической модели, команда НооСофт поможет провести предпроектный разбор и подготовить требования к обмену.