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