Разберем распространенную техническую проблему, с которой можно столкнуться при перегрузке данных между конфигурациями 1С (в частности, в «1С:Управление торговлей 10.3») с помощью обработок ВыгрузкаЗагрузкаДанныхXML82 или V8Exchan82.
При попытке загрузить справочник ЕдиницыИзмерения в целевую информационную базу система завершает операцию с ошибкой:
Ошибка при вызове метода контекста (Записать): Значение поля "Владелец" не заполнено или заполнено неверно.
При этом анализ XML-файла и отладка в базе-источнике показывают, что поле Владелец физически заполнено и содержит корректный уникальный идентификатор (GUID) номенклатуры. Проанализируем причины этой проблемы на уровне платформы и метаданных 1С, а также рассмотрим пошаговые методы исправления.
Выясним, почему платформа 1С отклоняет запись объекта при загрузке, несмотря на наличие ссылок в файле.
Платформа 1С требует, чтобы объект-владелец физически существовал в таблице базы данных на момент вызова метода Записать() у подчиненного элемента. Даже если GUID владельца передан в файле и ссылка сформирована, при попытке сохранить подчиненную единицу измерения до того, как записан сам элемент номенклатуры, запись блокируется платформой с ошибкой незаполненного владельца.
В конфигурации «Управление торговлей 10.3» существует замкнутый круг ссылок между справочниками:
Номенклатура содержит реквизиты ЕдиницаХраненияОстатков и ЕдиницаДляОтчетов, которые ссылаются на элементы справочника ЕдиницыИзмерения.ЕдиницыИзмерения является подчиненным справочнику Номенклатура и требует обязательного заполнения реквизита Владелец.Если выгружать справочники по отдельности (только номенклатуру или только единицы измерения), этот замкнутый круг разрывается, и платформа не может разрешить зависимости при загрузке.
Проанализируем возможные повреждения данных в исходной базе:
Владелец.ЭтоГруппа = Истина). В 1С подчиненные справочники могут иметь владельцем только элементы.Владелец содержит незачищенную ссылку на некорректно удаленный объект («Объект не найден»). В XML-файл при этом выгружается валидный GUID, но в приемнике создать связь невозможно.Если в подписках на события или модулях справочников добавлены кастомные проверки перед записью, но отсутствует платформенная проверка режима загрузки, отмена стандартных проверок не сработает:
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Если такой блок отсутствует, бизнес-логика базы-приемника начинает принудительно валидировать еще не полностью инициализированный объект.
Рассмотрим несколько практических способов устранения проблемы в зависимости от используемого инструмента обмена.
При использовании обработки ВыгрузкаЗагрузкаДанныхXML строго запрещено выгружать подчиненные справочники отдельно от их владельцев. Разберем правильный порядок действий:
ВыгрузкаЗагрузкаДанныхXML в базе-источнике.Номенклатура, ЕдиницыИзмерения и КлассификаторЕдиницИзмерения.При загрузке единого файла обработка выполняет двухпроходный алгоритм записи, благодаря чему сначала создаются ссылки на объекты, а затем разрешаются цикличные зависимости.
Если обмен выполняется с помощью правил через обработку V8Exchan82, устраним кольцевую зависимость в конфигураторе правил:
Номенклатура отключим прямую передачу реквизитов ЕдиницаХраненияОстатков и ЕдиницаДляОтчетов.ПослеЗагрузки у ПКО Номенклатура или ЕдиницыИзмерения уже после того, как все объекты гарантированно записаны в базу.ЕдиницыИзмерения настроим поиск владельца строго по уникальному идентификатору.Если проблема сохраняется, выполним диагностику исходных данных.
Для обнаружения конкретных проблемных единиц измерения воспользуемся консолью запросов в базе-источнике:
ВЫБРАТЬ
Единицы.Ссылка КАК ЕдиницаИзмерения,
Единицы.Владелец КАК Владелец
ИЗ
Справочник.ЕдиницыИзмерения КАК Единицы
ГДЕ
Единицы.Владелец.ЭтоГруппа = ИСТИНА
ИЛИ Единицы.Владелец.Ссылка ЕСТЬ NULL
Все найденные запросом элементы следует вручную перепривязать к правильным элементам номенклатуры или очистить некорректные дубликат-записи перед повторной выгрузкой.