Рассмотрим ситуацию, с которой часто сталкиваются при переносе данных между различными конфигурациями 1С. Допустим, мы настроили односторонний перенос справочника контрагентов из одной базы в другую. Часть данных перенеслась корректно, а часть по каким-то причинам не прошла. Возникает закономерный вопрос: если забить оставшуюся информацию руками (точно скопировав все реквизиты и даже код), не возникнет ли проблем в будущем, когда планируется включить двустороннюю синхронизацию? Разберем этот вопрос подробно и проанализируем, как система 1С работает с идентификацией объектов при обмене.
Многие начинающие специалисты полагают, что если создать в двух базах элементы справочника с абсолютно одинаковыми наименованиями, ИНН и кодами, то для системы это будет один и тот же объект. Выясним причину, почему это не так.
Разберем понятия объектных и необъектных данных. Элемент справочника или документ — это объектные данные. Они идентифицируются платформой не по значениям атрибутов (таких как Код или Наименование), а по особому внутреннему полю, в котором хранится уникальный идентификатор элемента — GUID. Это поле называется Ссылка. Если мы создадим контрагента руками во второй базе, система присвоит ему абсолютно новый, уникальный GUID, который гарантированно не совпадет с GUID объекта в базе-источнике.
По значениям атрибутов идентифицируются только записи регистров и строки табличных частей. Следовательно, при классическом обмене по внутренним идентификаторам система увидит два разных GUID и решит, что это два разных контрагента, создав в итоге полные дубли.
Посмотрим на ситуацию с другой стороны. Будут ли созданы дубли, зависит от того, как именно написаны правила обмена, например, в конфигурации «Конвертация данных» (КД). Проанализируем, какие механизмы поиска нам доступны.
В правилах обмена (ПКО — Правила конвертации объектов) можно указать не только поиск по внутреннему идентификатору (УИД), но и поля сопоставления. Для справочника «Контрагенты» золотым стандартом сопоставления выступают ИНН и КПП, а иногда Код или Наименование.
Если в правилах обмена включена настройка поиска по полям, то механизм работы будет следующим:
Если обмен идет через обработку «Универсальный обмен данными в формате XML», то в правилах почти всегда стоит галочка «Продолжить поиск по полям поиска, если по идентификатору объект не найден». В этом случае ручной ввод может спасти ситуацию, но вы должны быть на 100% уверены, что введете ИНН и КПП абсолютно идентично. Если же в правилах жестко задан только поиск по УИД, ручной ввод приведет к дублированию.
Разберем подробнее, как работает механизм сопоставления в современных конфигурациях (например, БП 3.0, УТ 11, ЗУП 3.1) при использовании типовой синхронизации (Enterprise Data). Здесь система использует не только правила конвертации, но и специальный служебный регистр сведений.
Когда объект переносится из базы А в базу Б в первый раз, система делает запись в регистр сведений СоответствияОбъектовИнформационныхБаз. Она записывает связку: «GUID в этой базе» = «GUID в другой базе».
Если вы введете контрагента вручную, этой записи в регистре, естественно, не появится. При следующей двусторонней синхронизации система может не «узнать» ваш ручной объект и пришлет данные из первой базы как новые, создав дубль. Чтобы этого избежать, при первом сеансе обмена после ручного ввода необходимо запустить «Помощник интерактивного сопоставления». Он покажет пользователю: в базе-источнике есть Контрагент А, а в базе-приемнике есть похожий Контрагент Б. Вы вручную подтверждаете их связь, и система сама сформирует нужную запись в регистре соответствий.
Если у вас есть навыки программирования, рассмотрим технический способ решения проблемы без риска дублей. Мы можем программно создать объект справочника во второй базе, принудительно задав ему такой же GUID, как в первой.
Для этого используется метод платформы УстановитьСсылкуНового. Разберем по шагам небольшой пример кода, который показывает принцип создания элемента с конкретным идентификатором:
// Получаем строковое представление GUID из базы-источника (переданное, например, текстом)
СтрокаУИД = "12345678-1234-1234-1234-1234567890ab";
// Формируем новый уникальный идентификатор
НовыйУИД = Новый УникальныйИдентификатор(СтрокаУИД);
// Получаем новую пустую ссылку с нужным УИД
НоваяСсылка = Справочники.Контрагенты.ПолучитьСсылку(НовыйУИД);
// Создаем новый элемент справочника
НовыйЭлемент = Справочники.Контрагенты.СоздатьЭлемент();
// Устанавливаем объекту заранее сформированную ссылку
НовыйЭлемент.УстановитьСсылкуНового(НоваяСсылка);
// Заполняем реквизиты
НовыйЭлемент.Наименование = "ООО Ромашка";
НовыйЭлемент.ИНН = "7700000000";
// Записываем объект
НовыйЭлемент.Записать();
В результате мы получаем в базе-приемнике «клона» объекта из базы-источника. На уровне системы их GUID идентичны, поэтому при любом обмене (даже без настройки поиска по полям) система безошибочно сопоставит эти объекты.
Предположим, вы забили данные руками, не учли правила поиска, и дубли все же появились. Разберем, как исправить ситуацию без потери данных.
В современных конфигурациях 1С присутствует штатный механизм исправления — обработка «Поиск и удаление дублей» (находится в разделе Администрирование — Обслуживание — Корректировка данных). Посмотрим на алгоритм действий:
Контрагенты.Резюмируем: Вместо того чтобы переносить недостающие объекты руками, всегда лучше зарегистрировать их для обмена в базе-источнике (через узел обмена) и позволить системе перенести их самой. Если ручной ввод неизбежен, убедитесь, что в правилах обмена корректно настроены поля поиска (ИНН, КПП), и используйте интерактивное сопоставление при первой синхронизации.