Как поменять GUID объекта в 1С

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

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

Ниже разобраны рабочие способы: через обработку с методом УстановитьСсылкуНового, через перенос данных на новую ссылку, а также вариант правки на уровне СУБД для файловых и клиент-серверных баз. Отдельно описано, как проверить результат и какие ошибки встречаются чаще всего.

Когда вообще нужно менять GUID объекта

Самая частая ситуация — рассинхронизация двух баз. Например, контрагент «Ромашка» создан вручную и в Бухгалтерии, и в Управлении торговлей. В каждой базе он получил свой GUID, и типовая синхронизация воспринимает их как два разных объекта, создавая дубли при каждом обмене. Приведение GUID к одному значению решает проблему на корню.

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

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

Маршрут решения

Как выбрать действие

Нужно, чтобы объект в двух базах имел один GUIDИспользуйте обработку с УстановитьСсылкуНового и переносом данных на новую ссылку

GUID нужно поменять у нескольких тысяч объектов разомРассмотрите пакетную обработку или перенос через конвертацию данных с сохранением идентификаторов

Объект участвует в типовой синхронизации данныхСначала проверьте регистрацию в планах обмена — смена GUID без очистки регистрации даст дубли и коллизии

Есть доступ к СУБД и объект одинВозможна прямая правка в таблицах, но только при понимании структуры хранения и после бэкапа

Почему нельзя просто отредактировать GUID у существующей ссылки

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

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

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

Способ 1. Обработка с методом УстановитьСсылкуНового

Основной и наиболее контролируемый способ — небольшая внешняя обработка на встроенном языке. Логика такая: получаем новую ссылку с требуемым GUID, копируем в неё данные старого объекта, записываем, затем заменяем ссылки и удаляем старый элемент.

Ключевой фрагмент кода для справочника выглядит следующим образом. Сначала формируем новую ссылку из строки GUID, затем создаём объект-копию и записываем его с принудительной установкой ссылки:

НоваяСсылка = Справочники.Контрагенты.ПолучитьСсылку(
Новый УникальныйИдентификатор("8f4da0b1-1234-5678-9abc-def012345678"));

НовыйОбъект = СтарыйОбъект.Скопировать();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
НовыйОбъект.ОбменДанными.Загрузка = Истина;
НовыйОбъект.Записать();

Режим ОбменДанными.Загрузка = Истина отключает бизнес-проверки и подписки на события, что ускоряет запись и исключает побочные эффекты. Но это же означает, что контроль корректности данных полностью ложится на вас: проверки заполнения, нумерация и обработчики не сработают.

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

1. 1
   Сделайте резервную копию базы и убедитесь, что она открывается
2. 2
   Получите целевой GUID — из базы-источника, файла обмена или внешней системы
3. 3
   Сформируйте новую ссылку методом ПолучитьСсылку с нужным идентификатором
4. 4
   Скопируйте объект, установите ссылку нового через УстановитьСсылкуНового и запишите
5. 5
   Выполните поиск и замену всех ссылок со старого объекта на новый
6. 6
   Пометьте старый объект на удаление и выполните удаление помеченных
7. 7
   Проверьте отсутствие битых ссылок и корректность обмена

Способ 2. Прямая замена на уровне базы данных

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

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

Единственный сценарий, где прямую правку применяют на практике, — аварийное восстановление в тестовой копии базы опытным специалистом с последующей полной проверкой ссылочной целостности через Тестирование и исправление. В рабочей базе так делать не следует.

Способ 3. Предотвращение проблемы при обмене данными

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

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

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

Сравнение подходов

Обработка с УстановитьСсылкуНового

Контролируемый и безопасный путь для одиночных объектов; требует замены ссылок по всей базе

Прямая правка в СУБД

Быстро, но опасно: битые ссылки, нарушение поддержки; только для тестовых копий

Настройка правил обмена

Не меняет данные вообще; подходит, когда проблема в дублях при синхронизации

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

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

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

Контрольные точки

Как проверить результат

GUID объекта после операции

Норма

Совпадает с целевым идентификатором из базы-источника

Тревожный признак

Остался прежним или отличается от нужного

Ссылки на старый объект

Норма

Поиск по ссылкам не находит ни одного упоминания

Тревожный признак

Найдены документы или регистры со старой ссылкой

Ссылочная целостность

Норма

Тестирование и исправление не выявляет битых ссылок

Тревожный признак

В документах появляются записи «Объект не найден»

Синхронизация с другой базой

Норма

Объект сопоставляется один-к-одному, дублей нет

Тревожный признак

При обмене создаются дубли или возникают коллизии

Ограничения и особые случаи

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

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

Учитывайте и права доступа: операции с ОбменДанными.Загрузка и массовой заменой ссылок требуют полных прав, а в базах с разграничением доступа часть объектов может быть недоступна вашей обработке, и замена пройдёт не полностью.

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

Можно ли поменять GUID без программирования?

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

Что будет, если в двух базах у одного объекта разные GUID?

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

Как узнать GUID объекта в 1С?

Программно — через выражение Ссылка.УникальныйИдентификатор(). Интерактивно можно открыть объект через консоль кода или посмотреть идентификатор в адресной строке веб-клиента, где ссылка присутствует в параметрах. Также GUID виден в файлах выгрузки обмена данными в формате XML.

Опасно ли менять GUID у документа с движениями?

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

Почему после смены GUID в обмене появились дубли?

Наиболее вероятная причина — старая регистрация изменений в планах обмена. Объект остался зарегистрированным к выгрузке под старым идентификатором, и при обмене в другую базу ушли обе версии. Перед сменой GUID снимите регистрацию старого объекта во всех узлах планов обмена, а после замены зарегистрируйте новый при необходимости.

Можно ли задать GUID при создании объекта сразу?

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