При объединении независимых информационных баз 1С или переносе нормативно-справочной информации часто возникает неприятная ситуация: в правилах обмена (КД 2.1) настроен поиск номенклатуры по наименованию или контрагентов по ИНН и КПП, однако при загрузке создаются дубликаты. Разберем детально, почему типовой механизм сопоставления пропускает заданные поля поиска и как правильно настроить правила конвертации объектов (ПКО).
Проанализируем стандартную логику работы алгоритма поиска объектов в обработке «Универсальный обмен данными в формате XML». Когда объект выгружается из базы-источника, вместе с ним всегда передается его уникальный внутренний идентификатор (GUID).
По умолчанию в правилах конвертации объекта включен поиск по внутреннему идентификатору. Если базы велись раздельно, GUID одинаковых по смыслу элементов заведомо различаются. При загрузке платформа сначала пытается найти объект по GUID:
Наименование или ИНН), они просто игнорируются, так как первый этап поиска по GUID завершился неудачей.Разберем по шагам, как исправить эту настройку в конфигурации «Конвертация данных 2.1»:
Контрагенты или Номенклатура).Для иерархических справочников («Номенклатура», «Контрагенты») критически важно учитывать структуру папок. Если в правиле конвертации свойств для реквизита Родитель установлен флаг поиска, сопоставление будет происходить строго внутри аналогичной группы.
Если в базе-источнике товар лежит в папке «Материалы», а в базе-приемнике — в папке «Сырье» или в корне справочника, алгоритм сочтет эти элементы разными и создаст дубль. Чтобы выполнять сквозной поиск по всему справочнику без учета папок, снимем флаг поиска с реквизита Родитель в таблице ПКС.
Рассмотрим частую проблему поиска контрагентов по связке ИНН + КПП. У физических лиц и индивидуальных предпринимателей реквизит КПП отсутствует (является пустой строкой). При строгом поиске по двум полям сопоставление для ИП может отрабатывать некорректно.
Чтобы избежать подобных ошибок, воспользуемся обработчиком «Поля поиска» в ПКО. Напишем код, который динамически определяет состав ключевых полей в зависимости от того, заполнено ли поле КПП:
Если ПустаяСтрока(СвойстваПоиска["КПП"]) Тогда
СтрокаИменСвойствПоиска = "ИНН, ЭтоГруппа";
Иначе
СтрокаИменСвойствПоиска = "ИНН, КПП, ЭтоГруппа";
КонецЕсли;
При визуальном совпадении наименований поиск по строке может не сработать из-за наличия неразрывных пробелов (символ с кодом 160 вместо обычного кода 32), случайных двойных пробелов или различий в регистрах. Функция СокрЛП() не удаляет неразрывные пробелы.
Если требуется реализовать нечувствительный к пробелам поиск или сложное сопоставление, напишем собственный запрос в обработчике «Поля поиска» и передадим найденную ссылку в переменную СсылкаНаОбъект:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| Номенклатура.Ссылка КАК Ссылка
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
|ГДЕ
| ПОДОБНО(Номенклатура.Наименование, &Наименование)
| И Номенклатура.ЭтоГруппа = &ЭтоГруппа";
Запрос.УстановитьПараметр("Наименование", СвойстваПоиска["Наименование"]);
Запрос.УстановитьПараметр("ЭтоГруппа", СвойстваПоиска["ЭтоГруппа"]);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
Выборка = Результат.Выбрать();
Выборка.Следующий();
СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;
Если переменная СсылкаНаОбъект заполнена в обработчике, типовой механизм сопоставления пропускается, и данные загружаются напрямую в найденный элемент.
Если сопоставить все элементы «на лету» в процессе обмена затруднительно, рассмотрим вспомогательные методы: