← На главную

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

Различие форматов: почему путают ЭТрН и ЭЗЗ

Для правильной настройки бизнес-процесса в первую очередь проанализируем, о каком именно документе идет речь — об электронной транспортной накладной (ЭТрН) или об электронном заказе-заявке (ЭЗЗ). Форматы ФНС для этих документов имеют принципиальные различия в части распределения ответственности за ввод информации:

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

Вариант 1. Заполнение через машиночитаемую доверенность (МЧД)

Если требуется, чтобы квалифицированные операторы или диспетчеры грузоотправителя полностью формировали и подписывали Титул 2 за перевозчика, рассмотрим наиболее юридически чистый способ — работу по схеме делегирования полномочий через МЧД.

Любое юридическое лицо или индивидуальный предприниматель-перевозчик имеет право выдать машиночитаемую доверенность единого формата (МЧД формата 003) на физическое лицо — сотрудника грузоотправителя. В полномочиях доверенности прописывается право подписания электронных перевозочных документов и соответствующих титулов.

Разберем по шагам, как организовать эту схему в среде 1С:

1. Перевозчик подписывает своей квалифицированной электронной подписью (КЭП) МЧД, выданную на конкретного диспетчера грузоотправителя, и регистрирует ее в распределенном реестре ФНС.
2. В информационной базе 1С грузоотправителя организация перевозчика заводится в справочник Организации (без ведения по ней регламентированного бухгалтерского и налогового учета).
3. Для созданной организации настраивается отдельная учетная запись участника ЭДО через модуль 1С-ЭПД.
4. К учетной записи привязываются личный сертификат физического лица сотрудника грузоотправителя и зарегистрированная МЧД от перевозчика.
5. Диспетчер грузоотправителя при погрузке переключается на контекст организации перевозчика, штатно заполняет Титул 2 со всеми данными автомобиля и водителя и подписывает его личной подписью на основании доверенности.

Такой подход полностью освобождает водителя и транспортную компанию от работы с интерфейсами учетных систем и исключает риски зависания документов из-за отсутствия связи у водителя в рейсе.

Вариант 2. Обмен черновиками титулов через оператора

Рассмотрим сценарий, когда перевозчик согласен самостоятельно подписывать титул (например, через Госключ или мобильное приложение), но категорически отказывается заполнять поля вручную. В этом случае грузоотправитель может сформировать предзаполненный черновик Титула 2.

Здесь важно учитывать технические особенности и ограничения межоператорского взаимодействия:

1. Ограничение роуминга: обмен неподписанными черновиками между разными операторами информационных систем ЭПД не стандартизирован. Роуминговые шлюзы передают только подписанные юридически значимые файлы. Поэтому создание черновика за контрагента «из коробки» возможно только в том случае, если грузоотправитель и перевозчик подключены к одному и тому же оператору.
2. Использование внешнего API оператора: если стороны работают в разных системах, грузоотправитель может настроить интеграцию своей 1С с открытым API того оператора, у которого зарегистрирован перевозчик. Информационная система грузоотправителя по API отправляет пакет данных с номером рейса, автомобилем, водителем и ставкой напрямую в личный кабинет перевозчика. Документ появляется у перевозчика в виде готового черновика, который достаточно лишь открыть и завизировать кнопкой «Подписать».

Вариант 3. Использование договора транспортной экспедиции

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

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

Рекомендации по автоматизации процессов в 1С

При внедрении ЭПД в конфигурациях 1С (ERP, КА, УТ) обратим внимание на следующие технические детали:

1. Не пытайтесь передавать неподписанный файл XML Титула 2 через стандартный сервис 1С-ЭДО (Диадок, СБИС и др.) как произвольный документ: шлюзы государственной информационной системы ГИС ЭПД требуют строгой цепочки титулов с проверкой идентификаторов файлов обмена (ИдФайл). Неформализованная передача разорвет связку документа в ГИС.
2. При использовании модулей интеграции внешних операторов отслеживайте порядок обработки статусов. Если модуль фиксирует изменение состояния по накладной с высокой частотой, следите за периодичностью регистров сведений, хранящих движение документов, чтобы исключить потерю событий при одновременной записи нескольких статусов за одну секунду.