Почему дублируются элементы справочников при переносе данных через Конвертацию данных 2.1 и как настроить сопоставление?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

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

Причина 1. Поведение флагов поиска в ПКО по умолчанию

Проанализируем стандартную логику работы алгоритма поиска объектов в обработке «Универсальный обмен данными в формате XML». Когда объект выгружается из базы-источника, вместе с ним всегда передается его уникальный внутренний идентификатор (GUID).

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

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

Разберем по шагам, как исправить эту настройку в конфигурации «Конвертация данных 2.1»:

  1. Откроем нужное правило конвертации объектов (например, для справочника Контрагенты или Номенклатура).
  2. Перейдем на вкладку «Настройки» (или «Дополнительно»).
  3. Установим флаг «Продолжать поиск по полям поиска, если по идентификатору объект не найден».
  4. Если базы абсолютно независимы и GUID сопоставлять не требуется, можно также снять флаг «Искать объект по внутреннему идентификатору», оставив только поиск по реквизитам.
  5. При необходимости предотвратить создание новых элементов при отсутствии совпадений включим опцию «Не создавать новый объект, если не найден».

Причина 2. Иерархия и влияние родительских групп

Для иерархических справочников («Номенклатура», «Контрагенты») критически важно учитывать структуру папок. Если в правиле конвертации свойств для реквизита Родитель установлен флаг поиска, сопоставление будет происходить строго внутри аналогичной группы.

Если в базе-источнике товар лежит в папке «Материалы», а в базе-приемнике — в папке «Сырье» или в корне справочника, алгоритм сочтет эти элементы разными и создаст дубль. Чтобы выполнять сквозной поиск по всему справочнику без учета папок, снимем флаг поиска с реквизита Родитель в таблице ПКС.

Причина 3. Специфика реквизитов и пустые значения (ИНН и КПП)

Рассмотрим частую проблему поиска контрагентов по связке ИНН + КПП. У физических лиц и индивидуальных предпринимателей реквизит КПП отсутствует (является пустой строкой). При строгом поиске по двум полям сопоставление для ИП может отрабатывать некорректно.

Чтобы избежать подобных ошибок, воспользуемся обработчиком «Поля поиска» в ПКО. Напишем код, который динамически определяет состав ключевых полей в зависимости от того, заполнено ли поле КПП:


Если ПустаяСтрока(СвойстваПоиска["КПП"]) Тогда
    СтрокаИменСвойствПоиска = "ИНН, ЭтоГруппа";
Иначе
    СтрокаИменСвойствПоиска = "ИНН, КПП, ЭтоГруппа";
КонецЕсли;

Причина 4. Невидимые символы и программный поиск

При визуальном совпадении наименований поиск по строке может не сработать из-за наличия неразрывных пробелов (символ с кодом 160 вместо обычного кода 32), случайных двойных пробелов или различий в регистрах. Функция СокрЛП() не удаляет неразрывные пробелы.

Если требуется реализовать нечувствительный к пробелам поиск или сложное сопоставление, напишем собственный запрос в обработчике «Поля поиска» и передадим найденную ссылку в переменную СсылкаНаОбъект:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ 1
    |   Номенклатура.Ссылка КАК Ссылка
    |ИЗ
    |   Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |   ПОДОБНО(Номенклатура.Наименование, &Наименование)
    |   И Номенклатура.ЭтоГруппа = &ЭтоГруппа";

Запрос.УстановитьПараметр("Наименование", СвойстваПоиска["Наименование"]);
Запрос.УстановитьПараметр("ЭтоГруппа", СвойстваПоиска["ЭтоГруппа"]);

Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
    Выборка = Результат.Выбрать();
    Выборка.Следующий();
    СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;

Если переменная СсылкаНаОбъект заполнена в обработчике, типовой механизм сопоставления пропускается, и данные загружаются напрямую в найденный элемент.

Альтернативные способы объединения справочников

Если сопоставить все элементы «на лету» в процессе обмена затруднительно, рассмотрим вспомогательные методы:

  1. Загрузка с префиксом и последующее слияние дублей: загрузим все элементы как есть, а затем воспользуемся стандартной обработкой конфигурации «Поиск и удаление дублей» (раздел Администрирование — Обслуживание — Корректировка данных). Обработка позволяет гибко настроить критерии похожести (по маске, без учета КПП) и перепривязать ссылки в проведенных документах к главному элементу.
  2. Синхронизация через EnterpriseData: при использовании типового формата обмена EnterpriseData в интерфейсе БСП доступен встроенный мастер сопоставления данных, где перед записью объектов можно вручную связать ненайденные позиции.
← На главную