Короткий ответ: обмен с государственной системой перевозочных документов из 1С собирается из трёх частей — модуль оператора внутри вашей конфигурации, справочники, приведённые в порядок, и регламент, кто в какой момент нажимает кнопку. Модуль есть почти у каждого оператора, и он не главная сложность. Две трети проекта уходит на то, чего в модуле нет: собрать перевозочный документ из ваших учётных данных и вернуть в 1С статусы подписания.
Считаем на модельной компании: перевозчик, 18 машин, 22 водителя, около 2 400 перевозок в год, 140 постоянных адресов погрузки и выгрузки, 60 грузоотправителей, учёт в 1С:Управление торговлей редакции 11, два юрлица. Все суммы — порядок величин на сентябрь 2026 года.
Отдельно оговорим, чем эта задача отличается от подключения обычного ЭДО. Там главная работа — сопоставление номенклатуры поставщика с вашей, и она разобрана в материале про способы обмена ЭДО с 1С. Здесь номенклатура второстепенна: перевозочный документ описывает не столько товар, сколько маршрут, машину, водителя и грузовые места. Ломается он поэтому в других местах, и опыт внедрения ЭДО с УПД помогает здесь меньше, чем кажется.
Где в 1С появляется перевозочный документ
Главное, что нужно понять до старта: единого документа-источника у перевозочной накладной нет. Она собирается из трёх разных мест учёта, и каждое из них живёт по своему графику.
- Заявка или заказ. Отсюда берутся стороны перевозки и их роли: кто грузоотправитель, кто грузополучатель, кто плательщик, кто экспедитор. В типовом заказе клиента этих ролей нет — там есть контрагент и адрес доставки строкой.
- Отгрузка. Отсюда берётся состав груза: позиции, количество, масса, объём, число грузовых мест и характер упаковки. Масса и места в типовой реализации чаще всего не заполнены, потому что бухгалтерии они не нужны.
- Рейс. Отсюда берутся машина, прицеп, водитель, точки маршрута и плановое время. В большинстве конфигураций рейса как объекта вообще нет: он живёт в голове диспетчера и в таблице.
Отдельная неприятность в том, что часть этих данных в учётной системе не живёт вовсе. Диспетчер держит рейсы в таблице или в голове, водителя назначает голосом, а фактическую точку заезда знает по памяти. Пока документ печатался, это работало: человек дописывал недостающее ручкой на бланке. Электронный документ дописать ручкой нельзя, и поэтому проект начинается не с модуля, а с вопроса, где у вас вообще ведётся рейс.
Отсюда и главное расхождение ожиданий. Заказчик считает, что подключение — это установка модуля и галочка в настройках. По факту установка занимает день, а следующие три недели уходят на то, чтобы в 1С появились те данные, которые модулю нечего взять. Ровно поэтому демонстрация у оператора всегда проходит гладко: на стенде справочники заполнены.
Схема: слева три подписанных блока — «заявка: стороны и роли», «отгрузка: состав, масса, места», «рейс: машина, прицеп, водитель, точки». Стрелки от них сходятся в центральный блок «перевозочный документ». Справа от него — «модуль оператора» и дальше «ГИС ЭПД». Под каждым из трёх левых блоков мелкая подпись, чего в типовой конфигурации нет: «ролей сторон нет», «масса и места не заполнены», «объекта рейса нет». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Конфигурации: где обмен встаёт штатно, а где нужна прослойка
Стоимость проекта определяет не оператор, а конфигурация. Ниже — как выглядит картина по основным вариантам. Трудоёмкость указана в часах инженера при ставке порядка 1 800–2 200 ₽ в час на сентябрь 2026 года и относится к доработкам, а не к настройке модуля.
| Конфигурация | Откуда берутся данные перевозки | Что обычно дописывают | Часов доработок |
|---|---|---|---|
| 1С:Бухгалтерия | Только реализация: машин, водителей и маршрутов в конфигурации нет | Справочники машин и водителей, реквизиты рейса, форма оформления перевозки | 40–80 |
| 1С:УНФ | Заказ покупателя и расходная накладная | Адреса как объекты вместо строк, привязка одного рейса к нескольким заказам | 30–60 |
| 1С:УТ 11 | Заказ клиента и реализация, доставка ведётся штатно | Сборка документа из заявки и отгрузки, возврат статусов подписания в заказ | 30–70 |
| 1С:ERP | Заказ, реализация и раздел управления перевозками | Роли сторон при нескольких юрлицах, увязка возврата документов с оплатой перевозчику | 60–160 |
| Отраслевые решения для перевозок на платформе 1С | Рейс уже есть в системе как объект | Обычно меньше всего, но поддержку конкретной сборки надо проверять отдельно | 0–40 |
Практический вывод: спрашивайте оператора не «поддерживаете ли вы 1С», а «покажите обмен на 1С:Управление торговлей редакции 11 версии такой-то». Разница между редакциями внутри одной конфигурации даёт разброс в десятки часов, и выясняется она на третьей неделе проекта, если не проверить на первой.
У большинства операторов это два разных продукта с разными лицензиями, и установленный у вас модуль обмена счетами-фактурами перевозочные документы не отправляет. Уточняйте это до закупки: строка «модуль уже стоит» в обосновании бюджета обычно означает, что стоит не тот.
Пять справочников, которые обязаны совпасть до старта
Это та часть, которую в коммерческих предложениях не считают, а в проекте она съедает больше всего календарного времени. Документ не уходит в систему, если хоть один обязательный реквизит пуст или заполнен в свободной форме.
- 1Машины и прицепы. Государственный регистрационный номер в едином формате, без пробелов, дефисов и латинских букв, подставленных вместо кириллицы. Прицеп — отдельная позиция, а не приписка к тягачу. На 18 машинах и 11 прицепах это полдня, на 120 — неделя.
- 2Водители. Данные должны совпадать с тем, как водитель заведён на Госуслугах и в приложении оператора: расхождение в инициалах или в отчестве останавливает подписание на погрузке. Сотрудники заводятся через Госуслуги, и это делается не из 1С.
- 3Адреса погрузки и выгрузки. Самая дорогая позиция. Адрес должен быть структурированным объектом, а не строкой «г. Москва, Каширское ш., у ворот 4». В модельной компании 140 постоянных адресов, по 12 минут на приведение каждого — 28 часов чистой работы, и её делает не программист, а человек, знающий, куда машина реально заезжает.
- 4Контрагенты и их роли. Грузоотправитель, грузополучатель, плательщик и экспедитор могут быть четырьмя разными юрлицами в одной перевозке. В типовом справочнике контрагентов такой разметки нет, её заводят отдельно — иначе документ соберётся не на то лицо.
- 5Номенклатура и грузовые места. Нужны масса брутто, число мест и вид упаковки. Это те поля, которые в учёте обычно пустые, потому что до сих пор никому не были нужны. Заполнять их придётся не разово, а поставить в регламент — иначе через месяц новые позиции снова пойдут без массы.
Совет из практики: начинайте справочники до выбора оператора. Эта работа не зависит от того, кого вы выберете, она всё равно понадобится, и выполненная заранее она снимает три недели с критического пути проекта. Обратный порядок — сначала договор, потом обнаружение, что адресов в системе нет, — стандартная причина срыва сроков.
Две колонки. Левая «как в учёте сейчас»: одно поле со строкой «г. Москва, Каширское ш., 4-й въезд, спросить Сергея», помечено крестиком. Правая «как нужно»: список отдельных подписанных полей — регион, населённый пункт, улица, дом, код по классификатору, отдельная строка «точка заезда» и отдельная «контактное лицо», помечено галочкой. Внизу подпись «140 адресов × 12 минут = 28 часов». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Подписи, доверенности и Госуслуги
Вторая точка, где проект упирается не в код. Подписи в перевозочных документах устроены по ролям, и каждая роль настраивается отдельно.
- Руководителю нужна усиленная квалифицированная подпись. Она же требуется сотрудникам, ответственным за погрузку и выгрузку, — это обычно кладовщик и начальник склада, а не только директор.
- Остальным сотрудникам достаточно сертификата, выданного по машиночитаемой доверенности, либо простой подписи через Госключ. Диспетчер, который оформляет документ в 1С, попадает именно в эту категорию.
- Водителю усиленная квалифицированная подпись не нужна. Он подписывает в приложении оператора, и это отдельный контур, который с 1С напрямую не связан.
- Доверенности надо где-то хранить и подставлять. Проверьте до закупки, умеет ли модуль оператора работать с машиночитаемыми доверенностями внутри 1С или их придётся выбирать вручную на каждом документе. Разница — минута на каждой перевозке, то есть 40 часов в год на модельном объёме.
Порядок подключения одинаков для всех: выбор оператора, соглашение с ним, заведение сотрудников через Госуслуги, настройка подписей и только потом тестовый обмен. Третий шаг делается вне вашей учётной системы и вне зоны ответственности подрядчика по 1С — и именно на нём проекты встают, потому что его никто не поставил в план.
Что модуль не делает
Модуль оператора решает ровно одну задачу: передать сформированный документ и принять ответ. Всё остальное — работа на вашей стороне, и ниже перечислено то, что заказчики регулярно считают входящим в поставку.
- Сопоставление позиций с данными грузоотправителя. Если груз описан у отправителя одними словами, а у вас другими, документ соберётся, но приёмка будет спорной. Автоматически это не решается.
- Автоподбор машины и водителя под рейс. Модуль берёт то, что уже указано. Планирование загрузки — отдельная задача и отдельная система.
- Контроль возврата подписанных документов. Модуль покажет статус по одному документу. Ответ на вопрос «по каким из 200 перевозок этого месяца нет подписи получателя и какие из них мы уже оплатили перевозчику» строится на вашей стороне.
- Разбор расхождений при приёмке. Получатель принял не всё — модуль отразит факт. Превратить это в корректировку реализации, претензию и правильную сумму к оплате должна учётная система.
- Регламент и дисциплина. Документ, зависший неподписанным на третьи сутки, выглядит в интерфейсе точно так же, как подписанный вчера. Кто за ним следит, в какой срок и кто заменяет отсутствующего — пишете вы.
Сам по себе этот список не претензия к операторам: они и не обещают ничего из перечисленного, просто заказчик читает «полная интеграция с 1С» и достраивает остальное в уме. Проявляется это одинаково — через месяц после запуска выясняется, что документы уходят, а закрыть месяц по-прежнему нельзя, потому что никто не знает, по каким рейсам подписи собраны. Дешевле всего обнаружить это до договора, а не после.
В договоре с подрядчиком полезно записать не «настройка обмена с ГИС ЭПД», а пять конкретных сценариев с ожидаемым результатом: оформление перевозки из отгрузки, возврат статусов в 1С, отчёт по неподписанным документам, отражение расхождения при приёмке, выгрузка архива. Формулировка «настройка обмена» считается выполненной в момент, когда первый документ ушёл, — а всё остальное окажется дополнительной работой.
Пусконаладка: тестовый контур и три пробных рейса
Порядок, который мы считаем рабочим на парке от десяти машин. Сроки указаны для модельной компании; на большем парке растёт не столько программирование, сколько справочники и обучение.
- 1Неделя 1. Обследование и схема обмена
Разбираем, из каких документов у вас реально собирается перевозка, кто её оформляет и в какой момент. На выходе — схема сборки документа и список того, чего в учёте не хватает. Здесь же выясняется, нужен ли вам обмен вообще или хватит кабинета оператора.
- 2Недели 1–3. Справочники
Машины, прицепы, водители, адреса, роли контрагентов, масса и грузовые места. Работа идёт параллельно с остальным и не требует установленного модуля, поэтому её запускают первой. Приёмка этапа — выгрузка справочника адресов без единой строки в свободной форме.
- 3Недели 2–4. Установка модуля и настройка в тестовом контуре
Модуль ставится на копию базы, настраивается соответствие ваших реквизитов полям документа, подключается тестовая среда оператора. Боевую базу на этом этапе не трогают. Оператор без тестового контура вынуждает делать этот шаг на живых рейсах — это отдельный аргумент при выборе.
- 4Неделя 4. Три пробных рейса
Именно три, а не один: один рейс покажет, что схема работает, а расхождения вылезают на втором и третьем. Берите разные случаи — простую перевозку, перевозку с несколькими точками выгрузки и перевозку с расхождением при приёмке.
- 5Неделя 5. Разбор расхождений и доработка
Собираем всё, что не сошлось: незаполненные реквизиты, адреса, на которые машина заезжает не с той стороны, роли сторон, подписи не тех сотрудников. Это самый полезный этап проекта, и сокращать его — значит перенести те же вопросы в боевую эксплуатацию.
- 6Неделя 6. Боевой запуск и обучение
Запускаемся не всем парком сразу, а одним направлением или одним диспетчером на неделю. Обучение водителей делается на погрузке, а не в переговорной: пять минут на реальном рейсе заменяют час презентации.
Горизонтальная лента времени на шесть недель с параллельными дорожками. Дорожка «справочники» тянется с 1-й по 3-ю неделю и выделена как самая длинная. Дорожка «модуль и тестовый контур» — со 2-й по 4-ю. Отметки-вехи: на 4-й неделе «три пробных рейса», на 5-й «разбор расхождений», на 6-й «боевой запуск одним направлением». Сбоку вынос: «заведение сотрудников через Госуслуги — вне 1С, ставить в план отдельно». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Смета и окупаемость: 352 800 ₽ и 13,4 месяца
Считаем ту же модельную компанию: 18 машин, 2 400 перевозок в год, 1С:УТ 11, два юрлица, 140 адресов. Ставка инженера в примере — 2 000 ₽ в час, ставка сотрудника, который приводит в порядок справочники, — 1 800 ₽.
Теперь эффект. Он складывается из трёх строк, и ни одна из них не про «ускорение бизнеса» — только про часы, которые перестают тратиться. Перебивка данных диспетчером: 200 перевозок в месяц по 9 минут — это 30 часов, при ставке 700 ₽ получается 21 000 ₽. Переоформление документов из-за ошибок в адресах и реквизитах: 14 случаев в месяц по 40 минут — около 6 500 ₽. Сверка возврата подписанных документов перед оплатой перевозчикам: 12 часов бухгалтера по 900 ₽ — 10 800 ₽.
Тринадцать месяцев — честная цифра, и мы не собираемся её улучшать подбором допущений. Вывод из неё другой: на объёме 2 400 перевозок в год обмен с 1С делают не ради экономии. Обязанность оформлять перевозочные документы в электронном виде наступила 1 сентября 2026 года, и выбор стоит не между «внедрять или нет», а между ручным оформлением в кабинете оператора и обменом из учёта. Экономия здесь — приятное следствие, а не обоснование. Порог, где обмен окупается быстро, — около 600 перевозок в месяц: те же строки дают 97 600 ₽ в месяц, и смета порядка 420 000 ₽ возвращается за 4,3 месяца.
| Парк | Порядок сметы внедрения | Срок пусконаладки |
|---|---|---|
| До 5 машин | Обмен не нужен: кабинет оператора | — |
| 5–30 машин | 250 000–450 000 ₽ | 5–8 недель |
| 30–120 машин | 450 000–900 000 ₽ | 8–14 недель |
| Свыше 120 машин | Считается отдельно, обычно с заменой контура планирования рейсов | от 3 месяцев |
Три места, где проект встаёт
За последний год это три самые частые причины, по которым сроки уезжают вправо. Ни одна из них не техническая.
- 1Справочники некому вести. Программист адреса привести в порядок не может: он не знает, что на этот склад заезжают с обратной стороны и что фактический пункт выгрузки на километр дальше юридического адреса. Нужен человек из компании с выделенным временем, и его надо назначить до старта, а не искать на третьей неделе.
- 2Сотрудники не заведены через Госуслуги. Шаг не относится ни к 1С, ни к подрядчику, поэтому в план его не ставят. Отдельно проверьте, что у ответственных за погрузку есть действующая усиленная квалифицированная подпись, а не истекшая в прошлом квартале.
- 3Владельца процесса нет. Перевозочный документ трогают диспетчер, склад, бухгалтерия и водитель — четыре зоны ответственности. Если не назначен один человек, за которым закреплён весь маршрут документа, каждое расхождение будет обсуждаться заново и заканчиваться ничем.
Столбчатая диаграмма из семи сегментов общей суммой 352 800 ₽: «обследование 40 000», «модуль 55 000», «справочники 82 800», «сборка документа 72 000», «возврат статусов 48 000», «тестовый контур и рейсы 30 000», «обучение 25 000». Сегмент «справочники» выделен штриховкой и подписан «делает сотрудник компании, а не подрядчик». Внизу подпись «18 машин, 2 400 перевозок в год, 1С:УТ 11». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Когда обмен с 1С не нужен
Отказ от интеграции — нормальное инженерное решение, а не признак отсталости. Вот случаи, где мы сами советуем обойтись кабинетом оператора.
- Меньше 15 перевозок в сутки. Ниже этого порога диспетчер оформляет документы руками быстрее, чем окупается поддержка обмена. Двухчасовая ежедневная перебивка — примерная граница.
- Учёт на платформе, которую вы всё равно меняете в этом году. Настраивать обмен на базе, которая уедет через полгода, значит оплатить работу дважды. Сначала платформа, потом обмен.
- Перевозки оформляет ваш подрядчик. Если возит наёмный перевозчик и документ собирает он, ваша роль сводится к подписи ответственного за погрузку. Интеграция здесь не экономит ничего.
- Справочников нет и вести их некому. Обмен без порядка в адресах и машинах не заработает, а появится только новая точка отказа. Сначала справочники и человек, который за них отвечает, потом обмен.
Модуль устанавливается за день. Проект длится шесть недель, потому что все эти недели в учёте появляются данные, которых там раньше не было.
