← На главную
При организации электронного документооборота часто возникает задача: учетная система уже умеет выгружать готовые файлы электронных документов (например, универсальные передаточные документы формата 5.03 / 820 с кодами маркировки «Честный Знак» и реквизитами прослеживаемости РНПТ), и требуется передать их контрагенту через оператора ЭДО без внедрения тяжелых модулей, платных внешних обработок или сложных доработок конфигураций. Разберем, как построить надежный и простой процесс передачи файлов с помощью файлового коннектора оператора, а также выясним технические нюансы работы с электронными подписями и серверной инфраструктурой.
Архитектура решения: использование файлового коннектора
Для исключения прямой программной интеграции с оператором ЭДО применяется промежуточное программное обеспечение — файловый агент (коннектор). Наиболее стабильным решением для этой задачи является утилита СБИС Коннект. Принцип ее работы строится на мониторинге файловой системы:
- Учетная система или фоновый скрипт формирует файл УПД в формате XML и сохраняет его в специально назначенную локальную или сетевую папку отправки.
- Коннектор непрерывно отслеживает появление новых файлов в каталоге.
- При обнаружении документа утилита выполняет его проверку, подписывает установленным сертификатом электронной подписи и отправляет на сервер оператора.
- После успешной отправки файл перемещается в каталог отправленных документов, а при возникновении ошибок — в папку с логами и ошибочными пакетами.
Такой подход полностью изолирует учетную систему от обновлений внешних API операторов, изменений в модулях интеграции и проблем с совместимостью релизов.
Структура пакета и служебные файлы (конверты)
Проанализируем распространенную ошибку: многие предполагают, что для отправки достаточно просто сбросить XML-файл УПД в папку, рассчитывая, что коннектор сам определит маршрут по атрибутам ИдОтпр и ИдПол. На практике большинству шлюзов требуется сопутствующий транспортный файл метаданных (конверт):
- Файл документа: стандартный XML-файл УПД, содержащий титул продавца, табличную часть, коды идентификации маркированных товаров и данные РНПТ.
- Файл описания (конверт): файл формата INI или служебный XML с аналогичным базовым именем. В нем указываются идентификатор отправителя, идентификатор получателя в системе ЭДО, тип документа, а также отпечаток (thumbprint) сертификата, которым должен быть подписан документ.
Если требуется отправлять документы от имени нескольких юридических лиц, коннектор позволяет организовать работу в едином пространстве. Достаточно передавать в служебном конверте реквизиты нужной организации и идентификатор соответствующего сертификата. Также поддерживается запуск нескольких изолированных экземпляров коннектора, каждый из которых привязан к собственным каталогам обмена.
Контроль маркировки и предвалидация
При передаче УПД с маркированными позициями оператор выполняет первичный синтаксический и криптографический контроль перед отправкой документа контрагенту:
- Проверяется корректность длины криптохвоста и экранирование специальных разделителей (GS-символов) в кодах маркировки.
- Выполняется запрос к государственной информационной системе маркировки для проверки статуса кодов (не списаны ли они, принадлежат ли текущему собственнику).
- Если обнаружена ошибка, коннектор не отправляет документ, а помещает его в каталог сбоев с текстовым описанием ошибки. Рекомендуется настроить автоматический мониторинг каталога ошибок, чтобы вовремя реагировать на отклоненные файлы.
Настройка криптографии и сертификатов на сервере
Вопрос подписания документов на стороне сервера требует соблюдения технических и правовых регламентов. Разберем основные варианты развертывания:
- Серверная операционная система: если файловый коннектор устанавливается на Windows Server, криптопровайдер КриптоПро CSP требует наличия специализированной серверной лицензии. На клиентских версиях ОС (Windows 10/11) достаточно стандартной пользовательской лицензии.
- Запуск коннектора: если утилита запускается как системная служба Windows (Service) для автономной круглосуточной работы, она не имеет доступа к токенам, проброшенным через пользовательские RDP-сессии. В этом случае контейнер закрытого ключа должен быть установлен в локальное хранилище компьютера с предоставлением прав доступа служебной учетной записи, либо должен использоваться постоянно подключенный физический ключевой носитель.
- Сертификаты физических лиц и МЧД: в связи с переходом на электронные подписи физических лиц с машиночитаемыми доверенностями (МЧД), доверенность должна быть предварительно зарегистрирована в реестре ФНС и привязана к профилю организации в веб-кабинете оператора, либо ее номер должен явно передаваться в транспортном файле конверта.
Альтернативные каналы интеграции
Если установка локального коннектора нежелательна, рассмотрим альтернативные методы автоматизации:
- Защищенный FTP (SFTP/FTPS): некоторые операторы предоставляют доступ к сетевым шлюзам, куда можно выгружать предварительно подписанные файлы. Это исключает необходимость ставить стороннее ПО, позволяя использовать стандартные сетевые утилиты операционной системы.
- Прямой REST API: отправка документа может быть реализована компактным внешним скриптом (на PowerShell, Python или curl), который отправляет файл методом HTTP POST напрямую в API оператора, принимая статус отправки в синхронном ответе.