Как интегрировать новую XSD схему в Реестр сведений в ФСС для 1С:УПП и 1С:ЗУП 2.5?

← На главную

При обновлении форматов обмена с ФСС (СФР) в рамках пилотного проекта прямых выплат работодатели часто сталкиваются с ситуацией, когда шлюз приема отчетности начинает требовать новую версию XSD-схемы (например, переход с версии 1.7.4 на 1.7.5), а установленный релиз конфигурации «1С:Управление производственным предприятием 1.3» или «1С:Зарплата и управление персоналом 2.5» продолжает формировать XML-файлы по предыдущему стандарту. Разберем, как устроена архитектура выгрузки реестров в решениях на обычных формах, почему простая замена XSD-пакета не решает проблему и как адаптировать выгрузку к новым требованиям.

Архитектура выгрузки реестров ФСС в конфигурациях на обычных формах

В современных конфигурациях на управляемых формах (таких как «1С:ЗУП 3.1» или «1С:ERP 2») выгрузка регламентированных сведений обычно опирается на встроенные пакеты XDTO и автоматическую сериализацию объектов. Однако в 1С:УПП 1.3 и 1С:ЗУП 2.5 механизм выгрузки реестров пилотного проекта устроен процедурно:

Макет описания формата: Структура результирующего XML-документа и перечень тегов описаны в табличном документе (макете) конфигурации или обработки, где зафиксированы имена элементов, их типы данных и обязательность.
Программный модуль: Формирование файла выполняется прямым созданием XML через объект платформы ЗаписьXML в общем модуле ОбменСведениямиОПособияхСФСС (процедура ДобавитьСтрокуВРеестр и вспомогательные функции).
Отсутствие автоматической привязки к XSD: Платформа не генерирует XML автоматически на лету из схемы .xsd, поэтому добавление или замена файла схемы в метаданных не изменит алгоритм выгрузки без модификации исходного программного кода.

Причины ошибок валидации при переходе на схему 1.7.5

Проанализируем основные изменения, которые привели к ошибкам выгрузки при переходе на схему 1.7.5:

Ужесточение контроля тега RECALC_REASON_CODE: В схеме 1.7.5 тег кода причины перерасчета должен присутствовать в узле документа только тогда, когда флаг TYPE_INFO равен 1 (признак перерасчета пособия). Если выгружается первичный реестр (TYPE_INFO = 0), даже пустой тег вида <RECALC_REASON_CODE/> приводит к фатальной ошибке XSD-валидации на стороне шлюза.
Изменение классификатора причин перерасчета: Было сокращено количество допустимых числовых кодов причин (с 7 до 6 значений).
Требования к последовательности узлов: Схема строго регламентирует порядок следования дочерних тегов, поэтому любое ручное добавление полей без соблюдения схемы приводит к отклонению файла.

Способ 1. Программное исправление в общем модуле конфигурации

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


// Проверяем признак перерасчета в переданных данных реестра
Если СтруктураДанных.Свойство("Перерасчет") И СтруктураДанных.Перерасчет Тогда
    НаборЗаписей.RECALC_REASON_CODE.Значение = Число(СтруктураДанных.КодПричиныПерерасчета);
Иначе
    // Если это первичная выгрузка, удаляем тег из структуры выгрузки полностью
    Если НаборЗаписей.Свойство("RECALC_REASON_CODE") Тогда
        НаборЗаписей.Удалить("RECALC_REASON_CODE");
    КонецЕсли;
КонецЕсли;

Также проверяем макет формата обмена: если в табличном документе строка RECALC_REASON_CODE была помечена как безусловно выгружаемая, корректируем условие ее заполнения, чтобы пустые теги не попадали в итоговый XML-файл.

Способ 2. Использование внешней обработки выгрузки

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

Создаем новую внешнюю обработку в конфигураторе.
Переносим в модуль обработки макет формата выгрузки и функции выгрузки из общего модуля ОбменСведениямиОПособияхСФСС и документа РеестрСведенийВФСС.
В процедуре записи узлов XML корректируем правила генерации тегов под схему 1.7.5.
Подключаем внешнюю обработку в справочник ДополнительныеВнешниеОбработки или запускаем через Файл - Открыть для формирования готового файла реестра.

Способ 3. Локальная валидация XML-файла по новой XSD-схеме

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


Процедура ПроверитьXMLПоСхемеXSD(ПутьКФайлуXML, ПутьКФайлуXSD)
    
    // Создаем фабрику XDTO на основании предоставленной схемы XSD
    Фабрика = СоздатьФабрикуXDTO(ПутьКФайлуXSD);
    
    // Инициализируем чтение XML-файла
    ЧтениеXML = Новый ЧтениеXML;
    ЧтениеXML.ОткрытьФайл(ПутьКФайлуXML);
    
    Попытка
        // Читаем XML с проверкой по типам схемы XDTO
        ОбъектXDTO = Фабрика.ПрочитатьXML(ЧтениеXML);
        Фабрика.Проверить(ОбъектXDTO);
        Сообщить("Файл успешно прошел проверку по XSD схеме!", СтатусСообщения.Информация);
    Исключение
        Сообщить("Ошибка валидации XML: " + ОписаниеОшибки(), СтатусСообщения.Важное);
    КонецПопытки;
    
    ЧтениеXML.Закрыть();
    
КонецПроцедуры

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