← На главную

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

Выясняем техническую причину ошибки XDTO

Для начала проанализируем структуру сообщения об ошибке. Текст ошибки выглядит следующим образом:

Ошибка проверки данных XDTO: Значение: '[Наименование_Банка_И_Счета]' не соответствует простому типу: Несоответствие фасету MaxLength = '80'

Аббревиатура XDTO (XML Data Transfer Objects) в платформе "1С:Предприятие" отвечает за моделирование данных и их подготовку к отправке во внешние системы в формате XML. Все файлы обмена с СФР должны строго соответствовать официальным XML-схемам (XSD), разработанным ведомством.

Каждое поле в такой схеме имеет жестко прописанные ограничения, называемые фасетами. Фасет MaxLength = '80' означает, что длина передаваемой строки (в данном случае наименования банка или банковского счета) строго ограничена 80 символами. Если строка оказывается длиннее хотя бы на один символ, встроенный валидатор 1С блокирует выгрузку, чтобы предотвратить отправку заведомо некорректного файла, который все равно будет отклонен сервером СФР.

Часто в обсуждениях на форумах встречается ошибочная рекомендация сократить строку до 100 символов. Однако, поскольку схема СФР требует строго не более 80 знаков, любое сокращение, оставившее длину строки в диапазоне от 81 до 100 символов, продолжит вызывать точно такую же ошибку выгрузки.

Откуда берется избыточная длина наименования банка?

Рассмотрим, почему в информационной базе 1С вообще формируются такие длинные наименования. При создании нового расчетного счета сотрудника или организации в программе 1С наименование банковского счета часто генерируется автоматически по внутреннему шаблону. Этот шаблон может объединять в себе сразу несколько параметров:

• Официальное наименование финансовой организации.
• Тип операции или карты (например, "Пополнение счета банковской карты ПК").
• Скрытый или явный номер карты.
• Внутренние транзакционные префиксы (например, RBS) и номер расчетного счета.

Если пользователь соглашается с автоматическим предложением программы или вручную копирует строку назначения платежа из банковских документов, итоговая строка может составить 90 и более символов (например: 'АО "БИНБАНК ДИДЖИТАЛ" Пополнение счета банковской карты ПК №200080******8896RBS:40817810222713854271'). При выгрузке реестра конфигурация пытается передать это перегруженное название в качестве наименования банка получателя, что и приводит к ошибке.

Почему простое изменение названия в справочнике иногда не помогает?

Бывают ситуации, когда пользователь находит проблемного сотрудника, сокращает наименование его банковского счета до 30-40 символов, но при повторной выгрузке 1С снова выдает ту же ошибку, ссылаясь на старое длинное значение. Проанализируем, почему так происходит:

1. Кэширование данных. Платформа 1С сохраняет промежуточные результаты работы во временном кэше. Новые данные из справочника могут просто не успеть обновиться в оперативной памяти сеанса.
2. Запись сведений внутрь документа. При заполнении документов (таких как "Реестр прямых выплат" или "Сведения о застрахованном лице") программа копирует сведения о банке непосредственно в реквизиты самого документа. Простое изменение справочника "Банковские счета" задним числом не обновляет уже созданные и заполненные документы.
3. Влияние индексов СУБД. В редких случаях исправить кэш помогает только запуск процедуры "Тестирование и исправление" (в частности, реиндексация и реструктуризация таблиц), которая принудительно очищает временные таблицы СУБД и заставляет систему считать обновленные данные.

Разберем по шагам правильный алгоритм решения проблемы

Чтобы окончательно устранить ошибку выгрузки и избежать долгого тестирования всей базы данных (которое на крупных базах может занимать часы), выполним следующие действия:

1. Шаг 1: Найдите карточку банковского счета. Откройте карточку физического лица или сотрудника, по которому формируется реестр пособий. Перейдите в раздел "Банковские счета" и откройте карточку его личного счета.
2. Шаг 2: Сократите наименование. В поле "Наименование" удалите все лишние приписки, номера карт, коды RBS и номера расчетных счетов. Оставьте только лаконичное название банка (например: АО БИНБАНК ДИДЖИТАЛ или ПАО Сбербанк). Длина строки должна быть строго меньше 80 символов. Нажмите "Записать и закрыть".
3. Шаг 3: Обновите данные в документе выгрузки. Это самый важный шаг. Откройте документ, при выгрузке которого возникала ошибка (например, Реестр прямых выплат). Найдите строку с сотрудником, очистите поле выбора банковского счета и выберите его заново из справочника. После этого перепроведите документ. Данное действие принудительно запишет новое короткое наименование в структуру XML.
4. Шаг 4: Очистите кэш (при необходимости). Если ошибка все равно повторяется, закройте программу 1С. В окне запуска выделите вашу информационную базу, нажмите кнопку "Изменить", перейдите на страницу дополнительных параметров запуска и добавьте команду: /ClearCache. Затем запустите программу в обычном режиме и повторите выгрузку.

Выполнение этих простых шагов позволит быстро и гарантированно устранить ошибку проверки данных XDTO, не прибегая к потенциально опасным или длительным процедурам тестирования базы данных.