Как перенести отдельный реквизит в правилах Конвертации данных 2.1, не изменяя существующие данные?

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

Давайте разберем, как грамотно решить эту задачу, сохранив работоспособность текущих правил и целостность данных в базе-приемнике.

Способ 1: Создание дополнительного правила конвертации (ПКО)

Этот метод является наиболее «чистым» с точки зрения архитектуры Конвертации данных 2.1. Мы создаем специализированное правило, которое отвечает исключительно за передачу требуемого реквизита.

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

Таким образом, основной обмен останется нетронутым, а для разового обновления вы сможете запустить выгрузку по этому узкоспециализированному правилу.

Способ 2: Использование алгоритмов в обработчиках «После загрузки»

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

В этом сценарии система находит объект, а мы принудительно обновляем конкретный реквизит, даже если для остальных полей установлено правило «Не замещать».

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

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

Способ 3: Настройка поиска и «шаманство» с полями поиска

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

Рассмотрим рекомендации:

• Проверка уникальности: Если у вас настроен поиск по наименованию, и в приемнике оно было изменено пользователем, поиск может не сработать или сработать неверно. По возможности, всегда используйте уникальные идентификаторы, такие как GUID или Код, если они синхронизированы между базами.
• Минимизация полей поиска: Если данных для поиска много (например, ИНН + КПП + Наименование), попробуйте оставить только наиболее надежные комбинации.
• Вмешательство через алгоритмы: Если поиск по стандартным полям не дает нужного результата, используйте обработчик ПоляПоиска. В нем вы можете программно задать алгоритм поиска, используя запросы к базе данных для более точного сопоставления объектов.

Практические советы по реализации

Работая с Конвертацией данных, помните о следующих правилах:

1. Тестирование: Всегда проводите перенос на копии базы. Проверьте, не «затерлись» ли измененные вручную наименования после того, как вы применили новое правило.
2. Разовость: Если задача — обновить реквизит один раз для всех старых записей, не всегда целесообразно вносить изменения в основные правила, которые используются в ежедневных обменах. В таких случаях оправдано использование внешних обработок (например, на основе XML-файла, выгруженного через Конвертацию данных) или разового выполнения кода в консоли запросов/обработке.
3. Отказ от лишних обновлений: Если вы все же меняете существующие правила, внимательно следите за тем, какие поля включены в ПКС. Если реквизит не указан в ПКС, система не будет его менять при загрузке, что и является лучшим способом защиты данных от изменений.

Анализируя текущую ситуацию, мы видим, что наиболее эффективным и безопасным способом для системного администратора или программиста будет выделение задачи обновления в отдельное правило с четко настроенными полями поиска. Это позволит избежать влияния на основную логику обмена и обеспечит предсказуемый результат при обновлении данных.