ЭТрН: сценарий создания накладной, настройки процессов и межоператорского взаимодействия

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

Актуальность. Правовая часть — по состоянию на август 2026 года, с обязательностью применения с 01.09.2026 (Федеральный закон от 07.06.2025 № 140-ФЗ). Форматы и порядок межоператорского обмена подлежат повторной сверке перед запуском.

---

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

Схема прохождения документа: 1С клиента → модуль ЭТрН → оператор ИС ЭПД → ГИС ЭПД → оператор ИС ЭПД контрагента → учётная система контрагента.

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

1. Наличие настроенного обмена по УПД не означает готовности к ЭТрН. Под перевозочные документы требуется отдельное подключение к аккредитованному оператору ИС ЭПД.
2. Ситуация «у контрагента бухгалтерия в одном операторе, перевозка — в другом» является штатной, а не конфликтом. Это разные контуры, и в карточке контрагента для накладной указывается идентификатор именно перевозочного контура.

---

1.1. Организационная подготовка

1.2. Техническая подготовка

• Платформа. 1С:Предприятие 8.3, управляемые формы, версия платформы 8.3.20 и выше. Обычные формы, 7.7 или низкий режим совместимости — отдельная проектная оценка (внешняя обработка, коннектор либо промежуточная типовая база).
• Криптография. На сервере или рабочих местах установлены СКЗИ и сертификаты. При файловой базе на сервере и доступе через RDP работа поддерживается — трансляция смарт-ключей возможна, особенности фоновых заданий уточняются при внедрении.
• Подписи. Квалифицированная электронная подпись обязательна. Для сотрудника — машиночитаемая доверенность (МЧД); для руководителя организации доверенность не требуется. Работа без ЭП невозможна в принципе.
• Договор с оператором ИС ЭПД. Заключается клиентом напрямую, пакет титулов оплачивается оператору. На начальном этапе модулем поддержаны Контур.Логистика, Калуга-Астрал, СберКорус, ЭДИ Софт.

1.3. Выбор модели подписания

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

Автоматическая отправка возможна только при двух одновременных условиях: подпись размещена на сервере и определено событие-триггер в 1С (например, проведение реализации).

---

Шаг 1. Установка

Модуль ставится расширением на управляемых формах в ту базу, где организация формирует транспортные документы (она не всегда совпадает с базой модуля ЕИС — определяется на обследовании). Работа существующей функциональности не нарушается; при установленном 1С-ЭДО модуль не перехватывает документы стороннего обмена.

Шаг 2. Подключение провайдера

В настройках модуля указывается оператор ИС ЭПД и параметры подключения. Мультипровайдерная шина (МПШ) позволяет подключить несколько операторов одновременно — бизнес-процесс при этом остаётся единым. Побочный полезный эффект: при недоступности одного оператора документы направляются через другого без остановки отгрузок.

Шаг 3. Настройка документа-основания и триггера

• Накладная формируется на основании документа учётной системы, по аналогии с УПД. Функции создания «с нуля» нет: создание массовое.
• Основанием может быть реализация, «Перемещение», нетиповой документ доработанной конфигурации — настраивается под фактически используемый тип.
• Задаётся триггер — условие отбора документов-оснований, подлежащих обработке.
• Основанием может служить и документ, по которому уже сформирован УПД в модуле ЕИС; задвоение объектов исключено, оба документа оформляются на одной реализации.

Шаг 4. Сопоставление полей и постоянные значения

• Номенклатура берётся из справочника сопоставления, ведущегося в модуле ЭДО (связка позиций 1С и ЕИС).
• При поставке по контракту 44-ФЗ табличная часть реализации конвертируется в структуру контракта из модуля ЕИС; если контракт в ЕИС не размещён — данные берутся из справочника номенклатуры 1С.
• Неизменные реквизиты (тара, способ упаковки для наливных грузов и т. п.) задаются как постоянные значения и подставляются автоматически.
• Даты и время убытия/прибытия ТС подгружаются автоматически при наличии данных в учётной системе.

Шаг 5. Заполнение карточек контрагентов ФНС ID

Ключевой шаг для маршрутизации — подробно разобран в разделе 4.

Шаг 6. Права, организации, фильтры

• Мультиорганизационность поддержана: в журнале есть колонка и фильтр по организации; при необходимости полного разделения под каждую организацию настраивается отдельный процесс.
• Настраиваются пользовательские фильтры («Мои фильтры»): по контрагенту, по организации либо их сочетанию, с доступностью только автору либо всем пользователям.
• Действия пользователей фиксируются в модуле по логике, принятой в модуле ЕИС.

Шаг 7. Демо-режим и пилот

Сначала — демонстрационный режим (интерфейс и процесс без реальной отправки). Затем ограниченный пилот: один маршрут, один контрагент, с последующим масштабированием.

Условия входа в пилот:

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

---

3.1. Базовая цепочка титулов

Порядок подписания неизменен независимо от количества участников: Т1 → Т2 → Т3 → Т4 (с ветвлениями на Т7/Т8/Т9).

3.2. Пошаговый сценарий (сторона грузоотправителя)

Шаг 1. Событие в 1С. Менеджер проводит реализацию (или иной документ-основание). Срабатывает триггер, настроенный на шаге 3 раздела 2.

Шаг 2. Формирование Т1. Модуль создаёт титул грузоотправителя: реквизиты сторон, груз, тара, адреса, сведения о ТС и водителе, даты/время убытия. Постоянные значения подставляются автоматически, недостающие поля подсвечиваются.

Шаг 3. Определение маршрута доставки титула. Модуль читает ФНС ID перевозчика и грузополучателя из карточек контрагентов и определяет, через какого оператора уйдёт документ (см. раздел 4).

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

• Сервер: документ подписывается КЭП автоматически, при подписании сотрудником — с приложением МЧД.
• Клиент: пользователь подключает носитель и подтверждает отправку вручную.

Шаг 5. Отправка и регистрация в ГИС ЭПД. Титул уходит оператору ИС ЭПД, оттуда — в ГИС ЭПД. Система присваивает накладной уникальный идентификатор и начинает хранить цепочку титулов.

Шаг 6. Т2 — перевозчик. Перевозчик (как правило, водитель как уполномоченный сотрудник) подписывает приём груза. Статус меняется в 1С в реальном времени — вход в кабинет оператора не требуется.

Шаг 7. Рейс. При проверке на дороге предъявляются сведения в электронном виде. При изменении обстоятельств:

• переадресовка — Т9 (грузоотправитель) и Т7 (перевозчик);
• эстафета — Т8 при замене ТС либо водителя.

Обе ветки формируются модулем и не требуют создания новой накладной.

Шаг 8. Т3 — грузополучатель. У получателя входящий титул отображается в журнале модуля. Данные о грузе автоматически подставляются из Т1 с возможностью ручной корректировки. После подписания на основании Т3 в учётной системе формируется документ типа «Приобретение товаров и услуг» (наименование зависит от конфигурации); поддерживается и обратное сопоставление данных накладной в нужный документ 1С.

Шаг 9. Т4 — выдача груза перевозчиком. Цепочка закрывается.

Шаг 10. Контроль. Дашборд отслеживания накладных показывает статусы и незакрытые цепочки титулов. Срок хранения — 5 лет, выгрузка архива на серверы организации технически реализуема.

3.3. Параллельный бухгалтерский контур

На той же реализации формируется УПД и уходит через оператора ЭДО в адрес ФНС. Эти два потока не связаны напрямую: накладная подтверждает факт перевозки, УПД — реализацию. В одной базе они ведутся одновременно, через разных операторов, без раздвоения процессов — за это отвечает МПШ.

---

4.1. Что это

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

Аналогия для клиента: ИНН отвечает на вопрос «кто это», ФНС ID — на вопрос «куда именно доставить документ».

4.2. Какую задачу решает в модуле

1. Маршрутизация. Модуль по ФНС ID контрагента определяет, через какого оператора передать титул. Именно поэтому в карточке контрагента указывается идентификатор перевозочного контура, а не бухгалтерского — если у контрагента для УПД один оператор, а для ЭТрН другой, ошибка в этом поле означает недоставку.
2. Идентификация отправителя входящего документа. По ФНС ID система определяет, с какого оператора поступил документ. Приём ЭТрН от партнёров технически одинаков и через Калуга-Астрал, и через СБИС — механизм получения не зависит от того, какой оператор у вас.
3. Устойчивость к смене оператора у контрагента. Если контрагент переходит, например, со СБИС на Такском, достаточно изменить ФНС ID в карточке в 1С. Повторное внедрение, перенастройка процессов и переобучение сотрудников не требуются.
4. Устойчивость к смене оператора у вас. Бизнес-процесс реализован в учётной системе клиента и от оператора не зависит: меняется подключение в настройках, процессы, шаблоны и сопоставление полей сохраняются.

4.3. Что ФНС ID не делает

• Не заменяет договор с оператором ИС ЭПД.
• Не создаёт сам по себе связь с контрагентом: наличие корректного ФНС ID необходимо, но недостаточно — требуется настроенная роуминговая связка (раздел 5).
• Не переносится между контурами: идентификатор бухгалтерского ящика не годится для перевозочных документов.

4.4. Регламент ведения ФНС ID (рекомендуемый)

---

5.1. Нормативная рамка

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

5.2. Практическое ограничение, о котором нужно предупреждать клиента

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

5.3. Механика «нахождения» друг друга — по шагам

Шаг 1. Обмен идентификаторами. Стороны сообщают друг другу ИНН/КПП, наименование оператора ИС ЭПД и ФНС ID перевозочного ящика. Это минимальный набор; без наименования оператора заявка на роуминг не оформляется.

Шаг 2. Заявка на роуминговую связку. Инициатор подаёт своему оператору заявку с реквизитами контрагента и его ФНС ID. Оператор инициатора обращается к оператору контрагента.

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

Шаг 4. Активация связки. После подтверждения пара «мы ↔ контрагент» становится активной. Срок зависит от пары операторов и составляет от одного рабочего дня; на этот срок закладывается запас в графике внедрения.

Шаг 5. Внесение ФНС ID в 1С. Идентификатор фиксируется в карточке контрагента — с этого момента модуль маршрутизирует титулы автоматически.

Шаг 6. Тестовый обмен. До первой юридически значимой отгрузки прогоняется контрольный документ по маршруту. Техническую зрелость взаимодействия конкретной пары операторов рекомендуется проверять на пилотном маршруте до масштабирования.

Шаг 7. Дальнейшая передача документов. В рабочем режиме путь такой:

1С грузоотправителя → модуль ЭТрН → оператор ИС ЭПД «А» → ГИС ЭПД
                                                              ↓
      1С грузополучателя ← модуль ЭТрН ← оператор ИС ЭПД «Б» ←┘

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

5.4. Распределение ответственности при внедрении

5.5. Типовые ошибки и их проявления

5.6. Реестр роуминговых связок (рекомендуемая форма ведения)

Реестр ведётся с начала пилота: он же становится планом масштабирования — контрагенты подключаются по убыванию объёма отгрузок.

---

До пилота

• [ ] Классифицированы перевозки, определены роли по каждому потоку
• [ ] Заключён договор с оператором ИС ЭПД, оплачен пакет титулов
• [ ] Выпущены КЭП, оформлены МЧД на подписантов
• [ ] Установлены СКЗИ и сертификаты (сервер / рабочие места)
• [ ] Выбрана модель подписания (сервер / клиент)
• [ ] Модуль установлен в нужную базу, подключён провайдер
• [ ] Настроены документ-основание, триггер, сопоставление полей, постоянные значения
• [ ] Заполнены ФНС ID перевозочного контура по пилотным контрагентам
• [ ] Настроена и подтверждена первая роуминговая связка
• [ ] Пройден демо-режим, проведено обучение пользователей

Пилот

• [ ] Один маршрут, один контрагент, один-два постоянных перевозчика
• [ ] Пройдена полная цепочка Т1 → Т2 → Т3 → Т4
• [ ] Отработана ветка переадресовки (Т9/Т7) или эстафеты (Т8)
• [ ] Проверено формирование документа приобретения на основании Т3
• [ ] Проверен дашборд статусов и порядок действий при ошибке в данных

Масштабирование

• [ ] Ведётся реестр роуминговых связок, связки настраиваются клиентом самостоятельно
• [ ] Подключены остальные типы маршрутов и документы-основания
• [ ] Настроена автоотправка по потоку (при серверной подписи)
• [ ] Согласован порядок работы с архивом и выгрузкой (хранение 5 лет)

---

«У нас уже есть ЭДО, зачем ещё подключение?» — Оператор ЭДО обслуживает счета-фактуры и УПД и обменивается с ФНС. Перевозочные документы он не обрабатывает: их ведёт оператор ИС ЭПД, работающий с ГИС ЭПД Минтранса. Это разные контуры, и под ЭТрН нужно отдельное подключение.

«У контрагента другой оператор — значит, работать не сможем?» — Сможем. Межоператорский обмен через ГИС ЭПД обязателен для всех операторов ИС ЭПД, а идентификация идёт по сквозному ФНС ID. Единственное требование — заранее настроить роуминговую связку с этим контрагентом: автоматически она не появляется.

«Если мы поменяем оператора, всё придётся внедрять заново?» — Нет. Бизнес-процесс живёт в вашей 1С и от оператора не зависит: меняется подключение в настройках, процессы, шаблоны, сопоставление полей и порядок работы пользователей сохраняются, переобучение не требуется.