Как исправить ошибку XDTO «Не установлено значение свойства Контрагент» при синхронизации УНФ и БП

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

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

Анализ стека и деконструкция ошибки

Давайте внимательно изучим текст ошибки, который формируется в журнале регистрации или выводится на экран в момент выполнения обмена данными:

Ошибка проверки данных XDTO: Структура объекта '/КлючевыеСвойства' не соответствует типу... Не установлено значение одного из следующих свойств: Контрагент

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

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

Загадка «несуществующего» договора: почему UUID не находится?

Часто программисты пытаются решить эту проблему «в лоб»: берут из отладчика уникальный идентификатор договора (в нашем примере это 0226b708-ad15-11e0-a28b-001b11b11cf8) и пытаются найти этот элемент в справочнике ДоговорыКонтрагентов с помощью консоли запросов или обработки «Поиск и замена значений». Однако поиск не дает результатов.

Почему так происходит?

Дело в том, что этого договора физически не существует в базе данных УНФ. При выполнении кода в модуле менеджера обмена срабатывает защитный алгоритм: если у транзакции эквайринга в документе не определен договор, система не прерывает работу сразу, а динамически генерирует в оперативной памяти временную структуру «Основной договор» и присваивает ей временный UUID. Эта структура существует только в рамках сеанса выгрузки. Поскольку реального договора нет, реквизит Контрагент у этой виртуальной структуры также остается незаполненным, что и приводит к ошибке при проверке XDTO-схемы.

Таким образом, искать нужно не сам «несуществующий» договор, а первичный документ (или элемент справочника), который спровоцировал создание этой пустой структуры.

Пошаговое руководство по устранению проблемы

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

Шаг 1. Локализация проблемного документа «Отчет о розничных продажах»

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

1. Откроем обработку «Регистрация изменений для обмена данными» (ее можно найти через функции для технического специалиста или в разделе администрирования синхронизации данных).
2. Найдем в списке объектов документ Отчет о розничных продажах.
3. Проанализируем зарегистрированные к отправке документы за текущий период обмена. Обычно их немного (за последние несколько дней).

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

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

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

Шаг 2. Проверка и заполнение эквайринговых терминалов

Чаще всего первопричина кроется в некорректно настроенном справочнике ЭквайринговыеТерминалы. Давайте проверим его:

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

Шаг 3. Анализ настроек договора эквайринга

Даже если договор в терминале выбран, система может «забраковать» его при выгрузке, если он настроен неверно. Давайте проверим карточку договора с банком-эквайером:

1. Откроем выбранный в терминале договор контрагента.
2. Убедимся, что тип взаимоотношений с контрагентом установлен как Прочее или Дебитор/Кредитор (в зависимости от релиза конфигурации).
3. Проверим наличие и активность признака Это договор эквайринга (или соответствующего вида договора в зависимости от интерфейса вашей версии УНФ). Если вид договора указан как обычный договор с покупателем или поставщиком, алгоритм обмена проигнорирует его и попытается создать виртуальный «Основной договор», что вернет нас к исходной ошибке.

Шаг 4. Обновление данных в зарегистрированных документах

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

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

Использование отладчика для точечной диагностики (инструкция для программиста)

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

1. Запустите сеанс 1С:Предприятие в режиме отладки.
2. В конфигураторе откройте меню Отладка -> Настройка остановки по ошибке.
3. Установите флаг Останавливаться по ошибке и добавьте условие, указав тип исключения или просто включив остановку на любом исключении (включая обрабатываемые).
4. Запустите процесс синхронизации данных.
5. При возникновении ошибки валидации XDTO система автоматически остановит выполнение кода и переведет вас в конфигуратор на строку:
   ОбъектXDTO.Проверить();.
6. Посмотрите на стек вызовов и поднимитесь на несколько уровней выше — туда, где происходит обход выборки документов.
7. В табло отладчика вычислите выражение ДанныеИБ или Источник (в зависимости от текущего контекста модуля обмена). Там будет содержаться прямая ссылка на конкретный документ ОтчетОРозничныхПродажах, который в данный момент обрабатывается выгрузкой.
8. Запишите номер и дату этого документа, после чего вы сможете легко найти его в пользовательском интерфейсе и исправить.

Профилактика возникновения ошибки в будущем

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

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

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