От экспертов «1С-Рарус»: 10 интересных случаев применения 1С:Конвертации данных редакций 2.1 и 3.0

Технология обменов данным между решениями 1С с использованием конфигураций «Конвертация данных» редакции 2 и 3 известна уже давно. Однако, скорее меньшая часть от общего числа специалистов владеют данной технологией, и даже у них порой возникают задачи конвертации, которые непросто решить.

Некоторыми из таких непростых ситуаций мы поделимся в рамках публикации. Будет рассмотрено по 5 любопытных случаев для каждой из редакций.

Статья не должна рассматриваться как курсы или учебное пособие по конвертации — она нацелена именно на то, чтобы рассказать читателям об интересном и, возможно, облегчить жизнь в будущем, если придется столкнуться с подобными задачами.

Интересные случаи с 1С:Конвертацией данных, редакции 2

Алгоритм работы Конвертации данных 2

Любой процесс обмена данными можно разделить на две части:

1. Выгрузка данных базы в файл.
2. Загрузка данных из файла в данные информационной базы (далее ИБ).

Решение «1С:Конвертация данных, ред. 2» (далее КД 2) осуществляет обмен через правила:

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

Рассмотрим практические случаи применения КД 2 с погружением в описанные выше объекты.

Случай #1: Фильтрация выгружаемых объектов Информационной базы

Задача

В справочнике Организации информационной базы 1С заведено 10 элементов. Необходимо сделать так, чтобы выгрузились лишь 2 из них. В качестве критерия отбора будет использоваться значение реквизита ИНН.

В качестве решения можно отсеять нужные объекты в Правиле Конвертации Объекта, либо ограничить выборку в Правиле Выгрузки Данных. Рассмотрим эти варианты.

Решение №1: через Правило Конвертации Объекта (ПКО)

Сначала немного теории.

В механизме Конвертации данных ред. 2 за то, как будет выгружен и загружен тот или иной объект отвечает Правило Конвертации Объекта. В нём описывается:

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

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

Логика выгрузки и загрузки данных по правилам КД 2 реализуется стандартной обработкой УниверсальныйОбменДаннымиXML, встроенной во все типовые конфигурации 1С. Скачать инструмент можно на портале ИТС.

Выгрузка любого объекта осуществляется методом ВыгрузитьПоПравилу(...), расположенного в модуле объекта обработки. На вход методу подается:

• либо сам выгружаемый объект;
• либо структура, которая должна быть того же формата, что и реквизиты, описанные в правиле.

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

Посмотрим, как устроен процесс выгрузки.

В ПКО обработчики делятся на две группы — выгрузка и загрузка.

Рис. 1

Примечание. По каждому обработчику, находясь на его странице, можно получить справку, нажав на соответствующую кнопку главной панели (рис. 2, 3):

Рис. 2

Рис. 3

Если заглянуть под капот обработки Универсальный обмен данных, отвечающую за выгрузку/загрузку по правилам конвертации, то каждому обработчику событий в её модуле задан свой абзац кода. Например, обработчик Перед выгрузкой (рис. 4):

Рис. 4

При вызове метода ВыгрузитьПоПравилу() в общем виде происходит следующее (рис. 5):

Рис. 5

Первым срабатывает обработчик Перед выгрузкой данных, в коде которого можно отказаться от выгрузки объекта, опираясь, например, на значения свойств объекта и/или настройки системы. Для этого нужно установить значение служебной переменной Отказ в «Истина», в этом случае выгрузка объекта будет прервана:

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

Результатом применения ПКО является XML описание/образ объекта с необходимым набором полей для обмена данных (рис. 6):

Рис. 6

Результат: в качестве решения нашей задачи — пишем код на внутреннем языке 1С в обработчике Перед выгрузкой, который будет устанавливать значение служебной переменной Отказ в значение «Истина», если ИНН организации не удовлетворяет условиям (рис. 7):

Отказ = НЕ (Источник.ИНН = "<ИНН_А>" ИЛИ Источник.ИНН = "<ИНН_Б>");

Рис. 7

Решение №2: через Правило Выгрузки Данных

В качестве второго варианта решения предлагаем использовать ограничение выборки в Правиле Выгрузки Данных (далее ПВД).

Снова немного теории.

Когда в запущенной в режиме предприятия обработке Универсальный обмен данных из XML загружены правила, то ниже можем наблюдать коллекцию объектов в виде дерева (рис. 8):

Рис. 8

Это и есть ПВД, которые в конфигурации КД 2 определяются на отдельной странице (рис. 9):

Рис.9

Эти правила являются отправной точкой процесса выгрузки и описывают:

• в каком порядке нужно выгружать объекты;
• как будет определен набор выгружаемых объектов — стандартной выборкой, либо нестандартной (программный код).

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

• «Стандартный» — метод будет вызван неявно и в него будут переданы выбранные запросом объекты.
• «Произвольный алгоритм» — метод необходимо вызвать явно в коде обработчика и передать необходимые объекты.

Результат: в итоге для решения задачи используем ПВД со способом выгрузки Произвольный алгоритм, и в обработчике Перед обработкой, описываем код, который выбирает и выгружает нужные нам элементы справочника Организации (рис. 10):

Рис. 10

Внутренности исполняющего обработчика ПВД Перед обработкой (рис. 11):

Рис. 11

Случай #2: Выгрузка данных с фильтрацией связанных данных

Задача

Давайте рассмотрим следующую ситуацию: в крупной компании учет зарплаты ведется в единой информационной базе на конфигурации «1С:Зарплата и управление персоналом». В определенный момент появилась необходимость выделения учета по некоторым юридическим лицам в отдельную базу. Для чего потребовалось написать правила конвертации данных между аналогичными по структурам конфигурациям, но с фильтрацией выгружаемых данных. В том числе с ограничением перегружаемых объектов конфигурации.

Решение

Так как у конфигурации источник и приёмник идентичны, то изначально правила конвертации можно сформировать автоматически. Для этого на этапе введения нового правила конвертации данных (рис. 12) необходимо выбрать пункт «Автоматически создать все правила обмена (прототип)». Часто этот процесс занимает длительное время. Однако в отличии от ручного создания за вас это сделает система.

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

Рис. 12

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

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

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

Сам список описываем через значения коллекции «Соответствие», где в качестве ключа выступает имя регистра, а в значении указывается имя поля (измерение/ресурс/реквизит), по которому осуществляется фильтрация. При этом, если поле имеет единое название в некоторых регистрах, то можно оставить его незаполненным и подставить его в дальнейшем автоматически (рис. 13):

Рис. 13

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

Рис. 14

В конце обработчика указываем вызов хранимого алгоритма, который будет использовать эти две коллекции (рис. 14).

Выполнить(Алгоритмы.<ИмяАлгоритма>);

Перейдем к создании алгоритма. Для этого в списке правил обмена переключимся на страницу «Алгоритмы/Запросы» и создадим новый алгоритм. Заполняем имя алгоритма в соответствии с указанным в обработчике выгрузки ранее (рис. 13). А в коде выполняем обход коллекции со списом регистров. По каждому из регистров выполняем выборку данных с фильтрацией по указанному полю, а также выполняем выгрузку по правилам с помощью метода ВыгрузитьПоПравилу:

Рис. 18

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

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

Для того, чтобы передать эту входящую структуру воспользуемся третьим параметром метода ВыгрузитьПоПравилу(...) в ранее написаном алгоритме.

Рис. 19

Таким образом, упрощенная схема выгрузки выглядит следующим образом (рис. 20):

Рис. 20

В результате выгрузки получим XML с указанными элементами справочника, а также всеми записями связанных регистров сведений.

Случай #3: Выгрузка структуры данных через параметры

Задача

В ИБ-источнике есть справочник сотрудников, в котором хранится информация о дате рождения, ИНН, дате приема, организации и дата увольнения в виде реквизитов. А вот в ИБ-приемника указанные данные размещаются аж в трех сущностях: в справочниках «Сотрудники» и «Физические лица», а также в регистре сведений о кадровой информации. Необходимо реализовать выгрузку одного объекта-источник в три объекта-приемника.

Решение

Бывает так, что для некоторых полей объекта-источника нет полей в объекте-приемнике, но их нужно использовать для создания связанного объекта. Либо же на основании данных источника формировать какие-то другие данные объекта-приёмника.

И для этой цели служат параметры свойств.

Рис. 21

Используем параметры для передачи полей, которых нет явно в объекте-получателе. В обработчике После загрузки ПКО напишем программный код, который будет использовать значения этих параметров для создания нужных элементов справочников и записей регистров кадровой информации на стороне приемника (рис. 22, 23, 24):

Рис. 22

Рис. 23

Рис. 24

Благодаря этому и получаем решение данной задачи: элемент справочника Сотрудники будет создаваться по ПКО, а элементы справочника ФизическиеЛица, а также записи регистра сведений будут инициализированы программно при загрузке сообщения обмена.

Случай #4: Особый способ поиска объекта на стороне базы-приёмника

Задача

Необходимо определить на стороне ИБ-источника пару ключ:значение, по которой на стороне ИБ-приёмника будет осуществлён поиск, если по идентификатору в ИБ-приёмнике объект не будет найден. В нашем случае часть элементов справочника Химико-Энергетические Характеристики (ХЭХ) на стороне ИБ-приёмника должны быть идентифицированы нестандартным способом.

Решение

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

Рис. 25

Рис. 26

На рисунке 25 сказано, что прежде всего поиск следует производить по уникальному идентификатору. И если таковой не найден, то по полям поиска. А на рисунке 26 мы видим, что этими полями поиска назначена пара ЭтоГруппа и Код.

Задача усложняется, если среди полей объекта нет подходящих нам, то есть его надо надо как-то получить более сложным образом. Для этого в ПКО создано отдельное независимое без явного источника свойство (поле), в зависимости от значение которого инициализируется именованный параметр «ИмяПредопределенного» (рис. 27):

Рис. 27

В обработчике Перед выгрузкой данного свойства (ПКС) мы пишем математику, согласно которой и будем определять значение параметра ИмяПредопределенного (рис. 28):

Рис. 28

В момент загрузки происходит поиск объекта приемника согласно настроек ПКО, где сработает обработчик Поля поиска.

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

Отвлечемся от нашего случая и снова обратимся к стороннему примеру для демонстрации подхода. Приведем в пример ПКО справочника ФизическиеЛица, где полями поиска являются Наименование, Дата рождения, ИНН и СНИЛС (рис. 29, 30). В данном случае код поиска выполняется до 4 раз, если того требует логика поиска, например, показанная на рисунке 29:

Рис. 29

На первой итерации хотим искать по наименованию и дате рождения. Если по наименованию и дате рождения объект не найден, то далее хотим искать только по наименованию. Если и так не найден, то ищем по ИНН. Не найден по ИНН? Остаётся Страховой номер ПФР:

Рис 30

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

Рис. 31

Справка по обработчику:

Рис. 32

Случай #5: Создание объектов после общей загрузки

Задача

В ИБ-источнике у номенклатуры есть четыре основных единицы измерения (Весовая, Химико-энергетической характеристики, Тарная, Рецептурная), хранящиеся в соответствующих реквизитах с типом справочник Классификатор единиц измерения (далее ЕИ). В приемнике это тоже реквизиты, но уже типа справочник Единицы измерения с подчиненностью владельцу (номенклатуре).

Особенность задачи заключается в том, что прежде, чем инициализировать у номенклатуры значениями соответствующие реквизиты, эти значения (ссылки на ЕИ, подчиненные номенклатуре) должны быть предварительно созданы, а уже после назначены реквизитам владельца с записью изменений. Если бы не требовалось указывать единицы измерения в реквизитах владельца, то это был бы стандартный случай без дополнительных телодвижений.

Необычно, но решаемо.

Решение

Так как ЕИ в Номенклатуре-источнике — это классификатор, а в приемнике это ЕИ с подчинением номенклатуре, логично будет сделать для его переноса специфическое ПКО, в котором кроме стандартных полей, будет именованный строковый параметр, в котором через разделитель «;» будет описано отношение данной ЕИ к тому или иному реквизиту номенклатуры-получателя (рис. 33):

Рис. 33

Например:

Грамм: ИспользуетсяКак = “Вес;ХЭХ;Рецептурная”
Штука:> ИспользуетсяКак = “Тарная”

То есть ЕИ при переносе будет хранить информацию о том, в каком реквизите владельца она должна быть указана.

Приведём абзац кода обработчика Перед выгрузкой, формирующий значение параметра (рис. 34):

Рис. 34

Обратите внимание на то, что свойство (поле) Владелец, как и некоторые другие, получено из входящих данных при вызове данного ПКО из обработчика После выгрузки в файл ПКО Номенклатура (рис. 35). Входящие данные передаются, в том числе, правилам конвертации свойств (ПКС):

Рис 35

Так данные выгрузятся со всей необходимой для корректной загрузки информацией.

Теперь слово о загрузке. Как уже было сказано ранее, значения реквизитов номенклатуры могут быть указаны и записаны только после того, как будет создана сама номенклатура и все необходимые значения реквизитов (ЕИ, подчиненные номенклатуре).

То есть здесь имеем дело с постобработкой.

Для этого в глобальном обработчике Перед загрузкой данных правила КД программно создается глобальный параметр (рис. 36), который после каждой отработки специфического ПКО будет накапливать соответствие соответствий (рис. 37) следующего вида:

“Номенклатура А”
	> 	(Грамм > “Вес;ХЭХ;Рецептурная”
		 Штука > “Тарная”)
“Номенклатура Б”
	> 	(Грамм > “Вес;ХЭХ;Рецептурная”
		 Литр. > “Тарная”)
	….

И так далее.

Рис. 36

Рис. 37

Теперь, когда загружена номенклатура, подчиненные ей единицы измерений, а так же сформирована служебная структура для постобработки, можно приступить к инициализации реквизитов номенклатуры. Это будет сделано в глобальном обработчике После загрузки данных правила КД, через вызов алгоритма, в котором реализована логика постобработки (рис. 38, 39):

Рис. 38

Рис. 39

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

Устанавливаются значения реквизитов у объекта номенклатуры, а в конце производится запись изменений в ИБ.

Задача решена, ура!

Интересные случаи с 1С:Конвертацией данных, редакции 3

Алгоритм работы Конвертации данных 3

Прежде чем приступить к разбору случаев в Конвертации данных, редакции 3 (далее — КД 3), следует погрузиться в схему последовательности выполнения алгоритмов конвертации, поскольку далее они будут упомянуты в описываемых случаях.

Сокращения на схеме и далее:

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

ПКО — правило конвертации объектов.

ПКС — правило конвертации свойств.

Объект XDTO — объект, описанный в пакете XDTO (для обмена в формате EnterpriseData (КД 3) объекты описаны в пакетах «EnterpriseData_х_х_х»), предназначенный для передачи данных объекта конфигурации со схожей структурой.

Рис. 40

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

1. На шаге «1» выполняется инициализация структуры «КомпонентыОбмена», которая содержит в себе как правила обработки, конвертации, так и все необходимые параметры, задействованные в сеансе обмена. Параметры записываются в свойство «ПараметрыКонвертации» с типом «Структура».

2. На втором шаге выполняется алгоритм «ПередКонвертацией», определенный в модуле менеджера обмена:

   

   Рис. 41

   В конфигурации «Конвертация данных» его можно определить или изменить в справочнике «Конвертации» на вкладке «Глобальные обработчики конвертации»:

   

   Рис. 42

   В данном алгоритме происходит заполнение вышеупомянутой структуры «ПараметрыКонвертации» из шага 1.

3. На следующем шаге в случае выгрузки для зарегистрированных к отправке объектов происходит поиск соответствующего правила обработки данных (ПОД) и выполнение алгоритмов «При обработке» и «Выборка данных»:

   

   Рис. 43

   В случае загрузки для типа объекта XDTO определяется его правило обработки, и выполняется алгоритм «При обработке»:

   

   Рис. 44

4. Следом за алгоритмами ПОД происходит конвертация объекта информационной базы в объект формата XDTO, либо наоборот — в случае загрузки. Конвертация объекта выполняется в соответствии с алгоритмами правил конвертации объекта (ПКО) и настроенными ПКС (правилами конвертации свойств). При этом, общий порядок процедур конвертации в случае загрузки отличается от алгоритмов, выполняемых при выгрузке. В случае выгрузки срабатывает алгоритм «При отправке»:

   

   Рис. 45

   При загрузке же выполняются 2 алгоритма — «При конвертации данных», «Перед записью полученных данных». Третий алгоритм «После загрузки всех данных» выполняется позже, когда для всех объектов уже выполнены ПОД и ПКО:

   

   Рис. 46

5. Следующим этапом происходит вызов обработчика «Перед отложенным заполнением», определенного для конвертации:

   

   Рис. 47

   Также после выполнения ПОД и ПКО для всех объектов выполняются алгоритмы ПКО «После загрузки всех данных» (см. п. 4).

6. И, наконец, выполняется завершающий конвертацию алгоритм «После конвертации». Он определяется для конвертации в целом, поэтому настроить его можно в глобальных обработчиках конвертации:

   

   Рис. 48

Случай #6: Добавление настройки свертки номенклатуры на узле обмена

Задача

Необходимо данные табличных документов выгрузить из конфигурации «1С:УНФ 8. Управление предприятием общепита, редакция 3.0» (далее — УПО) в «1С:Бухгалтерия предприятия» (далее — БП) в неком свернутом виде. Например, 2 строки с номенклатурами «Холодильник» и «Микроволновая печь» в количестве по 1 шт. необходимо выгрузить в БП в 1 строку «Бытовая техника в ассортименте» с количеством 2 шт.

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

Решение

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

Рис. 49

В режиме предприятия настройка на узле выглядит следующим образом:

Рис. 50

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

Перед запуском алгоритмов конвертации система инициализирует и заполняет важнейшую структуру «КомпонентыОбмена» (см.п. 1 на схеме), которая содержит в себе все алгоритмы и параметры конвертации:

Рис. 51

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

Рис. 52

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

Первичная инициализация структуры «ПараметрыКонвертации» происходит в модуле менеджера обмена (для каждого плана обмена он может быть индивидуальный, в нашем случае это общий модуль «МенеджерОбменаЧерезУниверсальныйФормат»), в процедуре «ЗаполнитьПараметрыКонвертации»:

Рис. 53

Значения этой структуры устанавливаются в процедуре «Перед конвертацией» (см. п. 2 на схеме):

Рис. 54

В конфигурации «Конвертация данных» настроить обработчик можно в элементе справочника «Конвертации» на вкладке «Глобальные обработчики конвертации»:

Рис. 55

Значения структуры могут быть заполнены из реквизитов узла обмена. Узел обмена («УзелКорреспондента»), как и параметры конвертации, является свойством структуры КомпонентыОбмена, поэтому к нему можно обратиться следующим образом «КомпонентыОбмена.УзелКорреспондента». Доработаем процедуру «Перед конвертацией» в конфигурации «Конвертация данных»:

Рис. 56

Итак, мы добавили и определили значения двух новых параметров конвертации:

• УОП_СворачиватьНоменклатуру (булево) — признак необходимости свертки номенклатуры.
• УОП_СворачиваемаяНоменклатура — соответствие категорий номенклатуры, которые подвергнутся свертке и номенклатуры, которой они будут представлены в файле выгрузки в свернутом виде.

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

Рис. 57

Процедура «УОП_СверткаНоменклатурыПередОтправкой» выполняет изменение табличной части передаваемых данных, а процедура «УОП_ВставитьОтметкуСвертки» добавляет дополнительный признак того, что данный объект выгружен со свернутой номенклатурой. Для этого в свойство AdditionalInfo помещаем соответствующий флаг:

Рис. 58

О том, как расширять возможности схемы XDTO читайте в нашей статье «Конвертация данных вер.3 с применением расширения формата обмена» https://rarus.ru/publications/20230227-ot-ekspertov-konvertaciya-dannyh-3-format-obmena-581588

Ранее мы произвели настройку свертки номенклатуры на узле обмена в режиме 1С:Предприятия, где задали, что вся номенклатура с категорией «Бытовая техника» будет выгружена в 1 строку номенклатуры «Бытовая техника в ассортименте».

Рассмотрим передачу из УПО в БП документа «Расходная накладная» следующего вида:

Рис. 59

У номенклатуры «Холодильник BEKO» и «Микроволновая печь SAMSUNG» выставлена категория «Бытовая техника»:

Рис. 60

Значит в соответствии с настройками конвертации они будут свернуты в одну номенклатуру «Бытовая техника в ассортименте» в количестве «3 шт». Рассмотрим выгруженный объект XDTO в файле выгрузки:

Рис. 61

Как видим, табличная часть выгруженного объекта состоит из 1 строки «Бытовая техника в ассортименте».

На сторону БП документ будет загружен в соответствии с объектом XDTO, т. е. следующего содержания:

Рис. 62

Случай #7: Отказ от загрузки определенного вида объектов XDTO из файла

Задача

В продолжение работы с предыдущей задачей рассмотрим случай, когда в сообщении обмена содержится объект XDTO, который мы не хотим загружать в базе-приемнике. Например, после выгрузки документа из УПО на сторону БП, нам не нужна обратная загрузка этого же документа, если была включена настройка свертки, так как это приведет к потери исходных данных.

Решение

Давайте возьмем документ загруженный ранее и увеличим количество свернутой позиции номенклатуры «Бытовая техника в ассортименте» до 4:

Рис. 63

Данное изменение зарегистрируется к выгрузке на узле обмена УПО и при выполнении синхронизации выгрузится в файл обмена в количестве «4 шт.»:

Рис. 64

Рис. 65

Теперь в случае его загрузки на стороне конфигурации УПО, изначальный документ с полным перечнем номенклатуры будет затерт свернутыми данными.

Избежать загрузки нежелательного типа документа в базе-приемнике можно с помощью отключения соответствующих ПОДов в процессе загрузки. Отключать их следует перед началом процедуры конвертации данных в процедуре модуля менеджера обмена «ПередКонвертацией» (см. п. 2 на рис. 40). Массив используемых в процессе компоновки ПОДов определяется в модуле менеджера обмена (процедура «ЗаполнитьПравилаОбработкиДанных») и записывается в свойство структуры «КомпонентыОбмена» (см. п. 1 на рис. 40) сразу после чтения файла обмена, поэтому к перечню ПОДов можно обратиться через «КомпонентыОбмена.ПравилаОбработкиДанных»:

Рис. 66

В процедуре «ПередКонвертацией» (см. п. 2 на рис. 40) менеджера обмена удалим выбранные ПОД из перечня обрабатываемых в «Конвертации данных»:

Рис. 67

Рис. 68

Таким образом, столкнувшись в процессе компоновки с объектом XDTO определенного типа система не будет «знать», по какому правилу его требуется обрабатывать и пропустит. Данный алгоритм можно заметить в процедуре «ПрочитатьСообщениеОбмена» модуля «ОбменДаннымиXDTOСервер»:

Рис. 69

В результате синхронизации на стороне УПО исходный документ останется неизменным:

Рис. 70

Случай #8: Использование одного объекта XDTO для описания нескольких видов объектов ИБ

Задача

Следующий случай произошел с нами при реализации обмена между конфигурациями «1С:УНФ 8. Управление предприятием общепита, редакция 3.0» (УПО) и мобильным приложением «1С:Кладовщик». В УПО для отражения процесса инвентаризации существует два документа: «Инвентаризационная опись» и «Инвентаризация запасов». Опись фиксирует список позиций, который должен обойти и проверить сотрудник. По результатам обхода всех описей формируется единый документ инвентаризации. Если же на складе работает лишь один сотрудник, то необходимости в создании отдельных документов описи нет и можно сразу работать с инвентаризацией.

При этом в мобильном приложении «1С:Кладовщик» есть только один объект отражающий процесс инвентаризации.

Решение

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

Рис. 71

Следует учесть, что обмен тем или иным типом документа будет производиться посредством одного типа объекта XDTO — «ПересчетТоваров»:

Рис. 72

По своей структуре он подходит и для обмена документами «Инвентаризация», и «Инвентаризационная опись». Поэтому нет необходимости вносить коррективы в схему XDTO. Будем решать эту задачу средствами гибкой настройки конвертации.

В первую очередь создадим правила конвертации на каждый тип метаданных для загрузки и выгрузки. Таким образом, получим 4 ПКО для данного объекта XDTO:

Рис. 73

Затем создадим правила обработки данных (ПОД). Начнем с правил для загрузки. КД3 позволяет выбрать использование сразу нескольких ПКО, поэтому выберем настройку количества правил конвертации «несколько» и подберем оба ПКО для загрузки. Получим следующего вида ПОД:

Рис. 74

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

Рис. 75

В нашем случае настройка в узле обмена установлена в «Истина», поэтому алгоритм конвертации будет работать только с ПКО «Документ_ПересчетТоваровОпись_Получение».

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

Рис. 76

В зависимости от настройки использования инвентаризационных описей или обычных инвентаризаций нам необходимо задействовать только одно из данных ПОДов. Эту задачу можно решить следующим образом.

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

Рис. 77

Таким образом, останется только один из ПОДов для отправки — «Документ_ПересчетТоваров_Отправка» или «Документ_ПересчетТоваровОпись_Отправка». В первом случае будут выгружены только документы «Инвентаризация», во втором — «Инвентаризационная опись».

Также рекомендуем отключить регистрацию не нужного типа объекта к отправке. Для этого можно добавить соответствующее фильтрующее условие в макете правил регистрации:

Рис. 78

Или непосредственно в настройках правил регистрации. В нашем случае мы добавили условия на объекты типов «Инвентаризация» и «Инвентаризационная опись», вызывая функцию «УОП_ПроверитьПризнакИнвентаризационнойОписи», которая возвращет значение настройки узла обмена:

Рис. 79

Случай #9: Замена номера документа для осуществления «своей» нумерации в приемнике

Задача

Рассмотрим доработку обмена, когда выгруженный документ из УПО в БП должен иметь номер либо как в базе-отправителе, либо заполняться в соответствии с внутренней сквозной нумерацией в базе-приемнике. Вариант нумерации определяет пользователь с помощью настройки на узле обмена.

Принцип добавления такой настройки описан в «Случае #1», поэтому не будем останавливаться подробно, просто примем во внимание, что пользователь базы-приемника (БП) пожелал вести сквозную нумерацию документов в программе и выбрал настройку нумерации «Установить в приемнике»:

Рис. 80

Решение

При обмене данными между решениями 1С номера документов в базе-приемнике по умолчанию устанавливаются такими же, как и в базе-отправителе. Чтобы номер документа в базе-приемнике сгенерировался следующим по списку с внутренним префиксом, необходимо передать в качестве номера пустое значение.

При выполнении загрузки объекта XDTO в базе-приемнике выполняется поиск существующего объекта по ключевым полям, либо создание нового объекта ИБ согласно подготовленным данным, полученным при конвертации. Запись объекта в информационную базу осуществляется функцией «СтруктураОбъектаXDTOВДанныеИБ» общего модуля «ОбменДаннымиXDTOСервер», в ней же происходит вызов процедуры установки номера объекта ссылочного типа:

Рис. 81

В случае, если поле «Номер» объекта для записи в ИБ не задано, оно генерируется в соответствии с правилами, определенными внутри базы-приемника, что соответствует требованиям решаемой нами задачи:

Рис. 82

Однако номер документа в подавляющем большинстве объектов типа «документ» в пакете XDTO является одним из его ключевых свойств и обязателен к заполнению (об этом свидетельствует значение свойства «Минимальное количество» = 1). То есть структура пакета XDTO не позволяет передать пустое значение номера:

Рис. 83

Тип поля номер «ТипНомераДокумента» — это строка до 256 символов:

Рис. 84

Для того чтобы разрешить эту ситуацию, передадим вместо пустой строки фиксированный строковый идентификатор, который будет известен передающей и принимающей стороне и для базы-приемника будет маркером очистки номера. В нашем случае таким идентификатором была строка «XupoNpriemX». Эту строку на стороне УПО мы помещаем в поле «номер» пакета XDTO, а в БП считываем перед записью в структуру ДанныеИБ, т. е. перед записью объекта в базу.

Поскольку идентификация документов при обмене данными происходит исключительно по GUID’у, а не по номеру, то изменение нумерации на стороне БП никак не помешает обмену:

Рис. 85

В конце процедуры «ВыполнитьПроцедуруМодуляМенеджера» после выполнения всех обработчиков конвертации объекта выполним процедуру по замене номера, где пропишем следующее:

Рис. 86

Для примера отправим документ «Приходная накладная» из УПО в БП с номером «НФУР-000013»:

Рис. 86

В выгружаемом файле значение поля «Номер» заменилось фиксированной строкой:

Рис. 88

Теперь в базе-приемнике этот номер необходимо корректно обработать.

Здесь нам следует произвести замену до всех процедур конвертации. В начале процедуры «ВыполнитьПроцедуруМодуляМенеджера» вызовем функцию корректировки номера. При этом номер будем редактировать в структуре «ПолученныеДанные», при загрузке она будет перенесена в данные объекта информационной базы:

Рис. 89

При обнаружении в поле «Номер» предопределенной строковой комбинации XupoNpriemX значение поля очищаем. Далее номер документа генерируется в соответствии с правилами базы-приемника. В результате, после загрузки сообщения обмена на стороне БП полученный документ имеет собственную сквозную нумерацию:

Рис. 90

Случай #10: Передача дополнительных сведений табличных частей из УПО в БП

Задача

Существует необходимость передать отраслевой реквизит табличной части документа «Выпуск продукции» из УПО в БП. Однако в пакете XDTO, применяющемся для обмена документами данного типа («Документ.ВыпускПродукции»), отсутствует свойство под этот реквизит.

Решение

Для того, чтобы не пришлось дорабатывать под наши цели пакет XDTO, было принято решение отправить эту информацию в дополнительных сведениях.

Базовым типом для документов и справочников в пакете XDTO EnterpriseData_x_x_x является тип Object. Если посмотреть описание типа Object в пакете ExchangeMessage (1c.ru/SSL/Exchange/Message), то найдем свойство AdditionalInfo с типом anyType (w3.org/2001/XMLSchema). Его и будем использовать для передачи дополнительной информации по объекту:

Рис. 91

На стороне УПО для правила объекта «Документ_Производство_Отправка» доработаем алгоритм ПКО «При отправке данных» (см. п. 4 на схеме), где заполним соответствие вида «Номер строки ТЧ» — «Значение отраслевого реквизита в строке». На рис. 92 переменная — «СуммыБезНДС»:

Рис. 92

Далее в процедуре «УОП_ДобавитьAdditionalInfo» добавляем это соответствие в свойство «УОП_Продукция_СуммыБезНДС» структуры AdditionalInfo с учетом того типа сведений, который мог быть уже помещен в свойство (JSON строка или структура):

Рис. 93

Теперь создадим документ «Выпуск продукции», чтобы убедиться в корректности и полноте отправляемых сведений:

Рис. 94

В результате синхронизации сообщение обмена будет выглядеть следующим образом:

Рис. 95

С помощью AdditionalInfo передаются различные дополнительные параметры, но нас будет интересовать свойство «УОП_Продукция_СуммыБезНДС». Как видим, соответствие номеров строк (Key) и значений по строке отраслевых реквизитов (Value) присутствуют в нужном нам виде в выгружаемом файле.

Теперь остается корректно принять эти данные на стороне БП. Для конфигурации БП все доработки делаем в расширении.

Получить значения принимаемых отраслевых реквизитов мы можем в процедуре «ПриКонвертацииДанныхXDTO» (см.п.4 на схеме) для объекта «ВыпускПродукции»:

Рис. 96

Поскольку в AdditionalInfo мы помещали структуру, то и в приемнике сможем работать с ней как со структурой и получить свойство «УОП_Продукция_СуммаБезНДС» через точку. Далее, с учетом полученных дополнительных свойств, мы можем скорректировать нужным образом значения загружаемых данных. В нашем случае необходимо было повлиять на реквизит «Плановая стоимость» в строке ТЧ.

Заключение

Итак, мы разобрали с вами 10 самых разных случаев, немного привели в порядок общую схему конвертации в части ее этапов, событийной модели, терминологии. Конечно, описанные здесь случаи не описывают всего, что можно рассказать в части конвертации и скорее всего мы продолжим повествование. Ну, а пока всё, читайте и получайте удовольствие от превращения одних данных в другие. :)