Когда начинаешь изучать ЭТРН, первое время все выглядит достаточно просто.

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

Красиво.

Только в реальной перевозке достаточно часто существует еще один участник - лицо, осуществляющее погрузку, или ЛОП.

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

И привычная картинка:

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

перестает описывать реальную перевозку.

В ней появляется еще один участник:

Грузоотправитель → ЛОП → Перевозчик → Грузополучатель.

Причем ЛОП - это не термин интеграторов и не очередное поле, которое кто-нибудь потом заполнит в XML.

Про него вполне конкретно написано в нормативных документах.

Для начала немного скучного. Что говорит нормативка

В Правилах перевозок есть достаточно прямая формулировка:

«Транспортная накладная подписывается грузоотправителем (лицом, осуществляющим погрузку груза в транспортное средство)…»

Кроме того, отдельно говорится, что груз считается вверенным перевозчику после того, как он погружен грузоотправителем или лицом, осуществившим погрузку, а раздел 8 «Прием груза» заполнен и подписан сторонами.

То есть уже на этом уровне ЛОП - не просто организация, название которой надо указать в документе.

Но для ЭТРН интереснее Постановление Правительства РФ № 931, которое регулирует электронный обмен перевозочными документами.

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

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

В Постановлении № 931 даже существует отдельное понятие:

«оператор лица, осуществляющего погрузку груза в транспортное средство».

Получается, нормативная модель изначально допускает ситуацию, когда грузоотправитель работает через одного оператора ИС ЭПД, а ЛОП - через другого.

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

Теперь посмотрим сам XML

Формат ЭТРН утвержден приказом ФНС России № ЕД-7-26/1065@.

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

В самом XML есть отдельный обязательный блок:

СвЛицПогрГр - «Сведения о лице, осуществляющем погрузку груза в транспортное средство».

И формат прямо предусматривает два варианта:

1 - ЛОП совпадает с грузоотправителем.

2 - ЛОП не совпадает с грузоотправителем.

Поэтому ситуация, когда грузоотправитель - одна организация, а фактически машину грузит другая, не является каким-то редким исключением. Этот сценарий предусмотрен самим форматом ЭТРН.

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

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

Он может быть отдельно указан в ЭТРН, формировать первый титул, подписывать его своей электронной подписью и передавать через своего оператора ИС ЭПД.

И именно на ЛОП в такой схеме ложится подтверждение фактической погрузки и передачи груза перевозчику.

Почему про ЛОП почти никто не говорит

Если открыть большинство вводных материалов по ЭТРН, пользователь увидит понятную схему:

Грузоотправитель → Перевозчик → Грузополучатель.

Грузоотправитель создает Т1, перевозчик принимает груз, грузополучатель принимает его у перевозчика, после чего документооборот завершается.

И в этом нет ничего плохого. Нельзя начинать вводный вебинар со всех возможных вариантов договорных отношений, самовывоза, складов ответственного хранения, нескольких ЭДО-контуров и особенностей работы ЛОП. Для понимания базовой механики трех участников вполне достаточно.

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

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

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

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

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

Простой пример из насыпных перевозок

Допустим, компании нужен щебень.

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

Получается следующая схема:

Грузоотправитель - покупатель, заключивший договор перевозки.

ЛОП - карьер, который фактически загружает щебень в самосвал.

Перевозчик - транспортная компания.

Грузополучатель - строительный объект.

На бумаге ничего особенно страшного.

А теперь попробуем сформировать ЭТРН.

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

Но фактическая информация появляется уже на карьере.

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

Получается, что информация для Т1 рождается сразу в двух организациях.

У грузоотправителя находится коммерческая и организационная часть. У ЛОП - фактические данные погрузки.

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

Представим обычную ситуацию.

Грузоотправитель находится в Москве, карьер - в Новосибирской области. Машина заехала на весы, порожний вес зафиксирован, щебень загрузили, получили фактический вес - 28,7 тонны.

Именно карьер сейчас знает, что эти 28,7 тонны действительно оказались в конкретном автомобиле.

Поэтому вопрос «кто нажмет кнопку создания Т1?» здесь не самый важный.

Гораздо важнее другое:

как данные грузоотправителя должны попасть к ЛОП, чтобы тот мог своевременно оформить и подписать корректный Т1?

На практике я пока вижу три рабочих варианта.

Вариант первый. Передача черновика ЭТРН

На мой взгляд, это самый логичный сценарий.

Грузоотправитель заранее создает у себя черновик Т1 и заполняет все, что ему уже известно: грузоотправителя, грузополучателя, перевозчика, машину, водителя, груз, адреса, заявку, сопроводительные документы и остальные необходимые реквизиты.

После этого неподписанный черновик передается ЛОП.

Машина приезжает на погрузку, сотрудник ЛОП открывает уже подготовленный документ, проверяет информацию и добавляет данные, которые появились непосредственно на точке погрузки: время прибытия, фактический вес и другие сведения.

После проверки ЛОП подписывает Т1 своей электронной подписью и запускает документ в официальный электронный документооборот.

В такой схеме практически нет повторного ввода. Грузоотправитель заполняет известную ему часть, ЛОП - то, что появилось на погрузке.

Но есть ограничение.

Черновик еще надо как-то передать.

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

Это необходимо проверять на конкретной связке.

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

Если нет - остается XML.

Вариант второй. Передача XML

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

Вместо этого выгружается подготовленный XML-файл в формате ФНС.

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

Сотрудник ЛОП получает XML и загружает его в свою систему ЭДО. На основании файла создается черновик Т1, который ЛОП проверяет, дополняет фактическими данными по погрузке и подписывает своей электронной подписью.

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

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

Но здесь я бы отдельно зафиксировал один момент.

XML, отправленный кладовщику по электронной почте, - это еще не отправленная ЭТРН.

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

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

Поэтому в регламенте я бы даже не называл этот процесс «передачей ЭТРН».

Точнее будет:

«Передача подготовленного XML для последующего формирования и подписания ЭТРН ЛОП».

Иначе рано или поздно появится диалог:

• Я ЭТРН отправил.
• Куда?
• На почту кладовщику.

Нет. Пока отправили только файл.

Вариант третий. Старый добрый Excel

Есть еще вариант, который, похоже, переживет любую цифровую трансформацию.

Excel.

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

Грузоотправитель формирует таблицу по заранее согласованному шаблону и передает ЛОП данные по планируемым погрузкам.

Например:

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

Работает? Да.

Хорошо ли оставлять такой процесс навсегда? Конечно нет.

Но на этапе пилота Excel иногда оказывается даже полезен.

До начала тестов почти всегда кажется, что все необходимые данные у компании есть.

Потом начинаем реально заполнять ЭТРН и выясняется, что ИНН водителя никто не хранит, прицеп заранее неизвестен, машину поменяли за час до погрузки, грузополучатель изменился, телефон водителя лежит у диспетчера в WhatsApp, а какой договор является основанием погрузки - надо еще выяснить.

Фактический вес вообще появится только после второго проезда через весовую.

Вот это сначала надо научиться собирать.

А потом уже автоматизировать.

Поэтому Excel вполне может быть нормальным инструментом тестовой эксплуатации. Главное - не обнаружить через пять лет, что он так и остался основной интеграционной шиной компании.

Три варианта в одной таблице

Для себя я бы расставил приоритет так:

черновик ЭТРН → XML → Excel.

Черновик ходит между системами - отлично.

Не ходит - проверяем возможность передачи XML.

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

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

Что надо согласовать между грузоотправителем и ЛОП

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

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

Роли и полномочия

Первое - четко определить, кто в конкретной перевозке является грузоотправителем, а кто ЛОП.

Не исходя из логики:

«Карьер грузит - значит он и грузоотправитель».

А исходя из реальной договорной схемы.

Нужно определить основание, по которому ЛОП осуществляет погрузку, а также конкретных сотрудников, которые будут подписывать Т1.

И тут быстро появляются вполне бытовые проблемы.

Например, карьер работает 24/7, а единственный человек с нужной электронной подписью - директор с графиком 5/2.

Для проекта это плохая новость.

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

Данные

Следующий вопрос - какие именно сведения грузоотправитель должен передать ЛОП.

Фразы «все необходимые данные для ЭТРН» здесь недостаточно.

Нужна обычная таблица:

поле - источник - ответственный - момент появления - обязательность.

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

Момент передачи и корректировки

Важно определить не только какие данные передаются, но и когда.

За день до погрузки?

После назначения автомобиля?

За час до приезда?

После въезда на территорию?

То же самое с корректировками.

Допустим, в черновике указана машина А124АА, а фактически приехала А123АА.

Может ли ЛОП сам исправить данные?

Или должен запросить новый черновик?

Машину в это время грузим или оставляем ждать?

Кому сотрудник карьера звонит в два часа ночи?

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

Аварийный сценарий

Ну и обязательно должен существовать ответ на вопрос: что делать, если штатная схема не работает.

Не пришел черновик.

XML не загружается.

ЭДО недоступно.

Нет интернета.

Не работает подпись.

Сотрудник, который обычно подписывает Т1, заболел.

Карьеру довольно сложно объяснить очереди из двадцати самосвалов:

«У нас интеграция временно недоступна, подождите».

Поэтому резервный процесс должен быть определен заранее.

И вот здесь проявляется настоящая проблема ЭТРН

ЭТРН до сих пор часто воспринимают как электронную версию бумажной транспортной накладной.

Была бумажка.

Теперь будет XML.

На практике изменение намного серьезнее.

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

Кто назначает автомобиль и водителя?

Кто знает фактический вес?

И главное - кто подтверждает, что конкретный груз действительно передан конкретному перевозчику?

Последний вопрос и приводит нас к ЛОП.

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

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

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

В такой ситуации фраза:

«ЭТРН формирует грузоотправитель»

сама по себе ничего не решает.

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

Что в сухом остатке

Если грузоотправитель и ЛОП - разные лица, этот сценарий я бы ставил одним из первых в тестовой эксплуатации ЭТРН.

Не перевозку, где грузоотправитель, ЛОП и склад - одна организация. Она, скорее всего, и так заработает.

Гораздо полезнее сразу проверить связку:

грузоотправитель → сторонний карьер → перевозчик → грузополучатель.

На ней достаточно быстро выяснится, готова ли компания к реальному ЭТРН или пока только научилась нажимать кнопку «Создать».

Именно в этом сценарии придется ответить на практические вопросы:

• кто передает ЛОП данные;
• в какой момент;
• кто их проверяет;
• что делать при расхождениях;
• кто подписывает Т1;
• и как документ попадет из системы грузоотправителя в систему ЛОП.

Варианты уже понятны:

1. Передача черновика ЭТРН.

2. Передача XML между контурами.

3. Excel как временный или резервный механизм.

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

Потому что автоматизировать лучше работающий процесс.

А не хаос за три дня до запуска.