Внедряем ЭДО

В опросе SberKorus от 07.2024, 80% респондентов отметили положительный эффект ЭДО, а данные ПЭК и СКБ Контур показывают двукратный рост подключений в Q1 2024 по сравнению с тем же периодом годом ранее, что говорит о том, что рынок активно готовится к массовому внедрению ЭДО, и мы не можем оставаться вне этого процесса.

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

В Trucker TMS изначально не было инструмента обмена документами, однако планируемый переход на обязательный ЭДО внёс свои коррективы в текущий на тот момент роадмап, да и сами клиенты всё чаще начинали требовать цифровой обмен, чтобы успеть обкатать процессы до обязательного применения.

Кроме того, наличие ЭДО воспринимается как конкурентное преимущество в логистике, т.к. бумажные документы (транспортные накладные в частности) – это всегда риски: водители или работники склада нередко ошибаются, забывают поставить подпись или дату, а то и вовсе теряют документы.

Ещё раз пройдёмся по драйверам решения о запуске ЭДО у нас в продукте. Некоторые из них обязательны для исполнения с т.з. законодательства, а некоторые - следствие движения по течению быстро меняющихся условий рынка, чтобы оставаться на нём востребованным сервисом.

1. Регулятор: с 1 сентября 2026 года ЭДО станет обязательным для грузоперевозок в России, а если продукт его не поддерживает, клиенты уйдут и будут искать TMS с этой функцией.
2. Клиентский спрос: опросы показали высокую заинтересованность клиентов, что говорит о готовности к использованию, а это плюс к тому, что клиент останется с нами.
3. Операционная эффективность: автогенерация и валидация исключают ручные ошибки, а это напрямую положительно влияет на закрытие перевозки и, как следствие, цикл Time-To-Money (ооооочень болезненная тема перевозчиков) проходит быстрее.
4. Юридическая надежность: документы в ЭДО имеют ту же значимость, что и бумажные, а это повышает взаимное доверие сторон, участвующих в перевозке.
5. Сарафан: чем больше клиентов используют ЭДО, тем выгоднее продукту, т.к. они все связаны сетью контрагентов в контуре нашей TMS.

Всё это дало нам примерное понимание того, что мы хотим получить на выходе: выдать рабочее MVP-решение, которое покрывало бы процесс End-To-End сценария «Создать → Подписать → Отправить» по формализованным и неформализованным документам с возможностью в будущем масштабировать решение и позаботиться о более удобном взаимодействии с т.з. пользовательского опыта.

Вместе с PM и аналитиком провели серию интервью и консультаций с ключевыми пользователями (логисты, экспедиторы и водители) и экспертами в отрасли (в том числе из команды оператора ЭДО), и выяснили важные детали:

• логисты тратят по 10−15 минут на оформление каждой накладной с учетом распечатки и заполнения;
• каждая шестая накладная возвращается на доработку из-за неточных данных;
• водители жалуются, что им приходится возить стопки доверенностей, путевых листов и накладных.
• КЭП на телефоне у водителей почти ни у кого нет;

Также, многие отмечали неудобство, что если потерял товарную накладную, это целая проблема её восстановить.

Мы также изучили что происходит в отрасли.

Кто-то из конкурентов уже использовали ЭДО, однако большинство таких продуктов представляют собой отдельные компоненты и требуют дополнительного подключения к внешним сервисам, которое выходит за рамки E2E и разрывает контекст при работе пользователя (мы так же просим пользователя «подружить» TMS с поставщиками ЭДО, но сделали это внутри интерфейса продукта).

Ещё одна слабость в большинстве продуктов – участнику перевозки приходилось вручную заполнять цифровую накладную, что мы также учли и, забегая вперёд, реализовали отправку документов водителем из мобильного приложения.

Собрав всю эту информацию, мы вывели основные гипотезы.

Гипотеза 1
Интеграция ЭДО в TMS сократит время обработки документов на 100%. Это должно ускорить закрытие рейсов и, как следствие, улучшить оборачиваемость средств у клиентов.

Гипотеза 2
Автозаполнение и встроенные проверки позволят снизить долю накладных с ошибками с 15% до 1−2%

Гипотеза 3
Интегрированное решение повысит удовлетворённость пользователей и привлечёт новых клиентов. Мы предполагали, что 70% текущих клиентов подключат модуль ЭДО в течение первого года, а также сможем заинтересовать крупные компании, которые ищут TMS с поддержкой ЭТрН (особенно в преддверии 2026 года). Метрика успеха здесь – доля активных клиентов, использующих ЭДО, и количество новых сделок, где наличие ЭДО стало решающим фактором (отследить сложнее, но продажи согласились собирать такую обратную связь).

Гипотеза 4
Решение будет соответствовать законодательству и избавит клиентов от необходимости искать альтернативы. То есть 100% электронных документов через Trucker должны удовлетворять требованиям ФНС и ГИС ЭПД. Эта гипотеза скорее обязательное требование к качеству, и её проверка - прохождение тестов с оператором ЭДО и успешные кейсы реального использования без юридических сбоев.

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

1. Пользователям критично встроить ЭДО в привычный процесс, а не делать его отдельным трудоемким шагом.
2. Мы должны превентивно валидировать обязательные поля, чтобы минимизировать риск ошибки.
3. Логист должен в любой момент видеть, на каком этапе документ: создан, отправлен водителю, подписан, передан грузополучателю и т. д.
4. Решение для водителей должно работать на смартфоне и не требовать сложных действий.

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

В итоге мы выбрали стратегию, в которой наше решение устраняет недостатке типовых TMS, предлагая пройти весь цикл ЭДО в интерфейсе нашего продукта.

Итак, у нас уже есть основные гипотезы, требования и конкретный критерий успешности в виде выполнения базового сценария «Создать → Подписать → Отправить», а также понимание того, как функционал ЭДО реализован у некоторых конкурентов.

Теперь нам надо декомпозировать сценарий с учётом контекста нашей TMS, и определить точки входа и движение данных документа внутри продукта.

Начнём с подключения к ЭДО и проверки подключения сертификата – без них модуль ЭДО в продукте можно считать бесполезным. Нам не нужно изобретать что-то необычное, т.к. у нас уже есть устоявшиеся паттерны поведения, поэтому проектирируем максимально упрощённый сценарий для старта работы: подключение оператора и проверка сертификата.

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

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

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

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

Я постарался сделать сценарий и сам экран максимально простым: понятные поля, подсказки, ссылки на регистрацию у оператора, индикатор успешного подключения:

1. В модальном окне пользователь выборает оператора
2. Авторизуется
3. Выборает продукт оператора, если их несколько

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

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

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

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

Подключение оператора ЭДО – это только технический канал обмена документами. Чтобы документы можно было юридически подписывать и отправлять через этот канал, пользователю нужен действующий сертификат электронной подписи и настроенное клиентское окружение (CryptoPro + плагин).

Главная проблема пользователей – не столько сама логика ЭДО, сколько «магия» вокруг подписи: CryptoPro, плагины, сертификаты.

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

• прошёл путь настройки на стороне операторов ЭДО по их публичным инструкциям и документации CryptoPro, выписал все шаги и типовые точки отказа, где обычно ломается процесс;
• посмотрел, как конкуренты показывают (или не показывают) состояние окружения: в одних продуктах есть только окно с ошибкой, в других – разрозненные ссылки на инструкции;
• обсудил с разработкой, что мы в принципе можем проверять автоматически на стороне клиента: видимость сертификатов, наличие плагина, статус подключения к оператору.

Из этого мини-исследования родилось решение: одно окно, где человек и видит состояние окружения, и сразу получает конкретные шаги, что сделать дальше.

Если на компе пользователя настроена работа с ЭДО, в открывшемся окне он увидит сообщение, что окружение настроено.

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

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

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

Если с сертификатом всё хорошо, то эта ветка сценария просто не срабатывает.

Итак, ЭДО подключено, окружение настроено, сертификат отображается – что дальше?

На этапе проектирования мы понимали, что пользователи будут работать не только с формализованными документами (ЭТрН, УПД, счёт-фактура и т. п.), но и с неформализованными.

Если кратко:

• формализованные документы предназначены для сдачи отчетности и взаимодействия с контролирующими органами, у них законодательно утвержденная структура и формат (XML) - их менять нельзя;
• неформализованные документы служат для взаимодействия отделов внутри организации – это доверенности, заявки, акты приема-передачи, экспедиторские расписки и прочие договоры с контрагентами.

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

Если пользователи не разделяют документы по назначению в точке входа, то как же тогда упростить взаимодействие со списком всех документов? Разделить на потоки. Логист видит это как набор документов, которые нужно отправить от лица компании и документы, которые пришли на подпись.

Важно уточнить: входящий документ для логиста – это его свойство как объекта, а не статус в процессе подписания.

Третья ветка – черновики. Это не до конца подготовленные по разным причинам документы для отправки. На этапе формирования бизнес-требований я уже задумывал сделать их как подтип исходящих, но общение с пользователями изменило моё решение – логисту важно хранить их отдельно, как отдельный объект, потому что данные для документа могут уточняться даже в течение нескольких дней, и важно как можно быстрее получить доступ к хотя бы черновому варианту, чтобы в будущем только дополнить информацией, а не тратить время на создание с нуля.

Для MVP-версии сделали только базовый набор атрибутов:

• название организации-контрагента;
• подробный статус документа, тип документа;
• номер заявки на перевозку;
• дата последнего действия.

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

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

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

Мы сознательно не делали один длинный список. В реальной жизни в процесс вовлечены две роли с разными задачами:

• бухгалтерия – закрыть сделку в учёте, НДС, первичка, сверки.
• логист или экспедитор – организовать саму перевозку: договориться, отвезти, сдать груз.

Поэтому мы разделили документы на две смысловые группы:

• «Бухгалтерия» – всё, что живёт в контуре учёта и налогов.
• «Оформление перевозки» – описывает саму перевозку и отношения между её участниками.

Так человек сразу понимает: «я сейчас закрываю перевозку в учёте» → левая колонка, «я оформляю перевозку как услугу или процесс» → правая колонка.

Список не выдуман с потолка. Он сложился из двух источников:

1 Аудит бумажного документооборота у клиентов
Мы с командой в начале проекта попросили нескольких ключевых клиентов прислать полный набор шаблонов, которые они используют по перевозкам: от заявки до закрывающих документов. Там всплыли и ТОРГ-12, и классический акт, и экспедиторские расписки, и реестры перевозок. Мы свели это в общий список и посмотрели, какие документы повторяются у всех, а какие – уникальные.

2 Юридические и бухгалтерские требования
С юристами и бухгалтерами мы прошлись по классическому набору документов в транспортной логистике и экспедировании:

• что обязательно по закону (УПД, счёт-фактура, акт, перевозочные документы);
• что типично требуют юристы в договорах перевозки и экспедирования (договор, поручение, доверенность, расписка);
• что используют для сверок и внутренней отчётности (реестр перевозок).

На пересечении «часто используем» + «юридически значимо» и получился костяк списка.

Забегу вперёд на несколько месяцев.

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

Упаковали всё в варианты и расписали UserFlow, где в зависимости от точки контекста (заказ, заявка, документооборот или чек-лист исполнения перевозки) и типа документа пользователь выбирает нужный ему способ создания.

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

Возвращаемся обратно.

Рассмотрим форму создания неформализованного документа для подписание в ЭДО.

Вспомним, что для неформализованных документов ЭДО не диктует жёсткий XML-формат. Пользователю нужно быстро «завернуть» уже готовый файл в юридически значимую форму: указать кому отправляем, к какой заявке это относится, и подписать.

Моя же задача - дать для этого всё необходимое, оставив форму простой. Мы сознательно не делали отдельные состояния под каждый вид документа (доверенность, расписка и т. д.), потому что требований от оператора к структуре нет, а у клиентов свои шаблоны Word/Excel.

Для идентификации документа нам обязательно понадобится его название и дата создания, причём её пользователь может указать сам, т.к. создание документа в TMS ≠ фактическая дата создания.

Также обязательно просим указать получателя - без него мы не узнаем, кому отправлять документ. Чтобы не вводить все реквизиты руками, ищем совпадения по названию огранизации или ИНН (такой паттерн уже используется внутри продукта) - это плюс к скорости заполнения и удобству.

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

Комментарий - свободное поле, куда пишут уточнения для получателя или внутренние пометки.

Основной файл - один обязательный. Это тот документ, который юридически значим и уходит через ЭДО. Инфо-иконка рядом объясняет эту роль, чтобы не возникало вопросов «а что именно подпишется».

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

Кнопка «Сохранить черновик» нужна тем, кто заполняет данные не за один подход (частый кейс в логистике), поэтому черновик можно отложить и вернуться позже.

Кнопка «Подписать документ» внизу инициирует подтверждение подписания с выбором сертификата, где ещё раз видно, какой документ сейчас уйдёт в ЭДО, и можно выбрать сертификат, которым он будет подписан.

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

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

К тому же, документ не всегда подписывается сразу и не всегда тем, кто его создал. Часто логист собирает комплект и сохраняет черновик, а подпись ставит бухгалтер или руководитель. Разделение на «создать» и «подписать» как раз поддерживает эту реальность: форма остаётся инструментом подготовки, а модалка – точкой, где человек с правом подписи делает финальный шаг.

Итак, пользователь уже сделал главное действие: документ отправлен в ЭДО и ушёл контрагенту на подпись. В этот момент в системе происходит две вещи.

1. TMS фиксирует документ как неизменяемый «отправленный» объект (по сути, это уже не черновик).
2. Через оператора ЭДО уходит пакет: основной файл, вложения и метаданные, и запускается ожидание ответа от другой стороны.

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

Дальше – текущий статус «Ожидает подпись исполнителя» и время последнего обновления: это главный ответ на вопрос пользователя «у кого сейчас мяч и актуальна ли информация».

Ниже – состав отправки: основной файл и вложения + «Скачать с ЭЦП». Это нужно, потому что пользователям часто нужен подписанный пакет «на руки» для архива/пересылки, даже если всё хранится в TMS.

Ключевой элемент здесь – линейка этапов подписания. Она объясняет, что уже подписано (грузоотправитель), кто следующий (исполнитель) и что будет дальше (грузополучатель и т. д.). Это снижает неопределённость и убирает лишние звонки «кто должен подписать?».

Редактирования нет, т.к. после отправки менять документ нельзя – вместо этого остаётся безопасное действие «Запросить аннулирование» на случай ошибки.

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

А что видит пользователь, для которого документ – входящий?

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

Сверху остаётся паспорт документа и блок файлов, а вот статус «Требуется ваша подпись» – это явный сигнал, что мяч на стороне исполнителя, и он должен либо подписать, либо отклонить.

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

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

Дальше по процессу: «Подписать» запускает КЭП и продвигает документ к следующему участнику; «Отклонить» фиксирует отказ и останавливает маршрут, чтобы отправитель видел, где и почему процесс встал.

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

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

Можно заметить, что не везде целевое действие на этапе получения документа – «Подписать». Вместо него мы выводим кнопку подтверждения получения. Она берётся из правил обмена у оператора ЭДО для конкретного типа документа.

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

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

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

Разберём шаг подписи на конкретном примере – подписание ЭТрн со стороны грузополучателя.

Это окно – последний шаг приёмки. Здесь грузополучатель фиксирует фактические параметры и сразу подписывает титул.

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

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

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