Как исправить ошибку XDTO «Не установлено значение одного из следующих свойств: Контрагент» при обмене УТ – БП

Синхронизация данных между конфигурациями «1С:Управление торговлей» (УТ 11) и «1С:Бухгалтерия предприятия» (БП 3.0) по универсальному формату EnterpriseData — это мощный, но порой капризный инструмент. В процессе его работы специалисты часто сталкиваются со специфическими ошибками XDTO-валидации. Одна из самых распространенных и труднодиагностируемых ошибок связана с выгрузкой договоров контрагентов.

В этой статье мы подробно разберем, почему возникает ошибка Ошибка проверки данных XDTO: Структура объекта '/КлючевыеСвойства' не соответствует типу... Не установлено значение одного из следующих свойств: Контрагент, как устроен механизм генерации «виртуальных договоров» в 1С и как быстро локализовать и устранить эту проблему на практическом примере.

Почему возникает эта ошибка: разбираем механизм «Виртуального договора»

Для начала проанализируем архитектурное различие двух конфигураций. В управленческих базах данных (УТ 11, КА 2, ERP) учет взаиморасчетов можно вести максимально гибко: в разрезе заказов, накладных или соглашений, вообще не создавая карточки договоров в справочнике. Более того, при розничных продажах и эквайринговых операциях договоры с конечными покупателями физически отсутствуют.

Однако в «1С:Бухгалтерии предприятия» правила ведения учета жесткие: проводки по счетам расчетов (например, 62.01, 62.02, 57.03, 76.05) в обязательном порядке требуют заполнения аналитического разреза (субконто) Договоры.

Чтобы подружить эти две системы, разработчики фирмы 1С внедрили в модуль МенеджерСинхронизацииЧерезУниверсальныйФормат специальный программный алгоритм. Когда система выгружает документ, в котором по правилам УТ договора нет (или это розничный документ ОРП), код выгрузки «на лету» генерирует так называемый «Виртуальный договор»:

1. Создается временная структура свойств, имитирующая договор контрагента.
2. В дополнительные свойства структуры записывается признак ВиртуальныйДоговор.
3. Данная структура передается в правило конвертации объектов (ПКО) Справочник_ДоговорыКонтрагентов_ИзСтруктуры.
4. ПКО транслирует эту структуру в XML-файл обмена в соответствии со схемой XDTO (в нашем случае версии 1.5).

Согласно схеме XDTO для объекта КлючевыеСвойстваДоговор, свойства Контрагент и ВалютаВзаиморасчетов являются строго обязательными (mandatory). Если хотя бы одно из этих полей не заполнено, XML-файл не пройдет проверку схемы.

При попытке выполнить выгрузку платформа выполняет метод проверки:

ОбъектXDTO.Проверить();

Если валидатор видит пустое обязательное поле, он моментально прерывает выгрузку всего пакета данных с ошибкой, которую мы рассматриваем.

Главная причина сбоя — «битые ссылки» в эквайринге

Выясним причину, по которой обязательные свойства виртуального договора могут оказаться пустыми. Очень часто это происходит из-за повреждения целостности данных, например, при некорректной работе распределенных информационных баз (РИБ).

Рассмотрим конкретный сценарий: в документе Отчет о розничных продажах (ОРП) на вкладке «Оплата платежными картами» указан эквайринговый терминал. Этот терминал был создан в периферийной базе РИБ, но по какой-то причине транзакция его переноса в главный узел не завершилась или объект был удален в центре. В результате в документе ОРП в главном узле поле терминала превращается в битую ссылку — <Объект не найден...>.

При выгрузке этого ОРП система пытается собрать данные для виртуального договора с банком-эквайером:

• Программа обращается к реквизитам терминала через точку: Терминал.Договор.Контрагент.
• Поскольку ссылка на терминал «битая», платформа не выбрасывает фатальную ошибку обращения к несуществующему объекту, а просто возвращает пустое значение — Неопределено или NULL.
• Код формирования структуры молча записывает пустые значения в поля контрагента и валюты.
• Валидатор XDTO спотыкается на проверке структуры и останавливает весь процесс обмена.

Аналогичная проблема может возникнуть, если сам терминал заполнен корректно, но в его карточке не выбран договор обслуживания или у этого договора не указана валюта.

Диагностика проблемы: пошаговый алгоритм поиска

Если ваша база содержит десятки тысяч документов, а сеанс обмена длится несколько часов, искать ошибку обычным отладчиком крайне тяжело. Разберем по шагам, как быстро локализовать проблемный объект.

Шаг 1. Анализ зарегистрированных к обмену объектов

Прежде всего, ограничим область поиска. Перейдем в обработку «Регистрация изменений для обмена данными» для нашего узла Бухгалтерии. Обратим особое внимание на документы, которые стоят в очереди на отправку:

• Отчет о розничных продажах
• Эквайринговая операция
• Приобретение товаров и услуг
• Реализация товаров и услуг

Проблема гарантированно кроется в одном из этих документов или связанных с ними справочников.

Шаг 2. Экспресс-поиск «битых ссылок» через консоль запросов

Вместо долгого перебора документов вручную воспользуемся консолью запросов в базе-источнике (УТ). Напишем запрос, который мгновенно выявит документы ОРП, содержащие невалидные ссылки на эквайринговые терминалы в табличной части платежей:

ВЫБРАТЬ
    ОРП.Ссылка КАК ДокументСсылка,
    ОРП.Номер КАК НомерДокумента,
    ОРП.Дата КАК ДатаДокумента,
    ТЧ_Оплата.ЭквайринговыйТерминал КАК ПроблемныйТерминал
ИЗ
    Документ.ОтчетОРозничныхПродажах КАК ОРП
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ОтчетОРозничныхПродажах.ОплатаПлатежнымиКартами КАК ТЧ_Оплата
        ПО ОРП.Ссылка = ТЧ_Оплата.Ссылка
ГДЕ
    ТЧ_Оплата.ЭквайринговыйТерминал.ВерсияДанных ЕСТЬ NULL
    И НЕ ТЧ_Оплата.ЭквайринговыйТерминал = ЗНАЧЕНИЕ(Справочник.ЭквайринговыеТерминалы.ПустаяСсылка)

Важное примечание: обращение к реквизиту ВерсияДанных через точку у «битой» ссылки всегда возвращает NULL. Этот изящный прием позволяет за доли секунды просканировать миллионы строк документов и вывести только дефектные записи.

Шаг 3. Использование выборочной выгрузки данных

Если запрос ничего не вернул, воспользуемся стандартной обработкой «Выгрузка загрузка данных EnterpriseData» (ее можно найти на диске ИТС или в функциях для технического специалиста):

1. Запустим обработку в режиме выгрузки.
2. Вместо полной выгрузки выберем период (например, один день или неделю).
3. Будем последовательно выгружать порции данных, пока не наткнемся на ошибку валидации.
4. Как только период с ошибкой найден, сузим его до конкретного часа или выберем документы по одному, чтобы точно определить сбойный объект.

Способы решения проблемы

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

Способ 1. Восстановление элемента через РИБ

Если эквайринговый терминал (или договор) действительно остался в периферийной базе и отсутствует в центральной:

1. Зайдем в узел РИБ, где физически существует этот терминал.
2. Внесем любое незначительное изменение в его карточку (например, добавим пробел в наименование и удалим его), чтобы объект зарегистрировался к обмену.
3. Выполним синхронизацию периферийной базы с центральной.
4. После того как терминал прилетит в центр, ссылка <Объект не найден...> автоматически заменится на нормальное представление объекта.

Способ 2. Ручное исправление документа

Если восстановить исходный элемент справочника невозможно, откроем сбойный документ (например, Отчет о розничных продажах):

1. Перейдем на вкладку «Оплата платежными картами».
2. Вместо битой ссылки выберем актуальный и корректный эквайринговый терминал из справочника.
3. Перепроведем документ.

Способ 3. Проверка параметров терминала и договора

Если битых ссылок нет, но ошибка все равно возникает, проверим заполнение реквизитов самого терминала:

1. Откроем карточку эквайрингового терминала, указанного в документе.
2. Проверим, заполнен ли реквизит Договор.
3. Откроем этот договор и убедимся, что в нем выбраны Контрагент (банк-эквайер) и Валюта взаиморасчетов (например, руб.).

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