При настройке или использовании типовой синхронизации между конфигурациями 1С:Управление торговлей и 1С:Бухгалтерия предприятия (через универсальный формат EnterpriseData) пользователи и администраторы часто сталкиваются с ошибками проверки XDTO. Одна из самых распространенных и коварных ошибок связана с выгрузкой документов поступления или реализации, когда система выдает сообщение: «Не установлено значение одного из следующих свойств: ДанныеНоменклатуры».
В этой статье мы подробно разберем, почему возникает эта проблема, как локализовать битые данные и какие действия необходимо предпринять для успешного завершения обмена. Мы пройдем путь от анализа текста ошибки до глубокой диагностики в отладчике и исправления данных в самой базе.
Для начала проанализируем техническую сторону вопроса. Ошибка возникает в момент работы общего модуля ОбменДаннымиXDTOСервер. Метод Проверить() объекта XDTO сопоставляет сформированный XML-пакет со схемой (XSD), которая жестко диктует правила: какие поля обязательны, а какие — нет.
В формате EnterpriseData версии 1.3 (и более поздних) объект ЕдиницаИзмерения не может существовать «сам по себе» внутри документа. Он обязательно должен содержать свойство ДанныеНоменклатуры, которое является ключевым. Это ссылка на номенклатуру-владельца данной единицы. Если по какой-то причине в базе данных УТ у единицы измерения не заполнен владелец или ссылка на него является «битой», при выгрузке это поле остается пустым. XDTO-пакет не проходит валидацию, и вся синхронизация прерывается.
В тексте ошибки 1С обычно четко указывает, в каком объекте произошел сбой. Рассмотрим пример из сообщения:
Объект: Документ объект: Поступление товаров и услуг 0000-000284 от 24.01.2019
Также указана конкретная строка табличной части: /Товары/Строка[1]. Это значительно упрощает нам задачу. Нам нужно открыть именно этот документ в исходной базе (УТ) и внимательно изучить первую строку в таблице товаров.
Прежде чем переходить к коду, проверим визуальные составляющие. Попробуем выполнить следующие действия:
Если визуальная проверка не дала результатов, воспользуемся советом опытных разработчиков: остановка по ошибке. Рассмотрим подробнее, как это сделать:
Исключение (или просто включим галочку «Останавливаться по ошибке»).ОбъектXDTO.Проверить(); в модуле ОбменДаннымиXDTOСервер, проанализируем дерево свойств переменной ОбъектXDTO.Нам нужно найти узел Товары, открыть первую строку и посмотреть на структуру ЕдиницаИзмерения. Если свойство ДанныеНоменклатуры имеет значение Неопределено или NULL, значит, алгоритм формирования XML не смог найти владельца единицы измерения.
Выясним причину, по которой ДанныеНоменклатуры не заполняются. В универсальном обмене за это отвечают Правила Конвертации Объектов (ПКО). Для единиц измерения часто используется ПКО КлючевыеСвойстваЕдиницаИзмерения.
Проанализируем ситуацию: если в УТ используются упаковки, то при выгрузке система пытается сопоставить упаковку с единицей измерения EnterpriseData. Если упаковка является «общей» (для всех видов номенклатуры), у нее может не быть жесткой привязки к конкретной номенклатуре в поле «Владелец» так, как этого ожидает схема XDTO. В таких случаях ошибка может быть в самих правилах обмена (например, используется устаревшая версия формата).
Иногда проблема кроется в «фантомных» записях. Давайте проанализируем ситуацию с помощью консоли запросов. Мы можем написать простой запрос к табличной части документа, чтобы увидеть скрытые данные:
ВЫБРАТЬ
ПоступлениеТоваровУслугТовары.Номенклатура КАК Номенклатура,
ПоступлениеТоваровУслугТовары.Упаковка КАК Упаковка,
ПоступлениеТоваровУслугТовары.Упаковка.Владелец КАК ВладелецУпаковки,
ПоступлениеТоваровУслугТовары.Номенклатура.ЕдиницаИзмерения КАК БазоваяЕдиница
ИЗ
Документ.ПоступлениеТоваровУслуг.Товары КАК ПоступлениеТоваровУслугТовары
ГДЕ
ПоступлениеТоваровУслугТовары.Ссылка = &СсылкаНаДокумент
Если в результате запроса ВладелецУпаковки окажется пустым или не будет совпадать с Номенклатурой в этой строке, мы нашли причину. Система XDTO не понимает, к какой номенклатуре относится данная единица, и оставляет поле незаполненным, что запрещено схемой.
В зависимости от выявленной причины, выберем один из способов исправления:
Если обнаружены дубли единиц измерения или упаковок, воспользуемся стандартной обработкой «Поиск и удаление дублей». Объединим некорректные записи с правильными. После этого обязательно перепроведем проблемный документ.
Если проблема в битых ссылках (объект удален, но ссылка в документе осталась), запустим процедуру «Тестирование и исправление» в конфигураторе. Установим галочки «Проверка логической целостности» и «Проверка ссылочной целостности». В параметрах выберем «Очищать ссылки» или «Создавать объекты» в зависимости от вашей политики ведения учета.
Если вы используете версию формата 1.3, возможно, стоит рассмотреть переход на более свежую версию (например, 1.10 или выше), если обе конфигурации (УТ и БП) обновлены. В новых версиях формата многие ошибки работы с упаковками и единицами измерения уже исправлены разработчиками 1С. Проверьте актуальность релизов обеих программ.
Если единиц с пустыми владельцами много, можно написать простую обработку, которая программно проставит владельца для упаковок/единиц измерения, основываясь на данных номенклатуры, в которой они используются.
ОбъектУпаковка = СсылкаНаУпаковку.ПолучитьОбъект();
Если ОбъектУпаковка.Владелец.Пустая() Тогда
ОбъектУпаковка.Владелец = СсылкаНаНоменклатуру;
ОбъектУпаковка.Записать();
КонецЕсли;
Ошибка проверки данных XDTO в части ДанныеНоменклатуры — это всегда сигнал о нарушении целостности данных в исходной базе. Основные причины: дубли, пустые владельцы единиц измерения или некорректно заполненные упаковки. Использование отладчика и консоли запросов позволяет быстро найти «виновника» и исправить ситуацию без изменения типового кода конфигурации.
Помните, что регулярное проведение профилактических работ в базе (поиск дублей и ТиИ) сводит риск возникновения таких ошибок при синхронизации к минимуму.