Смена GUID в 1С:Предприятии: ссылки, метаданные и база

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

Штатно GUID в 1С:Предприятии не редактируется ни в одном поле формы — он присваивается при создании. Чтобы его сменить, объект обычно пересоздают с нужным идентификатором средствами встроенного языка, правят в выгрузке конфигурации или управляют им при обмене через COM. Ниже — какой именно идентификатор меняют в каждом случае и каким способом.

С каким идентификатором вы имеете дело

Прежде чем что-то менять, определите, о каком GUID речь. От этого зависит и способ, и то, выполнимо ли это вообще.

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

Понятно и когда это вообще нужно. UUID ссылки меняют при переносе данных между базами, когда ссылки в источнике и приёмнике обязаны совпасть, или при разборе задвоений после неудачного обмена. Идентификатор объекта конфигурации трогают при объединении двух конфигураций в одну. Идентификатор базы — когда рядом с рабочей базой развёрнута её копия, и внешние сервисы путают их между собой. Во всех остальных ситуациях идентификаторы лучше не трогать: они на то и уникальны, чтобы оставаться постоянными.

Как сменить UUID ссылки на элемент данных

Самый частый запрос — поменять GUID конкретного элемента справочника или документа. У записанного объекта UUID ссылки изменить нельзя: ссылка неизменна с момента записи. Рабочий приём — создать новый элемент и явно задать ему нужную ссылку до первой записи.

Сначала получите текущий UUID, чтобы было с чем сравнивать:

// Строковое представление UUID ссылки
Текст = XMLСтрока(ЭлементСсылка);
// Или сам объект идентификатора
УИД = ЭлементСсылка.УникальныйИдентификатор();

Теперь создаём новый элемент с заданным UUID. Метод УстановитьСсылкуНового работает ТОЛЬКО у нового, ещё не записанного объекта — задать ссылку уже существующему он не даст:

НовыйУИД = Новый УникальныйИдентификатор("3d9f1e2a-1b4c-4e8a-9c0d-5f6a7b8c9d0e");
НоваяСсылка = Справочники.Номенклатура.ПолучитьСсылку(НовыйУИД);

Элемент = Справочники.Номенклатура.СоздатьЭлемент();
Элемент.УстановитьСсылкуНового(НоваяСсылка);
Элемент.Наименование = "Перенесённая позиция";
// ...перенесите остальные реквизиты...
Элемент.Записать();

После этого у вас два элемента: старый и новый с нужным UUID. Дальше нужно:

1. 📎 перепривязать документы и регистры, которые ссылались на старый элемент, на новый;
2. 🗑️ пометить старый элемент на удаление и выполнить Удаление помеченных объектов;
3. ✅ проверить, что остатки и обороты по регистрам не разъехались.

Пакетно пройтись по коллекции и получить UUID каждого элемента можно так:

Запрос = Новый Запрос("ВЫБРАТЬ Ссылка ИЗ Справочник.Номенклатура");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
	Сообщить(Выборка.Ссылка.Наименование + " = " + XMLСтрока(Выборка.Ссылка));
КонецЦикла;

Идентификатор объекта метаданных через выгрузку конфигурации

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

Единственный поддерживаемый путь — выгрузка конфигурации в XML, правка идентификатора в файле и обратная загрузка.

1. В Конфигураторе откройте Конфигурация → Выгрузить конфигурацию в файлы… и укажите пустую папку.
2. Найдите XML-файл нужного объекта. У корневого элемента объекта есть атрибут uuid — это и есть искомый идентификатор.
3. Замените значение атрибута на нужное (формат — стандартная строка UUID из 32 шестнадцатеричных символов с дефисами).
4. Загрузите конфигурацию обратно: Конфигурация → Загрузить конфигурацию из файлов….
5. Выполните Обновить конфигурацию базы данных (F7).

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

Идентификатор информационной базы и узлов обмена

Здесь чаще всего и возникает путаница. Единого «GUID базы», который меняют одной кнопкой, в 1С нет. Под этим понимают разные вещи, и действовать нужно по ситуации.

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

Узлы плана обмена и РИБ. В распределённой информационной базе узлы различаются не «GUID», а кодом и предопределённым признаком главного узла. Если нужно, чтобы периферийная база считалась новой, создают новый узел в плане обмена и заново формируют начальный образ. Старые регистрации обмена при этом не переносят — иначе две базы начнут конфликтовать при синхронизации.

Идентификатор для онлайн-сервисов. Когда базу разворачивают из резервной копии рядом с рабочей, внешние сервисы (например, механизмы автообновления и подключения к поддержке) могут принять копию за оригинал. В этом случае идентификатор базы для сервисов сбрасывают в разделе Администрирование → Интернет-поддержка и сервисы — отключают и заново подключают поддержку у копии, чтобы она получила собственную регистрацию.

Перенос данных через COM с сохранением GUID

Внешнее подключение по COM используют, когда данные гонят из одной базы в другую программно и важно, чтобы ссылки на объекты совпадали — то есть чтобы в базе-приёмнике элемент получил тот же UUID, что в источнике. Это и есть смысл «смены GUID через внешние компоненты и COM».

Подключение к базе-приёмнику:

Коннектор = Новый COMObject("V83.COMConnector");
СтрокаСоединения = "File=""C:\Bases\Target"";Usr=""Администратор"";Pwd=""""";
Приёмник = Коннектор.Connect(СтрокаСоединения);

Дальше в приёмнике объект создают с тем же UUID, что был в источнике, через уже знакомый УстановитьСсылкуНового:

УИД = Новый УникальныйИдентификатор(СтрокаUUIDИзИсточника);
НоваяСсылка = Приёмник.Справочники.Номенклатура.ПолучитьСсылку(УИД);
Элемент = Приёмник.Справочники.Номенклатура.СоздатьЭлемент();
Элемент.УстановитьСсылкуНового(НоваяСсылка);
Элемент.Наименование = НаименованиеИзИсточника;
Элемент.Записать();

Так ссылки в обеих базах сойдутся, и документы, перенесённые следом, найдут свои элементы по UUID без ручной перепривязки.

Несколько практических моментов:

• 🔢 Разрядность COM-соединения должна совпадать с разрядностью COM-объекта: 64-разрядный V83.COMConnector регистрируется отдельно, под 32-разрядный платформу ставят в режиме совместимости.
• 🔐 COM-соединение работает под указанным пользователем базы — у него должны быть права на запись нужных объектов.
• 🧩 Для разовых переносов часто удобнее не COM, а штатная выгрузка/загрузка через Конвертацию данных или правила обмена, где сопоставление по UUID настраивается без кода.

Почему не стоит менять UUID напрямую в SQL

В клиент-серверном варианте ссылки хранятся в полях типа binary(16) (поле вида _IDRRef и ссылочные реквизиты _Fld…RRef). Теоретически значение можно переписать SQL-запросом прямо в СУБД. На практике это худший из вариантов, и вот почему.

• ❌ Ссылка на один объект лежит не в одном месте, а во всех таблицах, где он используется: документы, регистры, подчинённые справочники. Поменяете в одной таблице — связи порвутся в остальных.
• ❌ Платформа кэширует структуру и данные; прямая правка в обход платформы приводит к рассинхронизации кэша и ошибкам «объект не найден».
• ❌ Любое изменение данных в СУБД в обход 1С выводит базу из поддерживаемого состояния: при обращении в поддержку такую правку вам не простят.

Если очень нужно разобраться, где лежит конкретная ссылка, смотрите соответствие таблиц и полей через Администрирование → Структура хранения базы данных в Конфигураторе — но для чтения, а не для записи. Там видно, в каких таблицах СУБД хранится объект и как называются ссылочные поля, что помогает оценить масштаб связей, прежде чем что-то менять.

Отдельно стоит помнить про формат хранения: UUID в поле binary(16) записан не в том же порядке байтов, в каком вы видите его в строке XMLСтрока(Ссылка). Байты в СУБД переставлены, поэтому попытка подставить «красивую» строку из интерфейса прямо в SQL почти наверняка даст не ту ссылку. Это ещё одна причина не лезть в базу напрямую: даже чтение требует аккуратности, а запись легко превращает рабочую базу в набор битых ссылок. Всё, что нужно сделать со ссылками, делается встроенным языком — медленнее, но предсказуемо и в поддерживаемом состоянии.

Проверка результата и типичные сбои

После смены идентификатора проверьте, что данные не осыпались. Минимальный набор:

1. 🔍 Откройте перенесённый объект и убедитесь, что XMLСтрока(Ссылка) возвращает ожидаемый UUID.
2. 📊 Сверьте остатки и обороты по регистрам до и после операции — расхождения выдадут порванные ссылки.
3. 🧪 Запустите Тестирование и исправление (chdbfl для файловой базы или штатный режим в Конфигураторе) и проверьте ссылочную целостность.

Самые частые проблемы при смене GUID:

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