Почему «Конвертация данных 2.0» перезаписывает объекты, несмотря на установленные флаги «Не замещать»?

При настройке обменов в Конвертация данных 2.0 часто возникает ситуация, когда стандартные настройки не дают ожидаемого результата. Вы устанавливаете флаг «Не замещать существующие объекты в приемнике при загрузке», однако после выполнения обмена обнаруживаете, что наименования или другие реквизиты объектов в целевой базе все равно были изменены. Давайте разберемся, почему так происходит и как взять процесс под полный контроль.

Почему стандартные галочки не всегда срабатывают?

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

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

Решение 1: Использование обработчика «Перед загрузкой» или «При загрузке»

Одним из штатных способов управления процессом является использование программных флагов в обработчиках событий правил обмена. Вы можете программно отменить запись или замещение.

Разберем подробнее событие При загрузке. В этом обработчике доступны параметры ОбъектНайден и НеЗамещатьОбъект. Установив последний в значение Истина, вы даете системе команду пропустить обновление найденного элемента.

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

Решение 2: Принудительный отказ от изменений через «После загрузки»

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

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

// В обработчике "После загрузки"
Если ЗначениеЗаполнено(Объект.Ссылка) Тогда
    // Получаем текущую версию объекта из базы данных, игнорируя изменения в XML
    Объект = Объект.Ссылка.ПолучитьОбъект();
КонецЕсли;

Разберем, что происходит в этом случае:

• Вы получаете Объект через метод ПолучитьОбъект(), обращаясь к его текущей Ссылка.
• Механизм обмена, получив в переменную Объект уже существующий экземпляр, не будет применять к нему процедуры автоматического заполнения из XML.
• Поскольку вы не вызываете метод Объект.Записать() в этом обработчике, изменения в базе данных не произойдут, и объект останется в том виде, в котором он был до начала обмена.

Рекомендации по анализу проблемы

Прежде чем использовать «хаки», проанализируйте следующие моменты:

1. Проверка полей поиска: Убедитесь, что Наименование не является полем поиска. Если оно указано как поле поиска, то любое несовпадение данных в XML вызовет попытку корректировки объекта.
2. Проверка подписок на события: Проверьте, нет ли в модуле объекта (справочника или документа) кода в процедурах ПередЗаписью или ПриЗаписи, который принудительно переписывает наименование на основе других реквизитов.
3. Настройка ПКС: Если вам нужно обновлять только часть реквизитов, снимите галку «Передавать только при создании» для тех полей, которые должны быть «неприкосновенными», но при этом проверьте, чтобы правило не было настроено на постоянную синхронизацию.

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