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