Задача
С 1 сентября 2026 года электронная транспортная накладная и другие экспедиторские документы принимаются только в электронном виде, а с мая экспедиторы обязаны состоять в реестре ГосЛог. Мой заказчик ведет всю операционку по перевозкам в CRM. Битрикс24 из коробки выдает только PDF-документы, но для отправки в систему нужен структурированный XML-файл строго по формату ФНС.
Без интеграции менеджеры делали двойную работу. Сначала они заполняли карточку сделки, а затем шли в кабинет оператора ЭДО и руками перебивали туда реквизиты четырех-пяти компаний, данные водителя, машины, адреса и информацию о грузе.
Проблема усугублялась тем, что данные в Битрикс24 разбросаны по смарт-процессам (водители, карточки адресов). Адреса хранились свободной строкой, тогда как схема ФНС требует жесткой нормализации по ФИАС, с индексами и кодами регионов. Дополнительно схема требует использования жестких классификаторов (упаковка по кодам UN/CEFACT, типы владения ТС) и фиксированных формулировок.
Для кого этот кейс: экспедиторы и транспортные компании на Битрикс24, которым нужно формировать XML-файлы для ЭДО без ручного переноса данных.
Решение
Я реализовал генерацию документов прямо в CRM. Технический стек: облачный Битрикс24, бизнес-процесс с кнопкой в сделке, интеграция с DaData и строгая проверка файлов по схемам ФНС.
Если сделки ведутся в Битрикс24, а не в 1С
У клиента есть 1С, но вся операционка по перевозкам - карточка сделки, водитель, адреса, груз - живет в Битрикс24. Если формировать накладную из 1С, менеджеру придется перебивать все данные второй раз. Я выстроил логику так, чтобы документ рождался там, где лежат исходные данные.
Как это работает: менеджер нажимает кнопку в карточке сделки. Запускается бизнес-процесс, который передает данные в сценарий автоматизации. Сценарий собирает XML-файл и прикрепляет его обратно в карточку сделки. Система формирует файл, но не отправляет его автоматически - менеджер сам загружает готовый XML в СБИС, а поручение грузит клиент в свой Диадок.
Схема ФНС содержит 318 полей, но реально для работы нужны 30, остальное относится к неактивным веткам (например, опасные грузы). Менеджер заполняет только свое, остальное система тянет из сделки одним общим запросом. За один раз скрипт забирает данные сделки, реквизиты компаний, карточку водителя с машиной, адреса и сотрудников склада.
Обязательные поля проверяются до сборки файла. Если нет телефона или не выбрана упаковка, ошибка пишется комментарием в сделку. Битый файл не попадет в кабинет оператора, потому что просто не соберется.
Для адресов я подключил бесплатный сервис DaData. Он приводит адреса к стандарту государственного реестра (ФИАС) и разбирает ФИО. Я добавил контроль качества: система сверяет номер дома до и после автоматической обработки. Если есть расхождения, в сделку падает понятный комментарий. Если адрес разбирается только до населенного пункта, документ уходит с текстовым форматом адреса (схема это разрешает) и предупреждением.
Справочники подтягиваются динамически из полей Битрикса (марка, тип ТС, тип владения). Госномера чистятся от мусора, латиница переводится в кириллицу. Поскольку налоговая требует файлы в строгой кодировке, я написал скрипт, который правильно кодирует документ, чтобы система ЭДО приняла его с первого раза без ошибок.
Три документа: ЭТрН, заказ-заявка, поручение экспедитору
Я автоматизировал сборку трех документов: ЭТрН (КНД 1110339), заказ-заявка (КНД 1110361, приказ ЕД-7-26/108@) и поручение экспедитору (КНД 1110486, приказ ЕД-1-26/277@).
Второй этап (заказ-заявка и поручение) я собрал на той же базе. Это один сценарий с двумя входами. У них общая проверка адресов и справочники, но свои сборщики под каждую схему. Подписанты разведены по документам: клиент, экспедитор, владелец склада.
На этапе приемки готовые файлы были прогнаны через два независимых инструмента проверки: локально по официальным схемам ФНС и через онлайн-валидатор Диадока.
Результат
Каждый из трех документов (ЭТрН, заказ-заявка, поручение экспедитору) формируется своей отдельной кнопкой прямо из карточки сделки. Менеджер скачивает готовый файл и загружает его в СБИС, а клиент в свой Диадок.
Что получилось:
- Мгновенная генерация. Сборка любого из документов занимает до 2 секунд.
- Исключение рутины. Из 318 полей, которые требует схема ФНС, менеджер заполняет только 30. Остальной массив информации система собирает и подставляет сама.
- 100% приемка файлов в ЭДО. Документы проходят проверку ФНС с первого раза и успешно загружаются в СБИС и Диадок на живых сделках.
- Защита от ошибок. Если в сделке нет телефона, не выбрана упаковка или указан адрес без дома, система покажет предупреждение сразу. Менеджер исправляет данные до того, как попытается загрузить битый файл в систему.
- Без смены инфраструктуры. Вся логика работает на стандартном облачном тарифе Битрикс24.
- Быстрый старт. Первая накладная была запущена в работу за 3 рабочих дня, остальные экспедиторские документы - еще за несколько дней на уже готовой базе.
