Интеграция ЭТрН с 1С: как автоматизировать сложные перевозочные сценарии

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

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

АЛЬПЕ Консалтинг решала такие задачи в двух проектах интеграции ЭТрН с 1С. В первом случае у заказчика была нетиповая 1С с собственными документами и двусторонним обменом данными. Во втором — типовая 1С, но сложный бизнес-процесс: одно задание на перевозку объединяло распоряжения разных юридических лиц, и из него нужно было формировать несколько электронных заказов-заявок и ЭТрН.

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

Почему простого подключения модуля часто недостаточно

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

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

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

Правильная интеграция должна отвечать на пять вопросов:

1. Какая операция в 1С запускает оформление перевозки.

2. Какие участники и юридические лица задействованы в сценарии.

3. Откуда берутся данные о грузе, маршруте, машине и водителе.

4. Какие сведения появляются или меняются во время рейса.

5. Какие результаты должны вернуться в 1С после выполнения перевозки.

Кейс 1. Нетиповая 1С и двусторонний обмен данными

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

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

В чём была сложность

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

Реквизиты в 1С могут:

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

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

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

После этого была составлена карта соответствия между нетиповыми реквизитами 1С и данными модуля логистики.

Почему потребовался обратный обмен

Особенность проекта — неоднократный двусторонний обмен между 1С и логистическим контуром.

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

Один из примеров — взвешивание прибывшего автомобиля. На момент создания документа в 1С был известен плановый вес. Фактические сведения появились позднее, уже после прибытия и взвешивания. Эти данные нужно было вернуть в учётную систему, потому что они влияли на дальнейшую обработку операции.

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

К таким событиям могут относиться:

• 🔹прибытие автомобиля;
• 🔹уточнение фактического веса;
• 🔹приёмка груза;
• 🔹изменение водителя;
• 🔹замена транспортного средства;
• 🔹изменение адреса доставки;
• 🔹расхождение между плановыми и фактическими данными.

Результат проекта

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

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

Что проверить, если у вас доработанная 1С

Возьмите одну реальную перевозку и проследите происхождение каждого значимого реквизита:

• 🔹откуда берётся грузоотправитель;
• 🔹как определяется грузополучатель;
• 🔹где хранится адрес погрузки и доставки;
• 🔹кто заполняет данные о машине и водителе;
• 🔹какой вес считается плановым;
• 🔹где появляется фактический вес;
• 🔹какие данные должны вернуться в 1С после рейса.

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

Кейс 2. Одно задание на перевозку и несколько юридических лиц

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

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

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

У каждого распоряжения была своя логика:

• 🔹организация, от имени которой оформляется перевозка;
• 🔹пункт погрузки;
• 🔹пункт доставки;
• 🔹получатель;
• 🔹состав груза;
• 🔹документ-основание;
• 🔹маршрут;
• 🔹участники перевозки.

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

Как была построена логика разделения

В проекте была настроена схема:

одно задание на перевозку → несколько электронных заказов-заявок → несколько ЭТрН

Система анализировала распоряжения внутри задания и формировала электронные документы по заданным правилам. Учитывались не только количество строк и тип документа-основания, но и более важные признаки:

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

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

В реализованном сценарии автоматическое разбиение выполнялось за несколько секунд. При этом такую оценку нельзя автоматически переносить на любую конфигурацию или объём данных: производительность зависит от конкретной базы, доработок, правил отбора и количества документов.

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

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

• 🔹какие распоряжения относятся к одной организации;
• 🔹сколько электронных заказов-заявок должно получиться;
• 🔹по каким признакам формируются отдельные ЭТрН;
• 🔹какие документы нельзя объединять;
• 🔹какие исключения должен обработать пользователь вручную;
• 🔹как сохраняется связь ЭТрН с документом-основанием.

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

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

Что проверить, если у вас несколько юрлиц

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

Проверьте:

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

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

Что объединяет оба проекта

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

Но техническое решение в обоих случаях начиналось с одного вопроса:

какая хозяйственная операция стоит за каждой будущей ЭТрН?

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

Например, товар может:

• 🔹отправляться покупателю со своего склада;
• 🔹забираться у поставщика;
• 🔹перемещаться между собственными складами;
• 🔹отгружаться со склада ответственного хранения;
• 🔹доставляться через экспедитора;
• 🔹перевозиться наёмным транспортом.

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

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

1. 🔹Какая операция в 1С запускает оформление перевозки.
2. 🔹Какие юридические лица и участники в ней задействованы.
3. 🔹Откуда поступают плановые данные о грузе, маршруте, машине и водителе.
4. 🔹Какие сведения появляются или меняются во время рейса.
5. 🔹Какие результаты должны вернуться в 1С для дальнейшей работы.

Такой разбор полезнее общего требования «интегрировать 1С с оператором». Последнее описывает канал обмена, но не отвечает, что именно через него передавать и какие действия должны происходить до и после отправки.

Что важно учесть при интеграции ЭТрН с 1С

1. Не все данные появляются одновременно

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

Если эти данные нужны для учёта, взаиморасчётов или анализа, их нужно возвращать в 1С автоматически или по понятному регламенту.

2. Нужно учитывать не только исходящие, но и входящие документы

Интеграция часто начинается с задачи «создать и отправить ЭТрН». Но компания может быть не только инициатором перевозки, но и получателем груза. В этом случае важно настроить работу с входящими титулами: кто их видит, кто подписывает, как документ связывается с учётными операциями и что происходит при расхождениях.

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

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

На практике причины могут быть разными:

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

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

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

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

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

5. Облачную 1С нужно проверять отдельно

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

Как запускать интеграцию ЭТрН с 1С

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

Такой пилот помогает проверить:

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

Пилот не заменяет интеграцию при большом потоке перевозок, но даёт материал для технического задания.

После этого можно переходить к проекту в 1С.

Этап 1. Описать сценарии

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

Этап 2. Составить карту данных

Для каждого реквизита нужно указать:

• 🔹источник в 1С;
• 🔹момент появления;
• 🔹правило передачи;
• 🔹необходимость преобразования;
• 🔹систему, в которую должен вернуться результат.

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

Этап 3. Проверить конфигурацию 1С

На этом этапе оценивают:

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

Этап 4. Зафиксировать правила формирования документов

Особенно важно сделать это, если:

• 🔹одно задание содержит распоряжения разных юридических лиц;
• 🔹данные поступают из нескольких внутренних процессов;
• 🔹перевозки оформляются по разным сценариям;
• 🔹часть данных меняется после отправки;
• 🔹есть несколько операторов или контрагентов с разными схемами ЭДО.

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

Этап 5. Протестировать полный маршрут

Проверять нужно не только создание ЭТрН, но весь процесс:

1. 🔹Формирование документа из 1С.
2. 🔹Отправка через оператора ИС ЭПД.
3. 🔹Получение документа контрагентом.
4. 🔹Подписание нужными участниками.
5. 🔹Обработка изменений в рейсе.
6. 🔹Возврат фактических сведений в 1С.
7. 🔹Связь ЭТрН с учётными документами.
8. 🔹Действия при ошибках и задержках.

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

Когда интеграция считается успешной

Критерий успешной интеграции простой:

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

Именно такой сквозной процесс, а не сам факт установки модуля, был целью обоих проектов АЛЬПЕ Консалтинг.

Чек-лист. Готовности к переходу на ЭТрН

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

Скачать чек-лист

Критерий готовности: компания может провести реальную перевозку через весь электронный процесс — от документа-основания и обмена с участниками до получения результата в учётной системе.

Нужно подготовить 1С или ERP к работе с ЭТрН? Разберём транспортные сценарии, распределим роли, определим интеграционный контур и составим план пилотного запуска.

Обсудить проект