← На главную

При выполнении обновления типовой или доработанной конфигурации 1С (например, перехода с релиза 2.0.44.13 на 2.0.66) разработчики нередко сталкиваются с критической ошибкой: «Дублирование имени объекта метаданных» или «Использование одинакового имени для перечисленных ниже объектов недопустимо». Чаще всего в списке конфликтующих элементов фигурируют макеты, ресурсы регистров или объекты с системным префиксом Удалить (например, РегистрСведений.УдалитьВерсииПодсистем, РегистрСведений.УдалитьПрисоединенныеФайлы).

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

Почему возникает дублирование имен объектов метаданных?

Платформа 1С идентифицирует элементы дерева метаданных не только по их строковому имени, но и по внутреннему уникальному идентификатору — UUID (GUID). Конфликт уникальности возникает по следующим причинам:

1. Перескакивание через релизы при обновлении: вендор (фирма «1С») в процессе развития конфигурации переименовывает устаревшие объекты, добавляя префикс Удалить, а в следующих релизах полностью исключает их из конфигурации. Если обновить базу «рывком» через большой интервал версий, механизм обновления не может сопоставить старое имя с новым и пытается создать дублирующий объект.
2. Рассинхронизация основной конфигурации и конфигурации поставщика: если ранее базу обновляли некорректно (через команду Сравнить, объединить с конфигурацией из файла вместо штатного механизма поддержки) или переносили объекты метаданных через буфер обмена, их UUID начинают отличаться от UUID в файле обновления поставщика. В результате платформа считает объект из обновления новым и пытается добавить его в дерево с уже существующим именем.
3. Включенная возможность изменения («желтый замок»): если на объекте снят запрет редактирования и в него вносились ручные правки, платформа защищает пользовательские изменения и не заменяет объект автоматически, что приводит к коллизиям при объединении.

Способ 1. Восстановление идентификаторов через чистый файл конфигурации поставщика

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

Разберем по шагам данный алгоритм:

1. Обязательно создадим резервную копию информационной базы перед любыми действиями через меню Администрирование — Выгрузить информационную базу.
2. Найдем и подготовим файл полной конфигурации поставщика (*.cf) ровно того релиза, который сейчас установлен в базе (в рассматриваемом случае — 2.0.44.13).
3. Откроем конфигуратор и перейдем в меню Конфигурация — Загрузить конфигурацию из файла....
4. Выберем файл cf текущего релиза и подтвердим полную замену конфигурации.
5. Применим изменения в структуре базы данных (клавиша F7).

В результате этой операции платформа перезапишет метаданные оригинальными объектами с правильными системными идентификаторами и восстановит исходную конфигурацию поставщика. После этого штатное обновление на следующие релизы пройдет без коллизий.

Способ 2. Строгое соблюдение цепочки обновлений с запуском в режиме «Предприятие»

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

Выполним процедуру последовательного обновления:

1. Выясним минимальную и рекомендуемую цепочку переходов по документации к релизам (файлы UpdInfo.txt в каталоге шаблонов обновления).
2. Обновим конфигурацию на первый промежуточный релиз штатным способом: меню Конфигурация — Поддержка — Обновить конфигурацию.
3. После успешного обновления конфигурации базы данных (F7) обязательно запустим 1С в режиме «Предприятие» от имени администратора.
4. Дождемся окончания всех регламентных процедур обработки данных и обновления версий подсистем.
5. Только после завершения фоновых обработок закроем режим предприятия и перейдем к накатыванию следующего релиза цепочки.

Способ 3. Корректная настройка режима удаления объектов при объединении

Рассмотрим вариант, когда обновление выполняется через файл cf нового релиза с помощью меню Конфигурация — Сравнить, объединить с конфигурацией из файла. В этом случае появление задвоенных объектов с префиксом Удалить связано с тем, что в окне объединения отключено удаление устаревших элементов.

Настроим правила объединения следующим образом:

1. В окне сравнения и объединения конфигураций нажмем кнопку Действия — Отметить по подсистемам файла или снимем общие флаги.
2. В меню параметров объединения включим возможность «Разрешить удаление объектов основной конфигурации».
3. Обратим внимание на объекты, указанные в ошибках: если объект устарел (помечен префиксом Удалить) и в файле новой конфигурации он отсутствует, платформа должна удалить старый объект, а не дублировать его.
4. Важное предупреждение: перед подтверждением удаления объектов регистров или реквизитов проверим, содержатся ли в них учетные данные. Если в удаляемых объектах хранятся критически важные сведения, предварительно перенесем их в актуальные структуры данных с помощью внешней обработки.

Способ 4. Тестирование и исправление информационной базы (ТИИ)

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

1. В конфигураторе перейдем в меню Администрирование — Тестирование и исправление....
2. Установим флажки на пунктах:
   • Реиндексация таблиц информационной базы;
   • Проверка логической целостности информационной базы;
   • Проверка ссылочной целостности информационной базы;
   • Пересчет итогов.
3. При наличии ссылок на несуществующие объекты выберем режим Очищать ссылки.
4. Нажмем Выполнить и дождемся завершения служебного протокола. Также убедимся, что используется актуальная версия технологической платформы 1С:Предприятие.

Способ 5. Ручное разрешение конфликтов через выгрузку конфигурации в файлы

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

1. Выполним команду Конфигурация — Выгрузить конфигурацию в файлы... в пустую директорию.
2. Откроем полученную папку в текстовом редакторе с функцией глобального поиска (например, Notepad++ или VS Code).
3. Выполним поиск по именам конфликтующих объектов, например: КлассификацияДоходовБюджетов или УдалитьВерсииПодсистем.
4. В файле ConfigDumpInfo.xml и связанных XML-файлах метаданных найдем записи с одинаковыми именами и сопоставим их uuid.
5. Если в основной конфигурации визуально отображаются два одинаковых макета или ресурса, вернемся в конфигуратор, переименуем лишний дубль (добавив, например, суффикс _Дубль), сохраним конфигурацию базы данных, после чего удалим ненужный объект и повторим попытку обновления.

Альтернативный вариант: перенос данных в чистую базу целевого релиза

Если база содержит критическое количество ошибок структуры метаданных, а разница между текущим и целевым релизом слишком велика, наиболее безопасным решением будет перенос данных:

1. Развернем типовую чистую конфигурацию целевого релиза (2.0.66.х).
2. С помощью типовой обработки ВыгрузкаЗагрузкаДанныхXML перенесем справочники, документы и регистры из старой базы в новую.
3. Выполним проведение документов и проверку контрольных отчетов (оборотно-сальдовой ведомости). Такой подход полностью исключает миграцию поврежденных метаданных и гарантирует стабильную работу информационной базы.