Справочник «Идентификаторы объектов метаданных»: как привести его в порядок

Обновление идентификаторов объектов метаданных в 1С 8.3 почти всегда выполняется само: при запуске базы после обновления конфигурации программа сверяет состав метаданных со справочником Идентификаторы объектов метаданных и дописывает изменения. Вручную вмешиваться нужно, когда это автоматическое обновление сорвалось: база не запускается с ошибкой про справочник, в РИБ узлы разошлись или после доработки конфигурации появились дубли.

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

Зачем 1С хранит идентификаторы объектов метаданных

Справочник Идентификаторы объектов метаданных входит в Библиотеку стандартных подсистем (БСП). Он есть во всех типовых конфигурациях на БСП: Бухгалтерии 3.0, ЗУП 3.1, УТ 11, КА, ERP, УНФ. Это механизм не платформы, а библиотеки, поэтому в самописных конфигурациях без БСП его нет.

Зачем он нужен. Платформа не позволяет хранить в реквизите ссылку на «объект метаданных» как на значение. А подсистемам БСП это постоянно требуется:

• 🔐 права доступа — ограничения задаются на конкретные таблицы;
• 📎 присоединённые файлы, дополнительные реквизиты и свойства — привязка к виду объекта;
• 📊 варианты отчётов — к какому отчёту относится вариант;
• 🗂 обработчики обновления, история изменений, печатные формы.

Поэтому каждому справочнику, документу, регистру, отчёту и обработке соответствует элемент справочника. В нём хранятся полное имя (Справочник.Номенклатура), синоним, ключ объекта метаданных и признак «удалён». Остальные данные базы ссылаются уже на этот элемент.

Что такое «UUID» в этом контексте

Под «UUID объектов метаданных» обычно понимают одно из двух:

Когда говорят «обновить идентификаторы», речь идёт о синхронизации справочника с текущим составом конфигурации. Менять сами UUID вручную не требуется и опасно: все ссылки на старый элемент станут битыми.

Когда синхронизация ломается

• 🔄 объект удалили и создали заново с тем же именем: у него новый ключ, а в справочнике остался старый элемент;
• ✏️ объект переименовали одновременно с другими крупными правками, и сопоставление сработало неоднозначно;
• 🧩 конфигурацию «сравнили и объединили» с другой, где объект создан независимо;
• 🌐 в РИБ структуру изменили в подчинённом узле, а не в главном;
• ⛔ обновление прервали на середине: закрыли окно, оборвалась связь с сервером.

Подготовка: резервная копия и проверка базы

Обновление справочника меняет данные, на которые ссылается половина служебных подсистем. Поэтому до любых ручных действий нужна копия.

Что проверить до начала:

1. Версию конфигурации базы данных. В Конфигураторе откройте Конфигурация → Конфигурация базы данных. Если основная конфигурация отличается от конфигурации базы, сначала выполните Обновить конфигурацию базы данных (F7).
2. Расширения. Отключите на время диагностики расширения сторонних разработчиков. Для их объектов БСП ведёт отдельный справочник Идентификаторы объектов расширений, и ошибки в нём легко спутать с основными.
3. Права пользователя. Ручное обновление выполняет только пользователь с ролью полных прав.
4. Активные сеансы. Пользователи в момент обновления должны выйти. Предупредите их заранее: принудительное завершение сеансов обрывает несохранённую работу.
5. Тестирование и исправление. При подозрении на повреждение данных запустите в Конфигураторе Администрирование → Тестирование и исправление с режимом проверки логической целостности. Режим требует монопольного доступа. Сначала проверку без исправления, чтобы понять масштаб.

💡 Проверять последовательность действий удобнее на копии: разверните .dt в отдельную базу и прогоните там всё, что описано ниже.

Способы обновления идентификаторов объектов метаданных

Выбор зависит от того, запускается ли база и насколько глубоко разошлись данные.

Способ 1. Штатный запуск

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

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

Способ 2. Принудительный повторный запуск обновления

Если штатное обновление уже отметилось как выполненное, а справочник остался в неверном состоянии, запустите клиент с параметром БСП ЗапуститьОбновлениеИнформационнойБазы:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /C"ЗапуститьОбновлениеИнформационнойБазы"

Для клиент-серверной базы вместо /F укажите /S"сервер\имя_базы". Параметр заставляет программу заново пройти процедуру обновления, включая сверку справочника идентификаторов.

Способ 3. Программный вызов

В БСП у менеджера справочника есть экспортная процедура ОбновитьДанныеСправочника. Её можно вызвать из внешней обработки в серверной процедуре:

&НаСервереБезКонтекста
Процедура ОбновитьИдентификаторыНаСервере()
	ЕстьИзменения = Ложь;
	ЕстьУдаленные = Ложь;
	Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(ЕстьИзменения, ЕстьУдаленные);
	Сообщить("Изменения: " + Формат(ЕстьИзменения, "БЛ=нет; БИ=да")
		+ ", удалённые объекты: " + Формат(ЕстьУдаленные, "БЛ=нет; БИ=да"));
КонецПроцедуры

Состав параметров зависит от версии БСП. Перед запуском откройте модуль менеджера справочника в Конфигураторе и сверьте сигнатуру процедуры. Если параметров другое количество — подстройте вызов под свою версию.

Способ 4. Ручная правка элементов

Крайняя мера, когда автоматическое обновление стабильно падает на одном объекте. Этот вариант подробно разобран в следующем разделе на примере справочника.

Пошаговый разбор: идентификатор справочника после пересоздания

Пример. В конфигурации был справочник Справочник.Контрагенты_Доп. Разработчик удалил его и создал заново с тем же именем. После обновления базы при запуске появляется ошибка о том, что в справочнике идентификаторов найдено несколько элементов с одинаковым полным именем, либо элемент не удаётся сопоставить с объектом.

Элементы удалённых из конфигурации объектов программа сама не стирает: на них могут ссылаться данные. Она помечает их как удалённые. Чистить их руками не нужно — на работу базы они не влияют.

Ошибки при обновлении идентификаторов и что с ними делать

Тексты ошибок отличаются в разных версиях БСП, поэтому ниже — смысл сообщения и порядок действий. Точный текст всегда есть в журнале регистрации: Администрирование → Обслуживание → Журнал регистрации, отбор по уровню «Ошибка».

Если ничего не помогло

• 🧪 Разверните копию базы и попробуйте обновить её на последний релиз типовой конфигурации. В новых версиях БСП исправлено много частных случаев сопоставления.
• 🧾 Проверьте, не сохранилось ли в конфигурации двух объектов с одинаковым синонимом и разными именами — это путает пользователей при ручной правке, хотя программе не мешает.
• 📨 Соберите текст ошибки, версию платформы, версию конфигурации и БСП и передайте разработчику, который сопровождает базу. Без журнала регистрации разбирать такие случаи вслепую бесполезно.

Идентификаторы метаданных в распределённой информационной базе

В РИБ справочник Идентификаторы объектов метаданных заполняется только в главном узле. Подчинённые узлы получают его элементы с обменом вместе с изменениями конфигурации. Так ссылки на идентификаторы совпадают во всех узлах.

Правильный порядок обновления:

1. Обновите конфигурацию в главном узле и обновите конфигурацию базы данных.
2. Войдите в главный узел в режиме «Предприятие» и дождитесь окончания обновления.
3. Выполните синхронизацию с подчинёнными узлами.
4. В подчинённом узле примите данные. Программа предложит принять изменения конфигурации и перезапуститься.
5. После перезапуска узел завершит обновление сам.

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

Как не допускать сбоев: профилактика и автоматизация

Большинство проблем со справочником создаётся при доработке конфигурации. Несколько правил для разработчиков и администраторов:

• 🛠 доработки типовой конфигурации выносите в расширения: основная конфигурация остаётся типовой и обновляется без конфликтов;
• 🏷 не удаляйте и не пересоздавайте объекты ради смены структуры — меняйте существующие;
• 🔀 при объединении конфигураций смотрите, не появляется ли объект с тем же именем из другого источника;
• 🧱 в РИБ меняйте структуру только в главном узле;
• 🕒 обновляйте базу в нерабочее время, с запасом времени на первый запуск.

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

1. Пакетный запуск Конфигуратора с выгрузкой .dt: 1cv8.exe DESIGNER ... /DumpIB"D:\Backup\buh.dt".
2. Обновление конфигурации базы данных: /UpdateDBCfg.
3. Запуск «Предприятия» с параметром ЗапуститьОбновлениеИнформационнойБазы под служебным пользователем с полными правами.
4. Проверка журнала регистрации на ошибки за время работы скрипта.

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

Частые вопросы