При работе с обменом данными в 1С, используя инструмент Конвертация Данных 2.1 (КД 2.1), мы часто сталкиваемся с вопросом: как система определяет, нужно ли создавать новый документ в базе-приемнике или обновить уже существующий? Это очень важный аспект, который напрямую влияет на корректность и целостность данных. Давайте вместе разберем эту ситуацию и выясним, как настроить КД 2.1 для желаемого поведения.
На первый взгляд, задача может показаться сложной, особенно если мы только начинаем осваивать КД 2.1. Однако, как показывает практика, основная причина непонимания часто кроется в панике и невнимательности к базовым настройкам. Если соответствия документа для преобразования не будут найдены по заданным параметрам, система, естественно, создаст новый документ. Наша задача — научиться управлять этим процессом.
В основе логики принятия решения о создании или поиске объекта лежат Правила Конвертации Объектов (ПКО). Мы рассмотрим их подробнее. Каждое ПКО определяет, как конкретный объект-источник (например, документ "Реализация товаров и услуг") должен быть преобразован в объект-приемник (например, тот же документ в другой конфигурации или базе).
Именно в настройках ПКО мы указываем, каким образом система должна искать существующий объект в базе-приемнике, прежде чем принять решение о создании нового. Если поиск не даст результата, будет создан новый объект. Это настраивается на закладке Настройки в ПКО.
Давайте разберем по шагам, как настроить поиск, чтобы избежать дублирования или, наоборот, обеспечить создание новых документов, когда это необходимо.
Внутри каждого ПКО мы создаем Правила Конвертации Свойств (ПКС), которые описывают соответствие реквизитов между объектом-источником и объектом-приемником. Для каждого такого свойства (реквизита) мы можем установить специальный флажок "Поиск". Если этот флажок установлен для одного или нескольких свойств, алгоритм КД 2.1 перед загрузкой будет искать объект в базе-приемнике по значениям этих реквизитов.
Одним из наиболее надежных способов поиска объекта для модификации является использование внутреннего (уникального) идентификатора объекта. Этот идентификатор невидим для пользователя и гарантированно уникален в пределах одной базы. Если мы настраиваем поиск по УИД, система будет пытаться найти объект с таким же идентификатором в базе-приемнике. Если он найден, объект будет обновлен; если нет — создан новый.
При переносе данных по УИД, если объект не найден, будет перенесена только ссылка на объект (без полей поиска — просто ссылка). Это может быть полезно в специфических сценариях.
В настройках ПКО существует также флаг "Не создавать новый объект в приемнике, если он НЕ найден". Этот флаг призван контролировать создание новых объектов. Если он установлен и объект не был найден (ни по УИД, ни по другим полям поиска), то новый объект создан не будет. Это может быть полезно, когда мы хотим переносить только те объекты, для которых уже есть соответствие в приемнике.
Однако, проанализируем ситуацию: на практике этот флаг может не всегда срабатывать штатно, особенно при специфических переносах (например, между 1С 8.х и 1С 7.7). В таких случаях может потребоваться доработка кода в макете "ПроцедурыИФункцииМодуляЗагрузки" для его корректной работы.
Для более гибкого управления процессом конвертации мы можем использовать обработчики событий, доступные в ПКО и ПКС. Они позволяют нам вмешиваться в логику обмена на различных этапах.
Один из мощных обработчиков — это "Поля поиска" в ПКО. Он позволяет нам динамически определять, по каким полям будет производиться поиск объекта в приемнике, в зависимости от данных источника. Это особенно полезно для сложных сценариев, когда правила поиска могут меняться.
Например, мы можем задать поиск контрагента по ИНН и КПП, но если это договор с комиссионером, добавить дополнительный поиск по наименованию. Для того чтобы поля были доступны в этом обработчике, они должны быть предварительно отмечены флагом "Поиск" в соответствующих ПКС.
Посмотрим на пример, как это может выглядеть в коде:
// Пример кода для обработчика "ПоляПоиска" в ПКО
// Здесь мы можем динамически добавлять или изменять поля поиска
// в зависимости от условий.
Если Источник.ВидДоговора = Перечисления.ВидыДоговоров.СКомиссионером Тогда
// Для договоров с комиссионером добавляем поиск по Наименованию
ПоляПоиска.Добавить("Наименование");
КонецЕсли;
// По умолчанию уже добавлены поля, помеченные флагом "Поиск" в ПКС.
// Мы можем также удалять поля из списка ПоляПоиска, если это необходимо.
Для передачи данных и управляющих флагов между различными этапами конвертации (ПВД, ПКО, ПКС) мы используем специальные переменные. Обратите внимание на следующие:
Параметры: Общий набор параметров для всего обмена.ИсходящиеДанные: Данные, которые выгружаются из источника.ВходящиеДанные: Данные, которые загружаются в приемник.ПараметрыОбъекта: Используются для передачи параметров из источника в приемник для конкретного объекта.Эти параметры позволяют нам создавать очень гибкие и адаптивные правила обмена.
Еще один важный момент, который мы должны проанализировать, — это код, который выполняется при создании объекта. Например, поле Код документа или элемента справочника. Оно может переноситься из исходной базы или же создаваться новое в базе-приемнике. Это поведение также определяется в ПКС, и при необходимости можно использовать обработчики для управления генерацией кода или его переносом.
Мы видим, что КД 2.1 — это мощный, но иногда трудозатратный инструмент. Некоторые разработчики, сталкиваясь с большими объемами данных или сложной логикой, предпочитают использовать альтернативные методы для обмена, например, через JSON. Это может быть более гибким решением для специфических задач, но требует написания кода "с нуля".
Также существуют методики переноса остатков, где ПКО для документа может создаваться "из пустоты" (с пустым объектом-источником). Это позволяет сформировать документ-приемник на основе данных, собранных в процессе конвертации из различных источников или вычисленных значений.
Помните, что при доработке конфигураций или обновлении на более актуальный релиз, актуализация правил обмена может потребоваться. Это непрерывный процесс поддержки.
Для глубокого освоения КД 2.1 и уверенной работы с ней мы рекомендуем:
Мы надеемся, что этот подробный разбор поможет вам лучше понять, как КД 2.1 принимает решение о создании нового документа или обновлении существующего, и позволит вам уверенно настраивать правила обмена данными.
← К списку