Как поменять GUID в 1С: пошаговое руководство для специалиста

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

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

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

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

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

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

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

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

Перед любой манипуляцией с идентификаторами сделайте полную резервную копию базы. Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей либо выполнить выгрузку в dt через конфигуратор. Для клиент-серверной базы используйте штатные средства СУБД: backup в MS SQL, pg_dump в PostgreSQL.

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

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

Способ 1. Внешняя обработка замены GUID

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

Общий порядок работы с такой обработкой одинаков: открыть её через «Файл → Открыть» в режиме предприятия, указать объект-источник, задать целевой GUID (или объект, чей GUID нужно присвоить), запустить выполнение и дождаться отчёта о заменённых ссылках. Обработка в транзакции заменяет ссылки во всех найденных таблицах.

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

Способ 2. Пересоздание объекта кодом

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

Ключевой метод — УстановитьСсылкуНового, которому передаётся объект СправочникСсылка или ДокументСсылка, созданный через ПолучитьСсылку с параметром Новый УникальныйИдентификатор. После записи нового объекта старый помечается на удаление, а ссылки переназначаются типовым механизмом поиска и замены.

НовыйGUID = Новый УникальныйИдентификатор("a1b2c3d4-e5f6-7890-abcd-ef1234567890");
НоваяСсылка = Справочники.Номенклатура.ПолучитьСсылку(НовыйGUID);
НовыйОбъект = Справочники.Номенклатура.СоздатьЭлемент();
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
НовыйОбъект.Наименование = СтарыйОбъект.Наименование;
// перенос остальных реквизитов и табличных частей
НовыйОбъект.Записать();

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

Способ 3. Прямое изменение в таблицах СУБД

В клиент-серверной базе GUID хранится в поле _IDRRef (для ссылочных таблиц) в бинарном виде. Администраторы иногда меняют его напрямую запросом UPDATE, когда объектов много и обработка работала бы слишком долго. Это самый быстрый, но и самый рискованный способ.

Главная сложность — ссылки на объект разбросаны по десяткам таблиц: реквизиты документов, регистры сведений, регистры накопления, табличные части. Обновить нужно все, иначе появятся битые ссылки. Тип поля и порядок байт GUID в MS SQL и PostgreSQL отличаются от строкового представления, поэтому значение нужно корректно преобразовать.

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

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

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

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

Проверка результата и восстановление целостности

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

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

Ограничения и когда лучше привлечь специалиста

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

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

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