Как работать с API реестра МЧД ФНС напрямую и через механизмы 1С?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Разберем архитектуру реестра, ограничения прямого взаимодействия, а также практические способы чтения и проверки МЧД через HTTP-запросы и встроенные механизмы Библиотеки стандартных подсистем (БСП).

Архитектура реестра МЧД и специфика прямого подключения

Проанализируем базовое устройство реестра. Единое хранилище доверенностей функционирует на базе Цифровой платформы распределенного реестра (ЦПРР) ФНС России. Это распределенная сеть (блокчейн), официальный прямой доступ к которой по протоколам обмена узлов предоставляется строго ограниченному кругу участников: аккредитованным операторам ЭДО, доверенным удостоверяющим центрам, банкам и государственным органам.

Для прямого участия в качестве узла ЦПРР требуется развертывание специального узлового ПО, организация шифрованного канала ГОСТ-VPN, заключение соглашения с ФНС и прохождение процедуры аттестации. Для прикладных систем такой путь в большинстве случаев экономически нецелесообразен.

Однако существуют альтернативные технические варианты взаимодействия:

  1. Прямые HTTP-запросы к веб-интерфейсу реестра — подходят для быстрого чтения и верификации статусов доверенностей без посредников.
  2. Использование штатных механизмов БСП / БЭД в 1С — обращение к реестру через встроенный шлюз экосистемы 1С.

Способ 1. Получение и проверка статуса МЧД через HTTP-запросы

Рассмотрим, как выполнить запрос к реестру напрямую. Портал реестра МЧД предоставляет методы, которые можно использовать из 1С с помощью объекта HTTPСоединение и отправки POST-запросов с телом в формате JSON.

Посмотрим на пример структуры запроса для получения кратких сведений и статуса доверенности. Запрос отправляется методом POST, а в теле передается идентификатор документа:


// Пример структуры тела запроса для кратких сведений
{
    "poaNumber": "123456"
}

В ответ сервис возвращает структуру данных доверенности в формате JSON:


{
    "poaNumber": "123456",
    "startDateTime": "2022-08-30T21:00:00.0000000Z",
    "endDateTime": "2022-09-15T20:59:59.0000000Z",
    "formatVersion": "5.01",
    "flags": "00010000",
    "type": "ROOT",
    "retrustType": "NO_RETRUST",
    "irrevocableRight": "ORDINARY",
    "flagPassword": "NO_PASSWORD",
    "authority": {
        "authorityLossType": "NOT_LOST",
        "collectiveRight": "INDIVIDUAL",
        "type": "MACHINE"
    },
    "status": {
        "status": "REJECTED",
        "statusDateTime": "2022-11-29T17:53:48.9650000Z"
    }
}

Если требуется получить полные сведения о доверенности, необходимо учитывать правила безопасности персональных данных. Сервис проверяет совпадение реквизитов участников, поэтому в теле запроса передаются идентификатор доверенности, ИНН доверителя и ИНН представителя:


{
    "guid": "123456",
    "innP": "7701234567",
    "innR": "7701234567",
    "password": ""
}

Важные особенности при работе через открытый веб-интерфейс:

  1. Данные конечные точки не имеют официального SLA и версионирования. ФНС может изменять состав параметров или заголовков без предупреждения.
  2. При частых запросах могут срабатывать механизмы ограничения нагрузки (rate limiting). Рекомендуется передавать стандартные клиентские заголовки запроса (например, User-Agent).
  3. Для регистрации и отзыва доверенностей требуется отправка структурированных XML-пакетов, подписанных квалифицированной электронной подписью доверителя.

Технические нюансы подписания XML при отправке в сервисы ФНС

Выясним причину, почему при попытке прямой регистрации или отзыва доверенностей собственным кодом 1С возникает ошибка проверки ЭЦП. Стандартный объект платформы МенеджерКриптографии при формировании открепленной подписи создает базовый контейнер CMS/PKCS#7. Принимающие шлюзы государственных сервисов требуют подпись стандарта CAdES (в частности, CAdES-BES).

В подписи формата CAdES-BES строго обязательно наличие подписанных атрибутов:

  1. contentType — тип передаваемого содержимого;
  2. signingTime — метка времени подписи;
  3. messageDigest — хэш исходных данных;
  4. SigningCertificateV2 — структурированная ссылка на сертификат подписанта.

Если этих атрибутов нет, сервис ФНС отклоняет пакет. Чтобы обойти данное ограничение платформы без сторонних платных сервисов, обычно используют вызов COM-объекта CAdESCOM.CadesSignedData (для ОС Windows) либо запуск консольных утилит криптопровайдера (например, утилит КриптоПро) через команду платформы ЗапуститьПриложение().

Способ 2. Получение и разбор МЧД средствами БСП

Рассмотрим подробнее стандартный механизм, заложенный в типовых конфигурациях 1С. В составе Библиотеки стандартных подсистем и Библиотеки электронных документов реализован модуль МашиночитаемыеДоверенности. Он взаимодействует со шлюзом 1С, который сам является авторизованным узлом реестра доверенностей.

Разберем по шагам, как получить данные доверенности из архива, распаковать zip-контейнер и прочитать файл формата XML с помощью фабрики XDTO:


Функция ДанныеДоверенностиXDTO(ИдентификаторДоверенности, ИННДоверителя)
    
    Результат = Новый Структура;
    Результат.Вставить("ДанныеПригодны", Ложь);
    Результат.Вставить("ДанныеXDTO", Неопределено);
    Результат.Вставить("ВерсияДоверенности", Неопределено);
    
    МодульМЧД = ОбщегоНазначения.ОбщийМодуль("МашиночитаемыеДоверенности");
    
    // Получаем полные данные доверенности через шлюз реестра
    ПолныеДанныеДоверенности = МодульМЧД.ПолучитьПолныеДанныеДоверенностиНаСервереМЧД(
        ИдентификаторДоверенности, 
        ИННДоверителя
    );
    
    Если ПолныеДанныеДоверенности.ДанныеАрхива = Неопределено Тогда 
        Возврат Результат; 
    КонецЕсли;
    
    ВременныйКаталог = РаботаСФайламиБЭД.ВременныйКаталог();
    
    Попытка
        ЧтениеZip = Новый ЧтениеZipФайла(ПолныеДанныеДоверенности.ДанныеАрхива.ОткрытьПотокДляЧтения());
        ЧтениеZip.ИзвлечьВсе(ВременныйКаталог);
        ЧтениеZip.Закрыть();
    Исключение
        РаботаСФайламиБЭД.УдалитьВременныеФайлы(ВременныйКаталог);
        ВызватьИсключение ОбработкаОшибок.ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
    КонецПопытки;
    
    ФайлыXML = НайтиФайлы(ВременныйКаталог, "*.xml");
    Если ФайлыXML.Количество() = 0 Тогда
        РаботаСФайламиБЭД.УдалитьВременныеФайлы(ВременныйКаталог);
        ВызватьИсключение НСтр("ru = 'В полученном архиве отсутствует файл XML'");
    КонецЕсли;
    
    ВерсияДоверенности = Неопределено;
    ДанныеПригодны = Ложь;
    ДанныеXDTO = Неопределено;
    
    Для Каждого ОписаниеФайла Из ФайлыXML Цикл
        ДвоичныеДанныеМЧД = Новый ДвоичныеДанные(ОписаниеФайла.ПолноеИмя);
        ЧтениеXML = Новый ЧтениеXML;
        ЧтениеXML.ОткрытьПоток(ДвоичныеДанныеМЧД.ОткрытьПотокДляЧтения());
        
        ДанныеXDTO = ФабрикаXDTO.ПрочитатьXML(ЧтениеXML);
        ЧтениеXML.Закрыть();
        
        // Определение формата: единый формат (EMCHD_1) или формат ФНС
        Если ДанныеXDTO.Свойства().Получить("ВерсФорм") <> Неопределено И ДанныеXDTO.ВерсФорм = "EMCHD_1" Тогда
            ВерсияДоверенности = "EMCHD_1";
            ДанныеПригодны = Истина;
            Прервать;
        КонецЕсли;
        
        Попытка
            Если ДанныеXDTO.Документ.ОКУД = "0251222" Тогда
                ВерсияДоверенности = "0251222";
                ДанныеПригодны = Истина;
                Прервать;
            КонецЕсли;
        Исключение
            // Пропуск файлов, структура которых не содержит узел Документ.ОКУД
        КонецПопытки;
    КонецЦикла;
    
    РаботаСФайламиБЭД.УдалитьВременныеФайлы(ВременныйКаталог);
    
    Результат.ДанныеПригодны = ДанныеПригодны;
    Результат.ДанныеXDTO = ДанныеXDTO;
    Результат.ВерсияДоверенности = ВерсияДоверенности;
    
    Возврат Результат;
    
КонецФункции

Сравнение подходов

Выбор способа реализации зависит от поставленных задач:

  1. Прямые HTTP-запросы оптимально подходят для фоновых регламентных заданий, когда необходимо лишь оперативно проверять актуальность и сроки действия большого пула доверенностей без создания накладных расходов.
  2. Механизмы БСП являются предпочтительными, если в конфигурации уже развернута подсистема электронного документооборота и требуется полная поддержка жизненного цикла доверенности (загрузка, сопоставление полномочий и проверка подписи через инфраструктуру 1С).
← На главную