Как устранить задваивание контрагентов при обмене данными через «1С:Конвертацию данных 2.0» при поиске по полям?

При настройке обмена данными между конфигурациями (например, из Управление торговлей 10 в Бухгалтерию предприятия 3.0) разработчики часто сталкиваются с необходимостью отключить поиск по уникальному идентификатору (GUID). Это происходит, когда базы велись независимо и одни и те же контрагенты имеют разные внутренние ссылки. Однако переход на поиск по полям (Код, ИИН/БИН, Наименование) часто приводит к неприятному эффекту: объекты начинают задваиваться. При этом один объект создается полностью заполненным, а второй — «пустышкой», где заполнены только поля поиска.

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

Причина возникновения дублей: механизм рекурсии и «объекты-заглушки»

Рассмотрим ситуацию, которая приводит к ошибке. Когда движок обмена читает файл выгрузки и встречает объект СправочникСсылка.Контрагенты, он начинает обрабатывать его свойства. Если среди свойств есть ссылки на этот же справочник (например, Головной контрагент) или на подчиненные объекты, ссылающиеся на владельца (Основной договор, где владелец — сам контрагент), возникает циклическая ссылка.

Проанализируем пошагово процесс загрузки такого объекта:

1. Система начинает загружать контрагента "Альфа".
2. Внутри объекта "Альфа" встречается свойство "Основной договор".
3. Система переходит к загрузке договора. У договора есть обязательное поле "Владелец".
4. В поле "Владелец" указана ссылка на контрагента "Альфа".
5. Поскольку основной объект "Альфа" еще не записан в базу (он в процессе обработки), система пытается найти его по полям поиска, чтобы подставить в договор.
6. Если поиск не находит объект, система создает «объект-заглушку». Это пустой элемент справочника, в котором заполнены только те поля, которые участвуют в поиске.
7. Договор записывается с этой ссылкой.
8. Система возвращается к загрузке основного объекта "Альфа". И здесь происходит критическая ошибка: механизм загрузки по какой-то причине не сопоставляет текущий загружаемый объект с той «заглушкой», которую он создал секунду назад для договора. В итоге создается второй — полноценный — объект.

Шаг 1. Настройка обработчика «Поля поиска»

Для корректной идентификации важно правильно описать логику поиска в ПКО. Часто состав полей поиска отличается для групп и элементов. Проанализируем пример кода, который необходимо разместить в обработчике ПоляПоиска у ПКО Контрагенты:

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

Важный момент: убедитесь, что все поля, перечисленные в строке имен свойств, имеют установленный флаг «Поиск» в таблице свойств ПКО. Если вы используете ИИН/БИН (или ИдентификационныйКодЛичности), проверьте его длину и тип данных в обеих базах (обычно это строка 12 символов). Любое несовпадение типов приведет к тому, что НайтиПоРеквизиту() не сработает.

Шаг 2. Порядок свойств в ПКО — ключ к успеху

Одной из самых частых причин задваивания является неправильный порядок следования свойств в правилах обмена. Система обрабатывает свойства сверху вниз в том порядке, в котором они указаны в ПКО.

Рассмотрим, как правильно расположить свойства:

1. Поля поиска (Код, ИИН, ЭтоГруппа, Наименование) должны быть в самом верху списка свойств.
2. Свойства-примитивы (Комментарий, Полное наименование и т.д.) — следом.
3. Свойства-ссылки (Головной контрагент, Основной договор, Менеджер) — в самом конце списка.

Почему это важно? Если Головной контрагент (ссылка) будет стоять выше Кода (поля поиска), то при попытке найти головного контрагента система создаст рекурсию, еще не зная идентификационных данных текущего объекта. Переместив ссылочные свойства вниз, мы гарантируем, что к моменту их обработки объект уже будет частично идентифицирован или даже записан.

Шаг 3. Устранение проблем с рекурсивными ссылками

Если перемещение свойств не помогло, проанализируем настройки ПКС (Правил конвертации свойств) для «проблемных» полей. Для свойства ГоловнойКонтрагент в ПКО Контрагенты попробуйте следующие настройки:

• Отключите флаг Поиск у этого свойства (оно не должно участвовать в идентификации, а должно просто заполняться).
• Убедитесь, что для этого свойства указано правильное ПКО (само на себя).
• В некоторых случаях помогает временное отключение выгрузки этого свойства, чтобы проверить, исчезнет ли дублирование. Если без него объекты не двоятся — значит, проблема именно в циклической ссылке.

Шаг 4. Использование атрибута Нпп (Номер По Порядку)

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

1. Проверьте, не используются ли разные ПКО для выгрузки одного и того же объекта в разных местах (например, в одном месте через ПКО "Контрагенты", а в другом через ПКО "Контрагенты_ТолькоПоиск"). Это ломает кэш нпп.
2. Убедитесь, что выгрузка идет стандартными средствами. При ручном формировании XML-узла Ссылка необходимо следить, чтобы атрибут нпп совпадал для всех упоминаний одного объекта.

Шаг 5. Гибридный метод поиска (GUID + Поля поиска)

Если обеспечить уникальность по полям поиска не удается или архитектура справочника слишком сложна, рассмотрим «гибридный» вариант. Это наиболее стабильное решение для баз с частично сопоставленными данными:

1. В ПКО оставьте включенным поиск по GUID (флаг "Искать объект приемника по внутреннему идентификатору").
2. Включите флаг "Продолжить поиск по полям поиска, если по идентификатору объект не найден".
3. Настройте поля поиска (Код, ИИН).

В этом сценарии старые объекты сопоставятся по полям поиска, и при записи в базе-приемнике в регистр СоответствияОбъектовИнформационныхБаз (для БСП) запишется связь GUID-ов. Новые же объекты будут создаваться один раз (по GUID), и механизм «заглушек» будет работать корректно, так как GUID гарантирует 100% сопоставление в рамках одной транзакции загрузки.

Заключение

Подведем итог. Чтобы победить задваивание без GUID, необходимо:

• Вынести Код, Наименование и ЭтоГруппа в самое начало списка свойств ПКО.
• Обеспечить идентичность состава полей в обработчике ПоляПоиска и в настройках свойств ПКС.
• Проверить циклы: если объект ссылается на самого себя, это свойство должно обрабатываться последним.
• Использовать актуальную версию обработки УниверсальныйОбменДаннымиXML, так как в старых версиях механизмы кэширования нпп могли работать нестабильно.