Разберем классическую и весьма неочевидную проблему, с которой часто сталкиваются разработчики при переносе данных через «1С:Конвертация данных 2.1». Проанализируем ситуацию: стоит задача перенести справочник контрагентов из одной базы в другую (например, из Бухгалтерии 3.0 в Бухгалтерию 2.0). В Правилах Конвертации Объектов (ПКО) настроены поля поиска: ИНН, КПП и Наименование. В настройках явно установлен флаг Не замещать существующие объекты. Однако после запуска обмена мы видим странную картину — некоторые контрагенты всё равно обновляются, затирая существующие данные в базе-приемнике. При этом отладка показывает, что переменная ОбъектНайден возвращает значение ложь.
Выясним причину такого поведения и рассмотрим по шагам все возможные способы решения этой нестандартной задачи.
Первое, на что необходимо обратить внимание — это настройки поиска в ПКО. По умолчанию система пытается найти объект по его внутреннему идентификатору (GUID). Если установлен флаг Искать объект приемника по внутреннему идентификатору, алгоритм работает следующим образом:
ОбъектНайден получает значение ложь.Именно здесь кроется особенность (или программная ошибка) платформы КД 2.1. Если объект не был найден по GUID, но затем нашелся по полям поиска, флаг запрета на замещение может быть проигнорирован. Система считает, что раз по GUID соответствия нет, значит объект "новый", и перезаписывает его найденную по реквизитам копию.
Как решить проблему: Откроем настройки ПКО для справочника контрагентов и полностью снимем флажок Искать объект приемника по внутреннему идентификатору. В этом случае поиск сразу начнется по полям, переменная ОбъектНайден корректно примет значение истина, и базовый запрет на замещение сработает так, как мы ожидаем.
Рассмотрим еще одну частую причину, которая ломает логику замещения. В Конвертации данных существует известный баг, связанный с обработчиками событий. Если для ПКО когда-либо открывался и редактировался обработчик Поля поиска, это может нарушить работу стандартных флагов.
Даже если вы закомментировали весь код внутри обработчика или оставили там всего один невидимый символ (пробел, перенос строки или табуляцию), платформа считает, что логика поиска переопределена программно. В результате настройка "Не замещать существующие объекты в приемнике" полностью игнорируется.
Как решить проблему: Проверим код обработчика Поля поиска. Если вы не используете сложную программную логику сопоставления объектов, полностью очистим текстовое поле обработчика от всех символов, включая пробелы и пустые строки.
Проанализируем ситуацию, когда контрагенты выгружаются не отдельным правилом, а подтягиваются вместе с документами (например, как реквизит документа реализации). В этом случае общая настройка ПКО для справочника может не сработать, так как объект выгружается по ссылке в рамках Правил Конвертации Свойств (ПКС) документа.
Как решить проблему: Перейдем в ПКО документа, который тянет за собой контрагента. Найдем соответствующее свойство (реквизит документа) в ПКС и установим для него специальный флажок: Не замещать значение свойства у существующих объектов в приемнике. Это гарантирует, что при обновлении документа система не перезапишет реквизиты связанного контрагента.
Если визуальные настройки по каким-то причинам не решают задачу в вашей сложной архитектуре, мы можем взять процесс под полный программный контроль. Посмотрим на пример кода, который необходимо прописать в обработчике При загрузке для ПКО базы-приемника.
Если ОбъектНайден Тогда
НеЗамещатьОбъект = Истина;
Иначе
Сообщить("Контрагент не найден, создаем нового: " + Объект.Наименование);
КонецЕсли;
Здесь важно помнить о нюансе из первого пункта: переменная ОбъектНайден будет иметь значение истина только в том случае, если мы отключили поиск по GUID или если объект реально нашелся по внутреннему идентификатору. Если вы не отключите поиск по GUID, эта переменная вернет ложь, и программный запрет НеЗамещатьОбъект = Истина просто не выполнится.
Подводя итоги, выполним следующий чек-лист для надежного переноса данных без перезаписи существующих элементов:
Используя эти методы, мы сможем добиться стабильного и предсказуемого обмена данными, избежав случайного повреждения справочной информации в базе-приемнике.