Синхронизация данных между двумя информационными базами 1С — это сложный процесс, который задействует множество механизмов: от планов обмена до XDTO-пакетов. Одной из наиболее запутанных ошибок является уведомление о неуникальности кода при записи узла обмена. Проанализируем ситуацию, когда две абсолютно одинаковые серверные базы БП 3.0 (одна из которых является копией другой) отказываются синхронизироваться, выдавая ошибку в журнале регистрации.
Ошибка {ОбщийМодуль.ОбменДаннымиСервер.Модуль(8962)}: Ошибка при вызове метода контекста (Записать) УзелОбменаОбъект.Записать; по причине: Значение "..." поля "Код" не уникально указывает на то, что система пытается создать или обновить запись в Плане обмена, но код, который она пытается присвоить узлу, уже занят другим элементом в этой же таблице.
Важно понимать, что в сообщении об ошибке идентификатор типа fcb49c89-3a96-48e2-ba78-e3167e9a85fc — это не GUID справочника Номенклатуры или Контрагентов, а уникальный идентификатор самого Узла обмена. Рассмотрим причины, почему это происходит:
.dt файла, мы получаем полную копию всех настроек, включая предопределенный узел «Этот узел» и все ранее созданные настройки обмена.Часто пользователи сталкиваются с тем, что система постоянно предлагает сопоставить данные (например, номенклатуру), даже если база-приемник является точной копией источника. Выясним, почему механизм сопоставления активируется снова и снова.
Сопоставление — это процесс связывания объектов в двух базах. Если объекты были созданы в одной базе и перенесены в другую штатными средствами обмена, они уже имеют одинаковые внутренние GUID, и сопоставление происходит автоматически. Однако, если база была клонирована, а затем в источнике были созданы новые элементы до завершения первой успешной синхронизации, система может «растеряться».
Проанализируем ситуацию: в приемнике объекта еще нет, в источнике он появился. При обмене система видит новый объект и, если настройки обмена подразумевают поиск по полям (ИНН, Наименование), она будет пытаться найти похожие объекты. Если вы хотите, чтобы данные просто копировались по GUID без лишних вопросов, необходимо правильно завершить первичный сеанс синхронизации.
Для того чтобы избежать ошибок уникальности и бесконечных окон сопоставления, разберем по шагам правильную последовательность действий при создании синхронизации на основе копии базы:
Шаг 1. Подготовка базы-приемника.
После загрузки .dt в новую базу необходимо первым делом изменить её префикс. Это делается в разделе «Администрирование» — «Синхронизация данных». Также крайне рекомендуется использовать обработку для изменения идентификатора информационной базы (входит в состав БСП), чтобы система считала эту базу уникальной.
Шаг 2. Очистка старых настроек.
Если в исходной базе уже были настроены обмены (например, с ЗУП), в копии их стоит проверить или удалить, если они не планируются к использованию, чтобы избежать конфликтов в планах обмена.
Шаг 3. Создание новой синхронизации.
Рассмотрим важный нюанс: при первой настройке синхронизации (особенно если используется «Универсальный формат обмена» через файл), очень важно не добавлять новые данные в базу-источник, пока не пройдет первый полный цикл обмена. Система должна зафиксировать состояние узлов.
Шаг 4. Решение проблемы с кэшем.
Как показывает практика, даже при верных настройках ошибка уникальности может сохраняться из-за серверного кэша. 1С кэширует структуру планов обмена. Рассмотрим процедуру очистки кэша на сервере:
1C:Enterprise 8.3 Server Agent.snccntx в каталоге сервера приложений.Если ошибка неуникальности кода указывает на конкретный идентификатор, мы можем найти его программно, чтобы понять, какой именно узел обмена вызывает сбой. Рассмотрим пример кода для консоли запросов или обработки:
// Пример поиска ссылки по уникальному идентификатору в планах обмена
ИскомыйGUID = "fcb49c89-3a96-48e2-ba78-e3167e9a85fc";
СсылкаНаУзел = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.ПолучитьСсылку(Новый УникальныйИдентификатор(ИскомыйGUID));
Если Не СсылкаНаУзел.Пустая() Тогда
Сообщить("Найден проблемный узел: " + СсылкаНаУзел.Наименование + ", Код: " + СсылкаНаУзел.Код);
КонецЕсли;
Если поиск по конкретному плану обмена не дал результатов, проанализируем все доступные планы обмена в цикле:
ИскомыйGUID = "fcb49c89-3a96-48e2-ba78-e3167e9a85fc";
Для Каждого ПланОбмена Из Метаданные.ПланыОбмена Цикл
Ссылка = ПланыОбмена[ПланОбмена.Имя].ПолучитьСсылку(Новый УникальныйИдентификатор(ИскомыйGUID));
Попытка
Если Ссылка.Наименование <> "" Тогда // Проверка на существование объекта
Сообщить("Объект найден в плане обмена: " + ПланОбмена.Имя);
КонецЕсли;
Исключение
// Объект не найден в этом плане обмена
КонецПопытки;
КонецЦикла;
Если ваша задача — полная идентичность справочников и части документов в двух базах, работающих на одной платформе и конфигурации, проанализируем преимущество РИБ (Распределенных информационных баз).
В отличие от универсального формата (XDTO), РИБ работает на уровне платформы. При создании начального образа подчиненного узла система сама заботится об уникальности кодов узлов, префиксах и автоматическом сопоставлении всех существующих объектов по внутренним идентификаторам (Binary ID). В случае использования РИБ вам не придется вручную сопоставлять 40 тысяч позиций номенклатуры, так как они будут «родными» для обеих баз изначально.
Подведем итог. Ошибка неуникальности кода при записи узла обмена в 1С чаще всего является следствием «грязного» клонирования базы или некорректной последовательности инициализации обмена.
Основные рекомендации:
УзелОбменаОбъект.Соблюдение этих правил позволит настроить стабильный обмен данными и избавит от пугающих ошибок в журнале регистрации.