Как исправить ошибку неуникального GUID-префикса при настройке синхронизации 1С

← На главную

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

Причина возникновения ошибки: эффект «клонированной» базы

Разберем ситуацию, которая приводит к подобным сбоям. В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) для идентификации баз в распределенной системе используется не только буквенный префикс (например, "УТ" или "БП"), но и уникальный глобальный идентификатор в формате GUID. Этот идентификатор генерируется один раз при создании базы или первом включении механизма синхронизации.

Проанализируем сценарий появления ошибки: администратор создает копию работающей базы (например, для тестов или для новой организации), просто копируя файл 1Cv8.1CD или разворачивая бэкап SQL на другом сервере. Вместе с данными копируются и все служебные идентификаторы. Когда система пытается установить связь через прямое подключение (COM), она обнаруживает, что удаленная база имеет точно такой же уникальный код, как и текущая, либо этот код уже занят существующей настройкой обмена. Система воспринимает это как попытку синхронизации базы «самой с собой» и блокирует процесс.

Способ 1: Изменение кода предопределенного узла через интерфейс

Рассмотрим самый простой и рекомендуемый способ, который появился в последних версиях БСП. Если база данных была скопирована, нам необходимо принудительно заставить программу сгенерировать новый код для «этого узла» плана обмена.

Откроем информационную базу, в которой возникает ошибка (как правило, это копия).
Перейдем в раздел Администрирование — Синхронизация данных.
Откроем список Настройки синхронизации данных.
В верхней командной панели нажмем кнопку Еще.
Найдем пункт Установить новый код предопределенного узла.

Важно: После выполнения этой команды система сгенерирует новый GUID для текущей базы. Это должно решить проблему конфликта идентификаторов при создании новой настройки обмена.

Способ 2: Корректировка префикса в планах обмена (ручной метод)

Иногда кнопка в меню Еще может отсутствовать или быть неактивной. В этом случае мы можем изменить код узла вручную через служебные инструменты. Посмотрим на этот процесс по шагам:

Включим Функции для специалиста (в главном меню программы в разделе «Настройки»).
Найдем раздел Планы обмена.
Выберем тот план обмена, по которому настраивается синхронизация (например, ОбменЗарплата3Бухгалтерия3 или СинхронизацияДанныхЧерезУниверсальныйФормат).
В открывшемся списке найдем запись, помеченную значком компьютера — это Этот узел.
Перейдем на закладку Служебные и найдем поле Код. Именно здесь хранится тот самый GUID (например, e41c9bb2...), на который ругается система.
Поменяем этот код на произвольный (главное — уникальный) или воспользуемся обработкой для генерации нового GUID.

Способ 3: Очистка регистров сведений через «Групповое изменение реквизитов»

Проанализируем ситуацию, когда стандартная смена кода в плане обмена не помогает. Информация о префиксах и связях баз дублируется в нескольких служебных регистрах. Если там остались «хвосты» от старых попыток настройки, их нужно вычистить. Для этого можно воспользоваться штатной обработкой `Групповое изменение реквизитов` или более гибкими инструментами, такими как обработка «Корректор» и универсальные обработки для работы с регистрами сведений.

Нам необходимо проверить и, при необходимости, изменить данные в следующих объектах:

Регистр сведений: ОбщиеНастройкиУзловИнформационныхБаз. Здесь хранится соответствие узлов и их префиксов.
Регистр сведений: НастройкиТранспортаОбменаДанными. Проверьте, нет ли там записей с конфликтующим идентификатором.
Константа: ИдентификаторИнформационнойБазы.

Рассмотрим пример программного кода, который можно запустить во внешней обработке или через консоль кода, чтобы полностью «обнулить» идентификатор базы, заставив систему считать её уникальной:


// Программный сброс идентификатора информационной базы
Процедура ОбновитьИдентификаторБазы()
    НовыйИД = Новый УникальныйИдентификатор();
    Константы.ИдентификаторИнформационнойБазы.Установить(НовыйИД);
    Сообщить("Установлен новый уникальный идентификатор базы: " + Строка(НовыйИД));
    
    // Также необходимо обновить коды в планах обмена
    // Для каждого плана обмена из метаданных выполняем обновление
    Для Каждого ПланОбмена Из Метаданные.ПланыОбмена Цикл
        УзелОбъекта = ПланыОбмена[ПланОбмена.Имя].ЭтотУзел().ПолучитьОбъект();
        Если УзелОбъекта <> Неопределено Тогда
            УзелОбъекта.Код = Строка(НовыйИД);
            УзелОбъекта.Записать();
        КонецЕсли;
    КонецЦикла;
КонецПроцедуры

Важные последствия и риски

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

Сбитая нумерация документов: Если вы меняете не только GUID, но и буквенный префикс (например, в настройках синхронизации изменили «УТ» на «ТОРГ»), маска номера новых документов изменится. Система начнет нумерацию заново (например, ТОРГ-000001), что может вызвать вопросы у бухгалтерии.
Дублирование данных: Если между базами ранее уже был настроен обмен, и вы решили изменить идентификатор базы «на ходу», синхронизация может перестать «узнавать» объекты. Контрагенты и номенклатура, пришедшие из этой базы ранее, могут создаться повторно, так как связь по уникальному идентификатору будет разорвана. Для устранения таких последствий потребуется поиск и удаление дублей.
Разрыв существующих обменов: Если база обменивается данными сразу с несколькими программами (например, БП обменивается с УТ и ЗУП одновременно), смена глобального идентификатора в БП приведет к тому, что все настроенные обмены перестанут работать. Их придется перенастраивать с нуля во всех связанных базах. Отслеживать их состояние после перенастройки поможет мониторинг синхронизаций данных.