Как присвоить объекту нужный GUID в 1С 8.3 и не сломать базу

Напрямую изменить GUID у уже существующего объекта в 1С нельзя: уникальный идентификатор элемента справочника или документа доступен только для чтения. Но задать новому объекту заранее известный GUID вполне реально — через код с методом УстановитьСсылкуНового или через выгрузку и загрузку данных в формате XML, которая сохраняет идентификаторы при переносе.

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

Что такое GUID и почему его просто так не переписать

GUID (он же UUID, уникальный идентификатор) — это внутренний ключ объекта. У каждой ссылки на элемент справочника, документ, план счетов и прочие объекты ссылочного типа есть свой 16-байтовый идентификатор вида f8b4e2a1-3c7d-4e2f-9a1b-0c5d6e7f8091. Платформа хранит его в поле _IDRRef таблицы объекта и использует как первичный ключ: все связи между документами, движения по регистрам, значения реквизитов-ссылок указывают именно на него, а не на код или наименование.

Получить идентификатор из кода можно так:

ИД = Элемент.Ссылка.УникальныйИдентификатор();
Сообщить(Строка(ИД)); // f8b4e2a1-3c7d-4e2f-9a1b-0c5d6e7f8091

Метод УникальныйИдентификатор() возвращает значение, но присвоить ему новое нельзя — свойства для записи у ссылки нет. Причина не в прихоти разработчиков платформы: идентификатор — это и есть личность объекта в базе. Поменять его «на месте» означало бы одновременно переписать ссылки во всех таблицах, где объект упомянут, иначе связи порвутся.

Как задать новому объекту нужный GUID через код

Единственный штатный способ записать объект с заранее выбранным GUID — присвоить ссылку ещё не записанному объекту методом УстановитьСсылкуНового. Работает только для нового объекта и только если такого идентификатора в базе ещё нет.

// Готовим ссылку с нужным идентификатором
НужныйИД = Новый УникальныйИдентификатор("f8b4e2a1-3c7d-4e2f-9a1b-0c5d6e7f8091");
Ссылка   = Справочники.Номенклатура.ПолучитьСсылку(НужныйИД);

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

Метод ПолучитьСсылку отдаёт ссылку с указанным идентификатором, даже если объекта с таким GUID пока нет — это просто «обёртка». УстановитьСсылкуНового закрепляет её за создаваемым объектом, и после Записать() элемент получает именно этот GUID.

Платформа следит за уникальностью: два объекта с одинаковым идентификатором в базе существовать не могут. Если попытаться записать новый объект с GUID, который уже занят, запись завершится ошибкой. Поэтому «переселить» идентификатор можно только на тот объект, который в базе ещё не создан.

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

НужныйИД = Новый УникальныйИдентификатор("...");
Ссылка   = Документы.РеализацияТоваровУслуг.ПолучитьСсылку(НужныйИД);
Док = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
Док.УстановитьСсылкуНового(Ссылка);
// перенос реквизитов шапки
ЗаполнитьЗначенияСвойств(Док, СтарыйДокумент);
Док.Записать(Новый СтруктураДополнительныхСвойствЗаписи, РежимЗаписиДокумента.Проведение);

Чтобы перенести реквизиты из старого объекта, удобно использовать ЗаполнитьЗначенияСвойств(Новый, Старый) — она копирует совпадающие по имени реквизиты. Табличные части переносят отдельно, например Новый.Товары.Загрузить(Старый.Товары.Выгрузить()).

Порядок действий, когда нужно «сменить» идентификатор у существующего объекта:

1. Создайте новый объект и задайте ему целевой GUID описанным способом.
2. Скопируйте в него все реквизиты и табличные части старого объекта.
3. Перенесите на новый объект ссылки из всех документов и регистров (вручную это нереально — используйте обработку объединения, см. ниже).
4. Пометьте на удаление старый объект и удалите его через Операции → Удаление помеченных объектов.

Перенос объектов с сохранением идентификатора

Когда объекты нужно перенести из одной базы в другую и сохранить их GUID (чтобы связи и последующие обмены не сломались), применяют типовую обработку «Выгрузка и загрузка данных в формате XML». Она сериализует объект вместе с идентификатором: в базе-приёмнике элемент появляется с тем же GUID, что и в источнике.

Обработка внешняя, поставляется 1С и подходит для переноса между базами одной конфигурации (или совместимых по структуре). Общая логика:

• в базе-источнике выбираете типы и отбор объектов, получаете файл XML;
• в базе-приёмнике загружаете этот файл;
• объекты записываются с исходными идентификаторами, ссылки между ними восстанавливаются автоматически.

Это основной инструмент, когда задача — «чтобы в новой базе был объект с таким же GUID, как в старой». Для разовых точечных переносов он удобнее кода, потому что сам тянет связанные объекты по ссылкам.

Массовая правка: объединение дублей и инструменты

Чаще под «массовым изменением GUID» на самом деле понимают другое — свести несколько объектов-дублей к одному. Для этого в типовых конфигурациях есть обработка «Поиск и удаление дублей» (Администрирование → Обслуживание → Поиск и удаление дублей в БП 3.0; в других конфигурациях — раздел администрирования или сервиса).

Что она делает:

1. Находит похожие элементы по заданным правилам (по наименованию, ИНН и т.п.).
2. Позволяет выбрать один элемент как оригинал.
3. Переносит все ссылки с дублей на оригинал — во всех документах и регистрах.
4. Помечает дубли на удаление.

Идентификатор у оригинала при этом остаётся прежним. Для бизнес-задачи «чтобы везде был один контрагент» результат тот же, что и смена GUID, но без ручной правки ссылок и без риска для целостности.

Таблица — чем какой инструмент хорош:

А вот правка GUID напрямую в SQL-таблицах (_Reference<N>, поле _IDRRef) — то, чего делать не стоит. Идентификатор хранится в бинарном виде, его нужно было бы синхронно переписать во всех таблицах-ссылках, а любое расхождение превращает базу в неработоспособную. Такой способ не поддерживается, гарантий целостности нет, и при обращении в поддержку базу после ручных правок SQL чинить не возьмутся.

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

Главный риск — порванные ссылки. Если GUID объекта изменился, а документы ссылаются на старый, в них появятся «битые» ссылки: вместо контрагента или номенклатуры будет <Объект не найден> с указанием прежнего идентификатора.

Отдельная зона риска — обмены и синхронизация:

• 🔄 В распределённой базе (РИБ) объекты узлов сопоставляются именно по GUID. Если на одном узле заменить идентификатор, на остальных узлах появится дубль, а не обновлённый объект.
• 🔗 При синхронизации между базами (например, Бухгалтерия ↔ ЗУП) соответствие объектов тоже строится на идентификаторах. Смена GUID на одной стороне разорвёт пару, и объект приедет повторно.
• 📤 Внешние системы, интеграции и сохранённые отчёты, где зашит конкретный идентификатор, перестанут находить объект.

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

Когда GUID менять не нужно — и что сделать вместо этого

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

Отдельно про бизнес-идентификаторы: если во внешней системе объект опознаётся по своему коду, не пытайтесь подогнать под него GUID. Добавьте реквизит под внешний идентификатор (или используйте регистр сведений для хранения соответствия) — это надёжнее и не ломает внутренние связи 1С.

Реальные сценарии, где смена GUID оправдана

Ситуаций, где действительно нужно управлять идентификатором, немного, но они встречаются:

• Слияние двух баз. Компании объединились, у каждой своя база. Чтобы один и тот же контрагент не задвоился после переноса, объекты заранее приводят к общим идентификаторам — переносом XML из одной базы и настройкой сопоставления.
• Настройка обмена между независимо созданными базами. Справочники заполнялись раздельно, GUID разные. Чтобы синхронизация связала объекты автоматически, а не плодила дубли, одну сторону выгружают в другую с сохранением идентификаторов.
• Восстановление «потерянного» объекта. Элемент удалили, а на него ссылались документы. Если известен его прежний GUID, можно создать объект заново с тем же идентификатором методом УстановитьСсылкуНового — и старые ссылки снова станут рабочими.

Во всех трёх случаях меняют не идентификатор у живого объекта, а создают или переносят объект с нужным GUID на чистом участке — на копии или в базе-приёмнике.

Как проверить, что ничего не сломалось

После любой операции с идентификаторами проверьте целостность ссылок, пока изменения ещё можно откатить из копии.

Где смотреть связи конкретного объекта: в форме элемента или в списке по правой кнопке мыши есть команда Связанные документы (в части конфигураций — Перейти → Связанные документы). Она показывает, какие документы ссылаются на объект. Если после переноса там пусто, а раньше связи были, — ссылки ушли на старый идентификатор, нужно переносить.

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

Для общей проверки базы используйте Конфигуратор → Администрирование → Тестирование и исправление с включённой проверкой логической целостности. Режим требует монопольного доступа к базе, поэтому запускайте его, когда в базе никто не работает , — иначе сеансы пользователей будут прерваны.

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