Как изменить способ синхронизации объектов с поиска по наименованию на поиск по внутреннему идентификатору (GUID)?

← На главную

При настройке обмена данными между конфигурациями 1С на базе «Конвертации данных 2.0» часто возникает ситуация, когда первоначальная синхронизация была настроена по простым полям (например, по Наименованию или Артикулу), но со временем появляется потребность перейти на более надежный способ — поиск по Уникальному Идентификатору (GUID). Основная сложность заключается в том, что если объекты в разных базах уже созданы, их внутренние идентификаторы (ссылки) почти наверняка не совпадают. Рассмотрим подробно, почему так происходит и какие существуют методы «бесшовного» перехода на новый тип синхронизации.

Почему простая установка галочки «Найти объект по идентификатору» не работает?

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

Извлекает из XML-файла значение атрибута Ref (это и есть GUID из базы-источника).
Пытается найти в текущей базе объект с точно таким же GUID.
Если объект не найден, система либо создает новый (с этим GUID), либо переходит к поиску по «полям поиска», если это настроено.

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

Метод 1. Использование механизма «Продолжить поиск по полям поиска»

Это самый правильный и «мягкий» способ с точки зрения методологии «Конвертации данных». Разберем его по шагам. В настройках ПКО (Правила Конвертации Объектов) необходимо не только поставить галочку «Искать объект по внутреннему идентификатору», но и активировать опцию «Продолжить поиск по полям поиска, если по идентификатору объект не найден».

Рассмотрим, как это сработает в вашем случае:

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

Чтобы при следующем обмене объект уже находился сразу по GUID, можно воспользоваться обработчиком «После загрузки» в ПКО, чтобы принудительно связать объекты, или просто довериться механизмам БСП, если они используются.

Метод 2. Типовой механизм «Поиск и удаление дублей»

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

В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем), таких как Бухгалтерия предприятия 3.0, есть замечательный инструмент в разделе «Администрирование — Обслуживание — Поиск и удаление дублей».

Проанализируем алгоритм действий:

Выберите справочник «Номенклатура».
Настройте правила поиска (например, по совпадению наименования).
Система выведет список пар-дублей.
Ваша задача — назначить «Оригиналом» тот элемент, который был загружен последним (у которого GUID совпадает с GUID из «Торговли»).
Нажмите «Удалить дубли».

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

Метод 3. Использование регистра «Соответствия объектов информационных баз»

Если вы используете типовой обмен через Планы обмена, то сопоставление объектов часто хранится не через GUID самого объекта, а в специальном регистре сведений СоответствияОбъектовИнформационныхБаз. Это позволяет связывать объекты, даже если у них разные внутренние идентификаторы.

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


МенеджерЗаписи = РегистрыСведений.СоответствияОбъектовИнформационныхБаз.СоздатьМенеджерЗаписи();
МенеджерЗаписи.УникальныйИдентификаторИсточника = GUID_Из_Торговли;
МенеджерЗаписи.СобственнаяСсылка = Ссылка_В_Бухгалтерии;
МенеджерЗаписи.УзелИнформационнойБазы = УзелОбмена;
МенеджерЗаписи.ТипИсточника = "СправочникСсылка.Номенклатура";
МенеджерЗаписи.ТипПриемника = "СправочникСсылка.Номенклатура";
МенеджерЗаписи.Записать();

Этот способ позволяет избежать изменения самих GUID в базе-приемнике, сохраняя при этом жесткую связь между объектами для последующих синхронизаций.

Метод 4. Программная установка GUID (для продвинутых пользователей)

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

Создаем новый объект (например, НовыйЭлемент = Справочники.Номенклатура.СоздатьЭлемент()).
Генерируем или получаем ссылку с нужным GUID: НужнаяСсылка = Справочники.Номенклатура.ПолучитьСсылка(Новый УникальныйИдентификатор(GUID_из_Торговли)).
Устанавливаем эту ссылку новому объекту: НовыйЭлемент.УстановитьСсылкуНового(НужнаяСсылка).
Заполняем реквизиты из старого элемента и записываем новый.
Заменяем ссылки по всей базе со старого элемента на новый с помощью НайтиПомеченныеНаУдаление и специализированных обработок поиска и замены значений.

Внимание: Работа с идентификаторами на уровне SQL (через правку таблицы _IDRRef) категорически не рекомендуется. Это гарантированно приведет к разрушению ссылочной целостности базы, так как идентификатор объекта используется во всех таблицах движений и документов. Используйте только средства платформы 1С.

Резюме и рекомендации

Подводя итог, можно сказать, что наиболее безопасным и быстрым способом решения проблемы является Метод 2 (Поиск и замена дублей). Он позволяет не трогать правила конвертации и не писать сложный код. Если же вы хотите автоматизировать этот процесс на будущее для всех новых объектов, обязательно настройте в КД 2.0 двухэтапный поиск: сначала по GUID, затем по полям поиска. Это обеспечит автоматическое «склеивание» объектов при первой же встрече в процессе обмена.