С 1 сентября 2026 года бумажные транспортные накладные становятся вне закона. Большинство компаний либо ещё не начали готовиться, либо готовятся неправильно. Делюсь тем, что понял за 10+ проектов с грузоотправителями на 1С ERP.
До 1 сентября 2026 — меньше полугода. Компании, которые начнут в мае-июне, будут стартовать в условиях жёсткого цейтнота.
Почему «просто подключить ЭДО» — это ловушка
Когда компании слышат про 140-ФЗ, первая реакция обычно одна: «окей, подключим оператора ЭДО и всё». Логика понятна — закон требует электронные документы, оператор ЭДО их создаёт.
Но это решает только юридическую часть. Оно не решает операционную.
Вот что происходит на практике, когда компания подключает только адаптер ЭДО без системы управления перевозками:
Три архитектуры перехода: что работает
За эти проекты я выработал чёткую классификацию. Есть три принципиально разных подхода к переходу на ЭТРН в 1С ERP. Каждый имеет право на существование — но у каждого своя цена.
Модуль встраивается в 1С ERP, формирует перевозку из заказов, автоматически объединяет их в рейсы, работает с перевозчиками через шлюз и на основе их данных формирует ЭТРН.
К управлению перевозками добавляется Адаптер Контур Логистика — он работает параллельно с Pooling 1С и берёт на себя весь документооборот.
Бронирование — это и есть перевозка. Когда Pooling 1С формирует бронирование, оно уже содержит все нужные данные: информацию о грузе, данные от перевозчика, маршрут, тип документооборота.
Адаптер Контур Логистика настроен на работу именно с объектом «Бронирование» из Pooling. Это значит: ЭТРН в адаптере не нужно настраивать с нуля. Связка уже знает, откуда брать каждое поле. Внедрение быстрее, поддержка проще.
Контур
Самый быстрый путь к соответствию закону на бумаге. На практике — источник скрытых проблем, которые обнаруживаются после запуска.
Без Pooling адаптер не знает, что такое «перевозка». Ему нужно объяснить: из каких документов 1С брать данные, какое поле — откуда, как собрать ЭТРН из разрозненных объектов системы.
В результате: бизнес тратит время на ручную настройку маппинга полей. А потом — на поддержку, потому что при изменении процессов ЭТРН перестаёт формироваться корректно. Каждое обновление 1С или изменение схемы документов — потенциальный инцидент.
Один и тот же перевозчик может выступать как перевозчик (нужна ЭТРН) или как экспедитор (нужны поручение + расписка). Каждый сценарий требует разных документов, по-разному заполненных. Без автоматического определения роли сотрудник логистики вынужден каждый раз уточнять у перевозчика — и только тогда может выпустить корректный пакет. Это блокирует отгрузку.
Каждая розничная сеть может предъявлять особые требования к оформлению ЭТРН: кто-то требует GLN, кто-то — номера DESADV и ORDERS в информационных полях. Адаптер без Pooling про эти требования ничего не знает. Итог: ЭТРН оформлена некорректно, товар не принимают на складе сети. Бизнес узнаёт об этом уже при приёмке.
Контур
Сравнение трёх архитектур
4 вещи, которые я понял за эти проекты
Что происходит, если ничего не делать
Это не страшилки. Это конкретика из закона.
Итог
Если вы работаете на 1С ERP и отправляете 100+ перевозок в месяц — у вас есть три пути. Я прошёл все три с разными клиентами.
Идите сразу на архитектуру 2. Это дороже, чем просто подключить ЭДО. Но это единственный вариант, который закрывает задачу полностью — и не потребует переделки через год, когда обнаружатся пробелы.
Мы работали с ZET Holding, Masterfood, Адресник, Protein Rex, Mai Foods, SPLAT и другими компаниями. Каждый раз разбирали архитектуру под конкретные процессы. Универсального ответа нет — но правильный вопрос всегда один: вы хотите просто соответствовать закону, или хотите заодно улучшить логистику?
Если второе — это реально, и это не сильно дороже первого.
