Как изменить уникальный идентификатор элемента справочника в 1С

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

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

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

Что такое GUID в 1С и почему его нельзя просто поменять

Уникальный идентификатор — это 128-битное значение, которое платформа присваивает каждому объекту при создании. В текстовом виде он выглядит как строка вида b2c3d4e5-... из шестнадцатеричных символов. Именно GUID хранится в поле ссылки таблиц базы данных, и все документы, регистры и другие справочники ссылаются на элемент именно по нему.

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

Как узнать текущий GUID элемента

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

Элемент = Справочники.Номенклатура.НайтиПоКоду("000000123");
Сообщить(Элемент.Ссылка.УникальныйИдентификатор());

Если под рукой нет консоли кода, GUID можно увидеть в адресной строке браузера при работе через веб-клиент — идентификатор присутствует в ссылке на объект. Также идентификатор виден в отладчике: достаточно остановиться на переменной со ссылкой и раскрыть её свойства.

Обратную задачу — найти объект по известному GUID — решает метод ПолучитьСсылку():

Ид = Новый УникальныйИдентификатор("b2c3d4e5-1111-2222-3333-444455556666");
Ссылка = Справочники.Номенклатура.ПолучитьСсылку(Ид);
Если Ссылка.ПолучитьОбъект() = Неопределено Тогда
Сообщить("Объект с таким GUID не найден");
КонецЕсли;

Способ 1: создание элемента с заданным GUID через УстановитьСсылкуНового

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

НужныйИд = Новый УникальныйИдентификатор("b2c3d4e5-1111-2222-3333-444455556666");
НоваяСсылка = Справочники.Номенклатура.ПолучитьСсылку(НужныйИд);

НовыйЭлемент = Справочники.Номенклатура.СоздатьЭлемент();
НовыйЭлемент.УстановитьСсылкуНового(НоваяСсылка);
НовыйЭлемент.Код = "000000123";
НовыйЭлемент.Наименование = "Нужный элемент";
НовыйЭлемент.Записать();

После записи в базе существует элемент именно с тем идентификатором, который требовался. Этот приём безопасен при одном обязательном условии: объект с таким GUID ещё не существует в базе. Если он существует, запись завершится ошибкой либо приведёт к конфликту — поэтому предварительная проверка через ПолучитьСсылку() и ПолучитьОбъект() обязательна.

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

1. 1
   Сделайте резервную копию базы или выгрузку DT
2. 2
   Определите текущий GUID элемента и целевой GUID
3. 3
   Проверьте, что объект с целевым GUID не существует
4. 4
   Создайте новый элемент с УстановитьСсылкуНового и скопируйте данные
5. 5
   Выполните поиск и замену ссылок со старого элемента на новый
6. 6
   Проверьте результат и удалите старый элемент

Способ 2: типовая обработка поиска и удаления дублей

Если изменение GUID нужно из-за дублей после обмена (один и тот же контрагент или товар существует в двух экземплярах с разными идентификаторами), правильнее использовать типовой механизм. В конфигурациях на БСП (УТ, ERP, Бухгалтерия) есть обработка «Поиск и удаление дублей»: Администрирование → Обслуживание → Корректировка данных.

Обработка находит элементы с совпадающими реквизитами, позволяет выбрать «главный» элемент и автоматически заменяет ссылки на дубли во всех документах, регистрах и других справочниках, после чего помечает дубли на удаление. GUID главного элемента при этом не меняется — но ссылочная структура приводится к единому объекту, что обычно и является конечной целью.

Этот способ предпочтительнее ручного пересоздания: он не требует кода, контролирует целостность ссылок и работает в пользовательском режиме. Ограничение — обработка не поможет, если нужен конкретный заранее известный GUID (например, чтобы совпасть с другой базой), а не просто устранение дублей.

Способ 3: прямая правка идентификатора в СУБД

В клиент-серверных базах GUID физически хранится в поле _IDRRef таблицы справочника. Теоретически его можно изменить SQL-запросом UPDATE. На практике это крайняя мера: ссылка хранится не только в таблице самого справочника, но и во всех таблицах, где есть реквизиты этого типа, — в документах, регистрах сведений, накопления, планах обмена. Пропуск хотя бы одной таблицы создаёт битые ссылки, которые проявятся не сразу.

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

Замена ссылок после смены GUID

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

Первый — типовая обработка «Поиск и замена значений» (также входит в БСП, раздел «Администрирование → Обслуживание»). Она находит все вхождения старой ссылки и заменяет их на новую в интерактивном режиме, показывая список затронутых объектов.

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

МассивСсылок = Новый Массив; МассивСсылок.Добавить(СтараяСсылка); Найденные = НайтиПоСсылкам(МассивСсылок); Для Каждого Строка Из Найденные Цикл Сообщить(Строка(Строка.Данные)); КонецЦикла;

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

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

Когда менять GUID не нужно: альтернативы

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

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

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