При работе с механизмом выгрузки и загрузки конфигурации в файлы XML в среде 1С:Предприятие 8.3 разработчики часто сталкиваются с системным сообщением: «Загрузка не должна менять принадлежность основного объекта конфигурации». Эта проблема может поставить в тупик, особенно когда загрузка производится в абсолютно пустую информационную базу. Разберем детально, почему это происходит и какими способами можно восстановить работоспособность процесса.
Для начала проанализируем ситуацию с точки зрения архитектуры платформы. Ошибка является частью защитного механизма, введенного фирмой «1С» для обеспечения целостности конфигураций, находящихся на поддержке поставщика. Под «принадлежностью» (ownership) основного объекта конфигурации платформа понимает статус самой конфигурации: является ли она полностью самописной, находится ли на поддержке с возможностью изменения или жестко привязана к конфигурации поставщика.
Рассмотрим подробнее логику проверки: когда мы запускаем процесс «Загрузить конфигурацию из файлов», система сравнивает метаданные в XML-файлах с текущим состоянием базы. Если в файлах содержатся настройки поддержки (информация о поставщике), а в базе данных конфигурация считается «пустой» или «самостоятельной», возникает конфликт. Платформа блокирует операцию, так как прямая загрузка файлов не предназначена для изменения фундаментального статуса «принадлежности» основного объекта. Проще говоря, 1С запрещает превращать «неподдерживаемую» базу в «поддерживаемую» простым импортом файлов, и наоборот.
Это самый надежный и рекомендуемый метод решения проблемы при работе с пустой базой. Разберем его по шагам, чтобы понять, как синхронизировать статусы поддержки.
.cf той же версии..cf файл.Поскольку теперь основной объект конфигурации в базе и в файлах имеет идентичный статус (один и тот же поставщик, те же правила поддержки), проверка принадлежности будет пройдена успешно.
Если у нас нет под рукой файла .cf или мы хотим загрузить только часть изменений, проанализируем альтернативный путь через Сравнение и объединение. В отличие от полной загрузки, этот механизм более лоялен к статусу объектов.
Выполним следующие действия:
Этот метод позволяет «протащить» изменения метаданных, минуя жесткую блокировку принадлежности, так как 1С воспринимает это не как замену всей конфигурации, а как частичное обновление объектов. Для выборочной подготовки исходных данных можно применить обработку для частичной выгрузки конфигурации в файлы.
Посмотрим на ситуацию глубже. При выгрузке конфигурации в файлы 1С создает служебный файл ConfigDumpInfo.xml. В нем фиксируется состояние объектов на момент выгрузки. Если мы работаем с пакетным режимом загрузки через командную строку, именно этот файл может служить источником проблем. Для автоматизации корректного создания этого файла подойдёт обработка для генерации ConfigDumpInfo.xml через командную строку.
Рассмотрим пример того, как система проверяет изменения в пакетном режиме:
/LoadConfigFromFiles "C:\MyConfigXML" -UpdateDBCfg
Если в ConfigDumpInfo.xml указаны свойства поддержки, которые не совпадают с текущей базой, возникнет ошибка. В некоторых случаях программисты прибегают к ручному удалению информации о поддержке из XML-файлов (удаление описаний поставщика в метаданных), но мы рекомендуем делать это только в крайних случаях, так как это может привести к потере связи с поставщиком и невозможности последующих обновлений через .cfu файлы.
Проанализировав проблему, мы видим, что ошибка «Загрузка не должна менять принадлежность основного объекта конфигурации» — это не баг, а фича безопасности платформы. Для успешного обхода этого ограничения всегда старайтесь соблюдать правило: статус поддержки в целевой базе должен соответствовать статусу поддержки в загружаемых файлах.
Если вы получили набор файлов от другого разработчика и не знаете, какая конфигурация была исходной, попробуйте сначала выполнить «Сравнение и объединение» в чистую базу — это зачастую позволяет увидеть, какой поставщик указан в заголовке, и понять, какие объекты находятся на замке.