Достаточно ли версии 1С:Управление торговлей 11.5.22 для работы с ЭТрН и ЭПД?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При подготовке к переходу на электронные перевозочные документы (ЭПД) — в первую очередь электронные транспортные накладные (ЭТрН) и электронные заказы (заявки) — у специалистов часто возникает вопрос о минимально необходимой версии конфигурации. Разберем, можно ли обойтись релизом 11.5.22.186 (или аналогичной веткой 2.5.22.xx в ERP/КА), с какими сложностями предстоит столкнуться и как правильно организовать обмен.

Возможность работы на ветке 11.5.22

Проанализируем нормативную и практическую базу. Законодательные правила обмена электронными перевозочными документами регулируются Постановлением Правительства РФ № 931, а базовые XML-форматы утверждены Приказом ФНС России № ЕД-7-26/1065@. Поскольку формат ЭТрН действует достаточно давно, его базовая структура поддержана в подсистеме Библиотеки электронных документов (БЭД), входящей в состав конфигурации 1С:Управление торговлей 11.5.22.186.

Практический опыт показывает, что обмен титулами ЭТрН и электронными заявками на ветке 11.5.22 функционирует: документы успешно формируются, подписываются и отправляются контрагентам. Однако обновление до ветки 11.5.27 или установка регулярных исправлений (патчей) содержит существенное количество доработок логики ГИС ЭПД, расширенные проверки корректности титулов и обновленные механизмы работы с МЧД. Если конфигурация сильно доработана и переход на версию 11.5.27 затруднен, работать на 11.5.22.186 возможно, но следует учитывать ряд особенностей подсистемы.

Различие контуров ЭДО и 1С-ЭПД: статус «Произвольный документ»

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

Рассмотрим, почему возникает такая классификация:

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

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

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

Одной из наиболее распространенных проблем как в релизах ветки 11.5.22, так и в более поздних 11.5.27, является подстановка произвольного подписанта при автоматическом формировании титулов. Разберем по шагам, из-за чего это происходит:

  1. Алгоритм автоподбора сертификата: подсистема криптографии пытается автоматически сопоставить сертификат из доступных в хранилище. Проверка идет по цепочке: текущий авторизованный пользователь базы -> ответственное лицо организации из регистров сведений -> первый попавшийся валидный сертификат в списке доступных на данном рабочем месте. Если на одном компьютере или терминальном сервере установлено несколько сертификатов разных сотрудников, программа может применить ключ по внутреннему приоритету сортировки.
  2. Привязка МЧД к конкретным титулам: в процессе грузоперевозки разные титулы подписываются разными ролями (кладовщик/грузоотправитель, водитель/перевозчик, грузополучатель). Если сертификаты физических лиц не имеют жесткой привязки к конкретным доверенностям (МЧД) с соответствующими полномочиями на конкретную операцию отгрузки или приемки, в XML-титул могут попадать реквизиты не того должностного лица.

Способы решения и стабилизации работы

Рассмотрим комплекс мер, позволяющий выстроить стабильный процесс подписания и обмена перевозочными документами без сбоев:

  1. Точечная настройка правил подписания: в справочнике настроек электронной подписи и шифрования необходимо отключить фоновый автоподбор сертификатов и жестко зафиксировать соответствие сертификатов, машиночитаемых доверенностей и ответственных лиц для каждого вида перевозочного документа.
  2. Обновление технологической платформы: стабильное функционирование криптографии и машиночитаемых доверенностей на стороне сервера «1С:Предприятие» требует использования платформы версий 8.3.21, а для современных криптографических сценариев — 8.3.24 и выше.
  3. Использование внешних интеграционных модулей операторов: если доработка типовых механизмов ветки 11.5.22 нецелесообразна, эффективной альтернативой выступает прямой интеграционный модуль от оператора ИС ЭПД. Такие внешние модули работают по API через собственные библиотеки, исключая зависимость от встроенной версии БЭД в конфигурации.
  4. Специализированные мобильные рабочие места: для подписания титулов при физической передаче груза (водителями и кладовщиками) рекомендуется использовать изолированные мобильные клиенты или приложения операторов, где исключена возможность подписи чужим сертификатом.
← На главную