Опыт доработки типовой синхронизации EnterpriseData на конвертации данных 3 без конфигурации 1С:КД3

Используемые сокращения:

КД – конвертация данных (например, КД 3)

ИБ – информационная база

УИД – уникальный идентификатор (либо GUID)

ПОД – правила обработки данных

ПКО – правила конвертации данных

ВИ – вариант идентификации

МД – метаданные

ТЧ – табличная часть

Сокращения наименований типовых конфигураций:

1С:ERP Управление предприятием 2 – ERP

1С:Зарплата и управление персоналом КОРП, редакция 3.1 – ЗУП

В рамках проекта необходимо было доработать типовой механизм синхронизации между типовыми конфигурациями ЗУП и ERP. Обмен реализован с использованием механизма конвертации данных 3. При анализе информации о работе с КД3 было выявлено, что в основном описана работа с обменами с использованием конфигурации 1С:Конвертация данных 3, при этом сам механизм позволяет дорабатывать обмены без её использования.

В статье рассматривается подход к доработке типовой синхронизации EnterpriseData на механизме конвертации данных 3, без использования конфигурации 1С:Конвертация данных 3. Приведены краткие сведения о механизме КД 3 – последовательность событий при выгрузке/загрузке, используемые объекты конфигурации. Также приведены примеры доработки синхронизации на КД 3 на примере задач для заказчика.

Описание используемых объектов конфигурации при синхронизации

Из используемых объектов конфигурации механизмами КД 3, выделю следующие: План обмена СинхронизацияДанныхЧерезУниверсальныйФормат, XDTO-пакеты EnterpriseData, а также общие модули – МенеджерОбменаЧерезУниверсальныйФормат, ОбменДаннымиXDTOСервер.

В плане обмена описан состав выгружаемых объектов, а также в модуле менеджера варианты различных настроек синхронизации с типовыми конфигурациями, т.е. один план обмена может быть использован для синхронизации с несколькими типовыми конфигурациями, например, настройка между ERP и ЗУП «ОбменУП2ЗУП3».

В общем модуле ОбменДаннымиXDTOСервер описываются алгоритмы выгрузки и загрузки.

В общем модуле МенеджерОбменаЧерезУниверсальныйФормат описываются правила конвертации, в нём выполняются основные доработки правил конвертации.

Подробно про XDTO пакеты можно прочитать в серии статей [1, 2]. Здесь же, кратко – в XDTO пакетах EnterpriseData описано по какой структуре будет сформирован xml файл, с его помощью записываются и считываются данные из xml файла. Пакеты XDTO EnterpriseData одной версии одинаковы по составу.

Чтобы узнать фактически используемую версию формата EnterpriseData, есть несколько вариантов:

• Если обмен настроен, то в xml файле сообщения между ИБ (файлы message) указана версия формата, в данном примере 1.15:

• Отладчиком в процедурах синхронизации найти информацию в КомпонентыОбмена:

• Версию можно узнать из настройки синхронизации в пользовательском режиме – используя, например, консоль запросов, либо любую другую обработку, чтобы узнать значение реквизита ВерсияФорматаОбмена.

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

Описание механизма конвертации данных 3 (алгоритмы выгрузки-загрузки)

Перед описанием алгоритмов, приведено описание состава правил конвертации. Для описания правил конвертации используются: Правила обработки данных (ПОД), Правила конвертации объектов (ПКО), Правила конвертации предопределенных данных (ПКПД).

ПОД. Если сравнивать с КД 2, то в КД 3 нет Правил выгрузки данных (ПВД). ПОД используется для описания и выгрузки, и загрузки. Содержит информацию: для выгрузки ОбъектВыборкиМетаданные – объект метаданных, который выгружается, для загрузки – ОбъектВыборкиФормат – объект XDTO, который будет преобразовываться при получении. Также, отмечу, ИспользуемыеПКО – массив ПКО, которые могут быть использованы для конвертации указанного объекта. Т.е. для одного объекта может быть определено несколько ПКО.

У ПОД есть событие (не обязательное) – ПриОбработке. В нём можно установить какие ПКО из ИспользуемыеПКО будут использоваться и при каких условиях (например, в зависимости от минимальной версии пакета XDTO).

ПКО. В ПКО описано, как преобразовывать реквизиты объекта МД в объект формата при выгрузке (и наоборот при загрузке). Описаны ПСК и ПКТЧ (правила конвертации свойств и табличных частей). Возможные события: для выгрузки ПриОтправкеДанных, для загрузки – ПриКонвертацииДанныхXDTO, ПередЗаписьюПолученныхДанных, АлгоритмПоиска.

При записи также в ПКО описывается вариант идентификации – «ПоУникальномуИдентификатору», «СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска», «ПоПолямПоиска».

АлгоритмПоиска – позволяет описать произвольный алгоритм поиска объекта. Если точно известно, что стандартные варианты идентификации не подходят, либо нужно дополнить эти механизмы – можно описать и выполнить запрос, по результату которого получить ссылку на объект. Выполняется после стандартных вариантов идентификации (далее: ВИ), при этом должен быть указан один из ВИ с использованием полей поиска.

ПриОтправкеДанных, ПриКонвертацииДанныхXDTO – необходимы для описания определенных механизмов конвертации свойств, когда свойство не переносится «1 в 1», а также позволяет использовать структуру AdditionalInfo – в ней можно передавать свойства, которых нет у объекта формата.

ПередЗаписьюПолученныхДанных – ДанныеXDTO уже преобразованы в ПолученныеДанные, но в систему ещё не записан. Можно дополнить значения объекта (аналог события ПКО ПослеЗагрузки в КД 2).

В ПКПД описаны правила конвертации предопределенных значений справочников и перечислений.

Далее описаны алгоритмы выгрузки/загрузки. Здесь не рассматривается подробный алгоритм – только ключевые моменты, связанные с последовательностью выполнения ранее описанных событий конвертации. Подробно алгоритм можно рассмотреть в ОбменДаннымиXDTOСервер. Ниже представлены блок-схемы для визуального представления описанных алгоритмов.

Алгоритм выгрузки данных

Примем, что объекты к выгрузке уже зарегистрированы.

Сначала инициализируются таблицы правил обмена, в т.ч. таблицы ПКО, ПОД (см. КомпонентыОбмена). Выгрузка объектов выборки (т.е. зарегистрированных объектов) происходит по циклу для каждого объекта.

Для текущего объекта выборки определяется ПОД, выполняется событие ПриОбработке, если оно задано. Далее по циклу определяются и выполняются ИспользуемыеПКО для данного ПОД.

Укрупненно – сначала формируется промежуточная структура ДанныеXDTO, из которой в дальнейшем формируется ОбъектXDTO. Собственно, дальнейшее описание – по сути формирование этой структуры.

Выполняется 1й этап конвертации. Для свойств, у которых в процедуре ДобавитьПКО установлено ИспользуетсяАлгоритмКонвертации = 0, значения конвертируются «1 в 1».

Далее выполняется обработчик ПриОтправкеДанных. Для свойств, у которых ИспользуетсяАлгоритмКонвертации = 1, их значения сложно передать «1 в 1», они будут конвертироваться на 2м этапе. Также, зачастую, здесь формируются данные для конвертации ТЧ. Можно передать некоторые свойства, которых нет в объекте формата, в структуру AdditionalInfo.

Соответственно, далее происходит конвертация на 2м этапе, описанных в ПриОтправкеДанных.

В результате формируется xml файл, в котором хранится информация о выгруженных данных.

Алгоритм загрузки данных

Вначале, аналогично, происходит формирование таблиц правил обмена. Производится чтение файла xml, формирование ОбъектаXDTO, формирование структуры ДанныеXDTO.

Выполняется поиск объекта в базе-приемнике. Поиск осуществляется в зависимости от настройки в ПКО ВариантИдентификаци.

Если в значении ВИ используется «ПоУникальномуИдентификатору», тогда сначала выполняется попытка поиска по GUID из регистра сведений ПубличныеИдентификаторыСинхронизируемыхОбъектов, если в значении ВИ есть «ПоУникальномуИдентификатору». Если объект найден, ссылка на него присваивается в ДанныеИБ. Если нет – ДанныеИБ = Неопределено.

Затем конвертация – также работает в 2 этапа. Независимо от того, какой ВИ и найден ли был объект по GUID. Конвертация производится из ДанныеXDTO в ПолученныеДанные.

При загрузке перед 2м этапом выполняется подготовка данных в событии ПриКонвертацииДанныхXDTO. Также в нём можно выполнить отказ от загрузки данных, пример описан ниже.

Далее если ДанныеИБ = Неопределено (т.е. либо объект по GUID не был найден, либо поиск только по полям поиска), то выполняется попытка поиска по полям поиска, если установлен такой ВИ. Аналогично, если объект найден, ссылка записывается в ДанныеИБ, если нет, присваивается Неопределено.

Независимо от результата идентификации по полям поиска выполняется событие АлгоритмПоиска (если такое событие описано в ПКО).

Если объект в результате поиска найден, то происходит преобразование ссылки в объект ДанныеИБ.

Затем выполняется событие ПередЗаписьюПолученныхДанных, в котором можно доопределить реквизиты объекта (аналог события ПКО ПослеЗагрузки в КД 2). В этом событии уже нет ДанныеXDTO – они конвертированы в ПолученныеДанные, также имеется ДанныеИБ со значением, полученным в результате поиска.

После чего формируется ДанныеДляЗаписиВИБ – либо на основании полученных данных, либо данных ИБ. И затем попытка записать объект в ИБ.

После выполняются процедуры постобработки, такие как отложенное проведение документов, если есть такая необходимость.

Примеры реализации доработок синхронизации EnterpriseData и лайфхаки

Использования Алгоритма поиска

Была поставлена задача настроить конвертацию нескольких платежных документов в документ заявка на расходование денежных средств. Основная часть обмена была типовой, но возникла сложность с поиском банковского счета контрагента на стороне ERP – по Уникальным идентификаторам элементы справочников не связаны, т.к. были созданы в обеих базах без использования синхронизации, а типовой поиск по полям поиска не подходил (НомерСчета + Владелец), поэтому был реализован Алгоритм поиска.

Для поиска в отдельном служебном регистре сведений введены данные об интересующих контрагентах. Для поиска банковского счета сначала осуществлен поиск контрагентов по регистру по ИНН+БИК (передаются при обмене). Далее, по найденному контрагенту + НомерСчета (передан обменом) уже определяем банковский счет.

В общем случае пример использования АлгоритмПоиска:

Синхронизация одного объекта в несколько

Поставлена задача на основании табличной части одного документа осуществить обмен в несколько документов заявка на расходование денежных средств. По требованиям заказчика был создан документ в ЗУП, в табличной части которого собираются данные по физлицам и суммам. На каждое физлицо необходимо осуществить формирование документа Заявка на расходование ДС в ERP. Задача обмена решена следующим образом: чтобы не создавать новое описание объекта XDTO в обеих системах, был использован наиболее подходящий объект пакета. Большая часть данных передана через AdditionalInfo, там же хранится подготовленная таблица значений, из которой формируется пакет документов в ЕРП.

Вся сложность в том, что приходится отказываться почти от всех стандартных обработок, т.к. в ПолученныеДанные может находиться только данные об одном объекте. Например, обработка массива либо таблицы значений через ПолученныеДанные типовыми алгоритмами не предусмотрено, и обмен завершается с ошибкой. По тем же причинам на стороне ERP объекты типовыми вариантами идентификации не определить. Поэтому вся обработка происходит обработчике, где у нас есть возможность описать преобразование свойств – ПриКонвертацииДанныхXDTO – поиск объектов в ИБ, создание документов либо получение найденных объектов, заполнение данных и запись объектов.

Отказ от загрузки данных

В КД2 есть настройка для ПКО – «Не создавать новый объект в приемнике, если он НЕ найден». В КД3 в модулях такой настройки для ПКО нет, поэтому для реализации такого механизма, можно в событии ПередЗаписьюПолученныхДанных сбросить ПолученныеДанные и ДанныеИБ – тогда значение ДанныеДляЗаписиВИБ будет тоже Неопределено. Пример варианта реализации:

Принудительное проведение документа

Свойство документа Проведен не всегда описывается в ПКО либо стоит задача, чтобы документ всегда конвертировался в приемник проведенным и без отложенного проведения. Для этого можно описать это свойство в ПолученныеДанные.

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

Заключение

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