Конвертация данных руководство по

 Содержание
1. Вступление
2. Что понадобится: конфигурация 1С: Конвертация данных 2. и обработки из пакета. Для примера задач возьмем конфигурации 1С: Управление торговлей 11 и 1С: БП 3.*.
3. Нам понадобятся Обработки для выгрузки структуры метаданных и обмена.
4. Выгрузка структуры метаданных конфигурации 1С: Управление торговлей 11.3 и 1С: Бухгалтерия предприятия 3.0.*
5. Загрузка структур метаданных конфигураций в базу конвертации.
6. Создание правил конвертации в 1С на конкретном примере задачи.  
7. Подводим итоги: Выгрузка и загрузка данных с помощью разработанных правил обмена данными.

1. Вступление.

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

2. Что понадобится: конфигурация 1С: Конвертация данных 2.* и обработки из пакета. Для Примера задач возьмем конфигурации 1С: Управление торговлей 11 и 1С: БП 3.*.

Итак, для разработки правил выгрузки данных в 1С потребуется конфигурация 1С: Конвертация объектов 2, а также обработки, входящие в пакет.

Например, у нас уже развернута база конвертации и запущена.

 
Разработку правил обмена будем писать между конфигурацией 1С:  Управление торговлей 11 и 1С: Бухгалтерия предприятия 3 (правила обмена УТ / БУХ).

3. Нам понадобятся Обработки для выгрузки структуры метаданных и обмена.

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

Собственно, в распакованном каталоге конфигураций для конфигураций на управляемых формах нас интересует обработка MD83Exp.epf. Если выгрузку нужно сделать из конфигураций на обычных формах, тогда используется обработка MD82Exp.epf. Это если, например, нужно получить структуру из таких конфигураций, как 1С: УТ 10, 1С: Управление производственным предприятием 1.3, 1С: Комплексная автоматизация 1.1, 1С: Зуп 2.5 и так далее.

Далее уже для выгрузки-загрузки данных в 1С с помощью наших правил понадобится обработка «Универсальный обмен данными в формате XML» V8Exchan83.epf для конфигураций на управляемых формах таких как 1С: Управление торговлей 11.*, 1С БП 3, 1С: ERP 2.* и подобных. И соответственно V8Exchan83.epf — для конфигураций на обычных формах.

4. Выгрузка структуры метаданных конфигурации 1С: Управление торговлей 11.3 и 1С: Бухгалтерия предприятия 3.0.*

Начнем с выгрузки структуры метаданных из конфигурации 1С: Бухгалтерия предприятия 3.
Откроем обработку MD83Exp.epf
 

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

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

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

 

В диалоговом окне загружаем структуру БП:

 

  И аналогично — структуру Управления торговлей.

 

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

 

  6. Создание правил конвертации в 1С на конкретном примере задачи.

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

 

  Так как в этой статье планировал показать создание «с нуля» и «без мусора», напоминаю, что ничего автоматически не создаем. Никаких прототипов. 
 

В этом диалоговом окне ничего выполнять не будем, просто нажмем — «Закрыть».

Создадим правила для выгрузки не один документ в один, а один вид в другой, например, документ РеализацииТоваровУслуг из УТ 11 с необходимыми справочниками в документ ПоступлениеТоваровУслуг в БП 3.

Итак, создаем новое ПКО (правило конвертации объектов в 1С)

 

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

 

  А вот на предложение создать ПВД (правил выгрузки данных) отвечаем «Да». 

 

 

Создаются ПВД, которые и будут отражаться в обработке универсального обмена XML для выбора:
 

Создадутся так же правила конвертации данных с пустыми правилами конвертации свойств. 

 

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

Снимаем поиск по УИО: 
 

  Теперь начнем сопоставление необходимых свойств (реквизитов) объекта. Для этого жмем «СинхронизацияСвойств»  (метка «1» на скрине). Убираем рекурсивное создание правил («2»). Снимаем все отмеченные реквизиты («3»). И выберем самостоятельно, что нам нужно.

 

Для примера выбираем необходимое:

 

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

 

Далее жмем ОК и получаем подобное:

 

  Где видим, что еще нет правил конвертации.

Начнем по реквизитам проходить и описывать. Сначала настраиваем поиск документа так, как писал ранее, делаем выгрузку и поиск документа на начало даты, и сделаем подмену нумерации. Первые три символа будем подменять на свой префикс «УТБ». А так как в БП и УТ нумерация по 11 символов, делаем составной номер: наш префикс и 8 символов от источника. Пример на скрине ниже.

 

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

Для этого ПКС установив, как не проведен, 0 или 1, используем как булево.

 

  На примере валюты создаем для ПКС правило конвертации объекта. При этом считаем, что в обеих базах валюты имеются, и они должны синхронизироваться по коду. Поэтому в ПКО валют не будем создавать все ПКС, а только добавим Код для поиска. Т.е. от предложения создать ПКС для объекта – отказываемся.

 

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

В итоге получаем вариант:

 

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

 

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

 

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

 

  Ниже показано, как установить без сложностей и в большинстве случаев ПКС для КратностьВзаиморасчетов, КурсВзаиморасчетов, Счета учета.

 
Для ПКО Номенклатура оставим поиск по внутреннему уникальному идентификатору. Но обращу внимание на то, как можно переопределить свою группу. Например, мы согласны, что будет выгружаться новая номенклатура из конфигурации 1С: Управление торговлей 11, но нужно, чтобы номенклатура собиралась в определенной группе «НашаГруппа».

 

  Для реализации данной задачи создаем ещё одно ПКО. Назовем его «НоменклатураРодитель», которое укажем в ПКС родителя в правиле конвертации.

Устанавливаем два поиска: по наименованию, где наименование жестко указываем нашей группы, и обязательное свойство признака «ЭтоГруппа» в истина.

 

  Поскольку мы приняли решение, что у нас вся номенклатура падает в нашу группу, то нет необходимости при выгрузке выгружать группы из УТ 11. Для этого в ПКО Номенклатура в обработчике событий «ПередВыгрузкой» поставим фильтр, что не нужно выгружать группы «Отказ = Источник.ЭтоГруппа;».

 

В ПВД (правила выгрузки данных) РеализацииТоваровУслуг, добавим фильтр, чтобы не выгружались помеченные на удаление документы. Для этого в ПВД в обработчиках событий «ПередВыгрузкой» пропишем фильтр «Отказ = Объект.ПометкаУдаления;».

  

  Сохраним разработанные правила в файл.

 

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

Открываем в 1С:Управление торговлей 11 обработку «Универсальный обмен данными в формате XML» V8Exchan83.epf.

 

  Выгрузка прошла, теперь этой же обработкой делаем загрузку в 1С: Бухгалтерия предприятия 3.

 
 

 
Загрузка прошла. Проверяем, что как загрузилось. Итак, документ загружен, как мы и добивались — у нас Организация загружена в контрагента, а контрагент в организацию. Счета учета все загружены и установлены. Номер документа у нас получился с нашим префиксом и на начало дня. Все реквизиты, которые прописали, заполнены.

 

  Проверяем загрузку номенклатуры. Видим, что всё получилось так, как мы и планировали.

 

 

 
У нас создались и заполнились реквизиты так, как мы это задумывали. В конвертации имеется множество тонкостей и каких-то простых, но нужных вещей, которые помогают точно написать конвертацию. А это позволяет минимизировать ошибки, не испортить существующие данные и избавиться от лишнего мусора. Это один из самых простых примеров. Можно так же делать конвертации одного объекта во многие или же наоборот многие — в один.

Сейчас есть конвертация данных 3, она решает другие задачи. Поэтому конвертация 2, так же нужна. Всем удачи в изучении и освоении. 

Конечно, если Вы программист и это — основная ваша работа, Вы можете сами попробовать написать конвертацию. Но если нет, то стоит ценить Ваше время в своей сфере деятельности, а данную задачу попросить выполнить профессионалов. 

Сергей ОМЕЛЬЧУК,
программист 1С, руководитель отдела внедрения ООО “Кодерлайн”

Введение

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

Глоссарий принятых сокращений размещён в конце статьи. Перейти к нему для ознакомления можно по ссылке.

Возникновение нового подхода к обмену в типовых решениях 1С

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

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

При этом уже знакомые нам технологии обмена, такие как обмены по правилам КД2 (1С:Конвертация данных 2.x), обмены между идентичными конфигурациями (выгрузка-загрузка данных XML, РИБ), не ушли в прошлое, а продолжают использоваться для своих задач.

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

Поэтому для новой технологии был разработан формат данных, созданный на основе таких стандартизованных объектов. И конфигурации в формате КД3 (1С:Конвертация данных 3.x) обмениваются между собой именно с помощью этого промежуточного звена — формата Enterprise Data (ED). Это позволяет использовать технологию обмена не только между конфигурациями на платформе «1С:Предприятие», а между базой 1С и любой программой, которая может работать с форматом ED, считывать и загружать данные в нужном формате.

Кроме того, важным преимуществом формата КД3 является то, что при изменении одной из конфигураций в обменной схеме потребуется изменить лишь формат ED, а не каждый xml файл правил на вход/выход для каждой конфигурации по соседству как было бы с измененной в цепи обмена посредством КД2.

Главной особенностью КД3 является концепция конвертации данных. Источник — its.1c.ru/db/metod8dev/content/5846/hdoc

На рисунке выше видно, что основное отличие КД3 от КД2 — наличие промежуточного звена обмена данными, а именно формата EnterpriseData. Данные, подлежащие выгрузке представляются в виде формата XDTO, и база-приемник работает уже с данными, сконвертированными в объект формата.

На стороне конфигуратора 1С формат ED представлен следующими основными объектами:

• Несколькими XDTO-пакетами:

  

• Общим модулем «МенеджерОбменаЧерезУниверсальныйФормат», в котором содержатся правила конвертации и обработки объектов в/из объекты формата.
• Планом обмена «СинхронизацияДанныхЧерезУниверсальныйФормат».
• Общими модулями «ОбменДаннымиXDTOСервер», «ОбменДаннымиПереопределяемый», «ОбменДаннымиСобытия».
• Обработкой «КонвертацияОбъектовXDTO».
• А также подписками на события, регистром сведений «НастройкиОбменаДаннымиXDTO».

Формат ED включают в себя описание бизнес-сущностей из различных областей хозяйственно-экономической деятельности предприятия и является расширяемым. С каждой версией формата ED фирма «1С» добавляет в него описание новых сущностей и расширяет существующие новыми полями.

Номера версий формата ED состоят из X.Y.Z, где X.Y. — это Major версия, Z — это Minor версия.

Как видно, для описания объектов формата уже существует несколько пакетов XDTO под различные версии. Изменение Minor версии не приводит к потери совместимости с предыдущими minor весиями. Major версии не имеют обратной совместимости.

Фирма «1С» гарантирует 1 год поддержки с момента выхода major-версии. По ссылке its.1c.ru/db/metod8dev#content:5934:hdoc можно увидеть все версии и сроки их поддержки детально.

Сейчас типовые конфигурации 1С массово используют новый подход с применением универсального формата ED. Рассмотрим, как выполнить обмен посредством XDTO на примере конфигураций «1С:Управление предприятием общепита» (далее — УПО) и «1С:Бухгалтерия предприятия 3.0» (далее — БП).

Пример настройки синхронизации между типовыми решениями «1С:Управление предприятием общепита» и «1С:Бухгалтерия предприятия 3.0»

Первое,что нужно сделать — перейти в подсистему «Администрирование» → «Синхронизация данных» в БП (1С:Бухгалтерия предприятия) и в открывшейся форме установить флаг «Синхронизация данных».

Аналогичные действия необходимо произвести во второй базе — УПО (1С:Управление предприятием общепита). В этой же форме для обеих баз нам понадобится задать их префиксы (см. рисунок выше), они пригодятся нам при настройке обмена для идентификации узла.

Настройка обмена посредством формата КД3 происходит последовательно:

1. Сначала настраивается обмен в первой конфигурации (в нашем случае начнем настраивать из УПО), в результате будет сформирован файл настроек для второй конфигурации.
2. Затем во второй конфигурации анализируется данный файл настроек, выгружается встречный, а также осуществляется первоначальная выгрузка данных.
3. И наконец приходит черед первой конфигурации, она принимает на вход встречный файл настроек, читает пришедшие данные выгрузки и выгружает свою первоначальную выгрузку. Рассмотрим этот процесс детально.

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

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

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

Сперва необходимо настроить параметры подключения баз друг к другу: можно выбрать прямое подключение, подключение к базе посредством интернета, если база опубликована на веб-сервере, а также подключение посредством файла. Рассмотрим третий вариант — флаг «Загрузить параметры подключения из файла» не устанавливаем, т. к. они пока отсутствуют:

На следующей странице выбираем один из вариантов, посредством которого будем обмениваться файлами. В нашем примере выберем каталог:

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

Следующий этап помощника — чтение файла выгрузки из БП, об этом программа нас предупредит:

Теперь необходимо переключиться на сторону БП и проделать там аналогичные шаги.

Создаем новую настройку синхронизации, теперь выберем пункт «Управление нашей фирмой», поскольку конфигурация УПО разработана на базе УНФ:

Настроим параметры подключения, но теперь укажем файл настроек, который мы заранее сформировали на стороне УПО:

Немного слов о файлах, которые уже сформировал УПО.

Первый файл — ФайлНастроекПодключения.xml — содержит в себе информацию об обменивающихся конфигурациях, префиксах (кодах узлов) и способе обмена:

Второй файл — Message_<код узла>_<код узла>.xml:

Второй файл — это по сути инструкция из УПО для БП о том, с какими объектами «умеет» работать УПО (тег AviableObjectTypes), а также с какими версиями формата ED для загрузки и выгрузки каждого такого объекта (теги Sending, Receiving). «*» — означает любой формат.

Так например, объекты Справочник.Контрагенты, Справочник.ЛицензииПоставщиковАлкогольнойПродукции, Справочник.Номенклатура УПО может как отправлять, так и загружать в любом формате ED, объект Справочник.КонтрагентыГруппа — не загружает, а только отправляет в любом формате, а вот объект Справочник.МаркировкаУпаковки может загрузить или выгрузить только в 7, 8 и 10 формате ED.

После загрузки файла с настройками подключения в БП появится возможность использовать гиперссылку помощника «Настроить правила отправки и получения данных». Эти настройки в уже созданной настройке конвертации мы сможем менять позже, так что настройки отправки НСИ и Документов принимаются на усмотрение пользователя. Мы настраиваем тестовый обмен, поэтому первоначальная выгрузка данных из БП нам не нужна для экономии времени. На вкладке «Служебная информация» указано, что по умолчанию предложена опция обмена в 10-м формате ED.

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

Настройка на стороне конфигурации БП завершена. Мы можем убедиться, что в папке появился файл выгрузки из БП — Message_БП_УР.xml, который также содержит информацию по возможным объектам и их форматам для обмена:

Если бы мы выгружали НСИ или документы, то они бы находились в теге Body. Атрибутом тега Body, как видим, является пространство имен того формата ED, который был задействован для выгрузки объектов из базы:

Для каждой синхронизации эти настройки хранятся в регистре сведений «Настройки обмена данными XDTO» (рисунок ниже). На основе этих настроек программа принимает решение, отправлять ей какой-то объект конфигурации, в каком формате и какому узлу:

Теперь мы можем вернуться в УПО и завершить настройку:

По нажатию на гиперссылку откроется форма настроек выгрузки и загрузки данных:

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

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

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

Обзор концепта «1С:Конвертация данных 3»

Двухтактный обмен

В отличие от КД2 обмен с применением технологии КД3 не использует файлов правил, все алгоритмы конвертации и обработки объектов, как выгружаемых, так и загружаемых, располагаются в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. При этом в модуле нет информации об объектах базы, с которой мы будем осуществлять обмен. Мы лишь подготавливаем данные в промежуточный объект XDTO, имеющий фиксированную структуру.

Напомним, что благодаря унифицированности объектов в решениях 1С структура формата максимально близка к структуре бизнес-объектов и достаточна для загрузки и выгрузки основной информации по этому объекту. За подготовку текста модуля МенеджерОбменаЧерезУниверсальныйФормат отвечает программный продукт от компании «1С» — «1С:Конвертация данных 3».

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

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

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

Устройство форматов ED

Для реализации обмена посредством КД3 в конфигурации помимо общего модуля присутствуют XDTO пакеты ExchangeMessage, и EnterpriseData_<версия формата>:

С развитием программных решений 1С состав формата расширяется и совершенствуется. Поэтому в дереве конфигурации мы видим несколько XDTO пакетов, описывающих формат ED.

К примеру, для передачи данных в формате 1.10 будет задействован пакет EnterpriseData_1_10_8, 1.8 — EnterpriseData_1_8_6 и т. п. На текущий момент в большинстве решений 1С по умолчанию устанавливается 10 формат передачи данных, как актуальный, поэтому далее будем рассматривать именно его.

Рассмотрим, что представляет собой объект формата ED на примере документа «Поступление товаров и услуг». Для описания документа в формате XDTO используется 3 сущности — тип значения, тип объекта и тип ключевых свойств объекта.

1. Для описания документа в пакете XDTO определен в первую очередь Тип значения ДокументСсылка.ПоступлениеТовароыИУслуг. Он имеет базовый тип Ref, определенный в пакете ExchangeMessage:

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

Если в описании объекта присутствует свойство ссылочного типа, то оно должно иметь тип КлючевыеСвойства<объект>. Как видим, в качестве типа свойства «Контрагент» указаны ключевые свойства типа объекта Контрагент — КлючевыеСвойстваКонтрагент. Как правило, Ключевые свойства всегда содержат свойство «Ссылка», в которое записывается ГУИД объекта.

3. И наконец третья сущность, с помощью которой документ «Поступление товаров и услуг» представлен в XDTO-формате — это тип объекта — Документ.ПоступлениеТоваровУслуг. Базовый тип для него — Object из пространства имен (1c.ru/SSL/Exchange/Message):

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

Именно в типе <ИмяОбъекта>.<ТияТЧОбъекта>.Строка описываются реквизиты табличной части объекта, а тип <ИмяОбъекта>.<ТияТЧОбъекта> содержит только строку, на которую ссылается, и из которых состоит.
При выгрузке объекта «Поступление товаров и услуг» в формате XDTO он сериализуется в следующем виде:

В секциях-реквизитах шапки «Организация» и «Контрагент» представлены ключевые свойства этих объектов, в секции «Услуги» — описания каждой строки табличной части. Аналогично и табличная часть «Товары» содержит секции «Строка», которые в свою очередь наполнены развернутой информацией по реквизитам строки ТЧ:

Устройство регистрации объектов при обмене в формате XDTO

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

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

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

В качестве фильтра, определяющего необходимость отправки объекта, существуют правила регистрации объекта (ПРО), которые хранятся в макете плана обмена и представлены в виде xml-текста:

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

Практический пример обмена «1С:Фастфуд 2.3» с «1С:Фастфуд 3.0»

Постановка задачи

Необходимо обеспечить обмен по технологии КД3 между решениями 1С:ФФ 2.3 («1С:Фастфуд. Фронт-офис, ред. 2.3») и 1С:ФФ 3.0 («1С:Фастфуд. Фронт-офис, ред. 3.0») нетиповых для формата ED объектов. Поскольку конфигурации ФФ 2.3 и ФФ 3.0 созданы на базе типовых продуктов 1С, они включают в себя подсистему обмена в формате ED и все обновления/дополнения/изменения схем соответствуют «базовым» решениям. Необходимо обеспечить миграцию общих по структуре, но отраслевых объектов и свойств, описание которых отсутствует в форматах ED типовых решений.

Рассмотрим несколько объектов, которые требуется передавать в формате XDTO.

Во-первых, это объекты, отсутствующие в формате ED. Если изучить структуру передаваемых в формате ED объектов, то близких по структуре мы найти не сможем. Так, например, из ФФ 2.3 справочник «рестМеню» должен попасть в аналогичный справочник в конфигурации ФФ 3.0:

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

Способы решения задачи расширения формата

Когда список всех дополнительных объектов к переносу определен, встает вопрос, какими же способами можно решать данную задачу:

1. Во-первых, можно доработать сам пакет XDTO EnterpriseData_1_10. Только его, т. к. на данный момент это актуальная версия. Минусы этого подхода очевидны — для его реализации придется снимать с поддержки сам объект и в случае внесения в него каких-либо изменений со стороны вендора поддерживать корректное обновление, учитывая наши доработки. В случае обновления версии обмена, каждый раз переносить все доработки XDTO из предыдущего пакета в пакет новейшей версии. Это поддерживать довольно проблематично. К такому подходу мы ни разу не прибегали и не рекомендуем.

2. Вторым вариантом может стать использование свойства AdditionalInfo. Поскольку каждый объект в схеме (пример в Документ.ПоступлениеТоваровУслуг рассмотрен выше) определен как тип Object из пространства имен 1c.ru/SSL/Exchange/Message, то можно заметить, что в базовой схеме у типа Object предопределено свойство AdditionalInfo с типом AnyType. Это означает, что мы можем в поле AdditionalInfo указать любую структуру, дополняющую объект.

   Но в случае значительных доработок объекта (как в справочнике «Номенклатура»), придется в AnyType записать как все дополнительные реквизиты шапки, так и все строки ТЧ, которые еще должны идентифицировать каждую строку и ее реквизиты. И получится конструкция-монстр, логику считывания и обработки которой будет описывать непросто, но вполне реализуемо:

   

   Однако этот вариант все же не решает задачу передачи новых типов объектов, ранее не определенных в ED.

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

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

   1С поддерживает вариант расширения форматов обмена ED путем добавления отдельного пакета XDTO, который дополнит уже существующий пакет EnterpriseData_<версия>. Это не означает решения задачи с помощью расширений в понимании патча. Нет, расширение формата обмена — это само название технологии, позволяющей неограниченно расширять существующие форматы ED.

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

Принцип работы с решением «Конвертация данных 3»

Рассмотрим детальнее продукт «1С:Конвертация данных 3.1». Он помогает облегчить труд с изменением общего модуля «МенеджерОбменаЧерезУниверсальныйФормат», отвечающего за обмен в формате XDTO, а также упрощает подготовку XDTO-пакета расширений. На момент написания статьи актуальная версия КД3 — 3.1.2.24, поэтому рассмотрим её возможности.

1. Загрузка структуры конфигурации

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

1.1 С помощью внешней обработки выгрузки структуры конфигурации (по аналогии с КД2) — из поставки решения КД3 берем обработку MD83Exp.epf.

Выполняем следующие действия:

1. Открываем информационную базу в режиме «Предприятие».
2. Открываем внешнюю обработку MD83Exp.epf (Меню Файл — Открыть).
3. Задаем имя файла, в который следует сохранить структуру информационной базы.
4. Проверяем настройки в форме обработки (все флаги должны быть сняты).
5. Нажимаем кнопку Выгрузить.

Далее необходимо подготовленный таким образом xml файл загрузить в КД3. Делается это следующим образом — в подсистеме «Конфигурации» переходим в список «Конфигурации», и создаем новый элемент справочника. Если этого не сделать, то последующая загрузка структуры произойдет в предопределенный элемент «Неизвестная конфигурация». Это не страшно, но лучше создать конфигурацию предварительно, чтобы потом поддерживать релизы и структурировать работу с КД3. Затем необходимо открыть обработку загрузки структуры:

Затем выбрать вариант загрузки — в существующую версию конфигурации (т. е. перегружаем в существующий релиз), либо в новую.

1.2. Второй способ не предполагает использования обработки MD83Exp.epf для выгрузки. В КД3 переходим в «Конфигурации» → «Сервис» → «Загрузка структуры конфигурации из файлов XML/EDT». Открывается форма с возможностью загрузки из файлов xml или EDT:

Мы можем выгрузить структуру из Конфигуратора, либо указав каталог проекта EDT. В случае, если конфигурация разрабатывается при помощи EDT, удобно загружать по настройке «Файлы EDT». В этом случае для загрузки структуры конфигурации будут прочитаны файлы *.mdo в папке src проекта.

Поскольку разработка ФФ ведется в Конфигураторе, выберем загрузку из файлов xml.

Структуру предварительно выгрузим из Конфигуратора. Для этого перейдем в подменю «Конфигурация» → «Выгрузить конфигурацию в файлы»:

В КД3 выбираем подготовленный каталог с выгруженными из конфигуратора файлами и нажимаем «Загрузить». В результате загрузки появится заполненный элемент справочника Релизы:

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

2. Загрузка модулей менеджера

Создаем элемент справочника «Конвертации» — мы настраиваем обмен в формате XDTO, поэтому создадим конфигурацию в этой группе:

Указываем наименование конвертации, версии формата ED, под который настраиваем конвертацию и записываем.

Далее необходимо загрузить новую версию формата (или обновить существующую). Для этого переходим в подсистему «Формат данных» → «Версии формата» → «Загрузка структуры формата»:

Предварительно нужно эту версию экспортировать из Конфигуратора — в контекстном меню для XDTO-пакета ED выбрать «Экспорт XML-схемы». Эту же процедуру проделываем с родительским пакетом ExchangeMessage:

Теперь можем загрузить модуль менеджера для созданной конвертации — в подсистеме «Конвертации» выбираем команду «Загрузка модуля менеджера»:

Для загрузки указываем ранее созданную конвертацию, состав загружаемых данных и способ загрузки. Грузить можно из буфера обмена, поэтому перейдем в конфигуратор базы и скопируем Ctrl+C текст общего модуля. После этого возвращаемся в КД и нажимаем «Загрузить». Результат загрузки модуля мы сможем увидеть, перейдя в «Конвертации» → «Настройка правил конвертации».

Перед нами откроется форма настроек правил обмена:

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

После работы с правилами обмена есть возможность их проверить по некоторым параметрам:

Обработку проверки можно вызвать как из самой формы настроек обмена, так и из подсистемы «Конвертации» → «Сервис» → «Проверка конвертации».

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

Создавать конвертацию и загружать правила из модуля менеджера необходимо для каждой конфигурации, участвующей в обменной схеме. Поэтому те же действия проделаем для второй конфигурации. Пример настройки правил обмена для конвертации с помощью КД3 описан ниже.

3. Создание ПРО с помощью КД3

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

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

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

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

После завершения работы с правилами, их можно выгрузить из КД3:

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

Данный инструмент позволяет переключиться с использования типовых правил на правила регистрации, описанные в файле xml, ранее выгруженном из КД3:

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

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

Реализация задачи расширения

Теперь рассмотрим реализацию задачи по расширению формата обмена. Процесс реализации будет состоять из нескольких шагов:

• Подготовительные действия — создание расширяющего XDTO пакета.
• Наполнение расширяющего XDTO пакета свойствами согласно постановке задачи (2 способа решения задачи).
• Создание конвертации под расширяющий формат и наполнение ее правилами.
• Выгрузка модуля менеджера обмена через универсальный формат из КД3 в конфигурацию.
• Доработка модулей конфигурации для обеспечения работы с механизмом расширений.
• Доработка правил регистрации (ПРО).

1. Создание расширяющего XDTO пакета

Основой механизма расширений является дополнительный, т. н. «расширяющий» XDTO-пакет, который дополняет уже существующий. В нашем примере будем расширять 10-ю версию ED, а значит пакет EnterpriseData_1_10_3.

Унифицированный глобальный идентификатор (URI) пространства имен пакета (v8.1c.ru/edi/edi_stnd/EnterpriseData/1.10) — это пространство имен, а также пространство имен второго базового пакета для формата обмена ED (http://www.1c.ru/SSL/Exchange/Message) необходимо прописать в директивах импорта создаваемого пакета-расширения. А для самого XDTO-пакета URI пространства имен должно выглядеть следующим образом:

http://v8.1c.ru/edi/edi_stnd/<уникальное_наиименование_расширенияформата>/<номер_версии_расширения>

Рассмотрим основные особенности расширяющего пакета:

1.1. Для нового объекта, отсутствующего в базовом пакете ED, например, справочника «рестМодификаторы», необходимо добавить тип значения СправочникСсылка.<имя_объекта> с базовым типом Ref:

Также необходимо описать тип объекта Ключевые свойства с рядом определяющих свойств, в данном случае Ссылка должна иметь тип, который мы только что определили в типах — СправочникСсылка.рестМодификаторы:

И наконец тип объекта Справочник.рестМодификаторы с базовым типом Object, и с обязательным свойством КлючевыеСвойства, которые мы ранее для него определили — КлючевыеСвойстарестМодификаторы:

1.2. Если в объекте присутствует свойство, тип которого уже определен в родительском формате ED, то дублировать его в XDTO-пакете расширении нет необходимости. Указываем тип из базового пространства имен.

Например, в новом объекте расширенного формата Справочник.рестМодификаторы мы добавляем свойство ЕдиницаИзмеренияМодификатора. В базовом пакете 10 формата уже присутствует описание типа КлючевыеСвойстваЕдиницаИзмерения, поэтому в качестве типа укажем тип объекта родительского формата, переопределять в расширенном пакете КлючевыеСвойстваЕдиницаИзмерения нет необходимости, если мы не планируем их изменять:

1.3. Для расширения объекта типа, который уже присутствовал в базовом XDTO-пакете, например, справочника «Номенклатура», не нужно добавлять в расширяющий пакет тип и ключевые свойства. Добавляется только тип объекта Справочник.Номенклатура, у которого заполнен базовый тип из пакета ED 10 формата:

1.4. Если есть необходимость передавать в формате обмена не только элементы справочника, но и его группы, чтобы передавать всю многоуровневую структуру, то для них должны быть определены отдельные типы объектов и типы объектов для ключевых свойств. Например, для справочника «рестМеню» создаем 2 типа объектов Ключевых свойств и 2 типа объекта под сами объекты элементов и групп:

Особенно внимательно следует указывать тип Ключевых свойств, и проставлять соответствующие для элемента КлючевыеСвойстварестМеню, для группы КлючевыеСвойстварестМенюГруппа:

1.5. Для расширения состава передаваемых реквизитов табличной части следует в расширенном пакете связать тип объекта (для которого расширяем ТЧ) с типом объекта базового пакета ED.

Например, мы хотим передавать табличную часть Товары документа ПоступлениеТоваровИУслуг вместе с дополнительным реквизитом «рестЭтоБлюдо». В таком случае в пакете-расширении должен быть определен тип значений ДокументСсылка.ПоступлениеТоваровУслуг с базовым типом ДокументСсылка.ПоступлениеТоваровУслуг (v8.1c.ru/edi/edi_stnd/EnterpriseData/1.10) из родительского пакета «1.10».

Кроме того, необходимо «подтянуть» в расширенный пакет не только тип объекта «Документ.ПоступлениеТоваровУслуг.Товары.Строка», но и все вышестоящие типы:

• КлючевыеСвойстваПоступлениеТоваровУслуг. Базовый тип здесь не указываем, свойство Ссылка имеет тип расширенного пакета — ДокументСсылка.ПоступлениеТоваровУслуг (v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10).
• Документ.ПоступлениеТоваровУслуг, базовы тип не определяем, свойство КлючевыеСвойства с типом КлючевыеСвойстваПоступлениеТоваровУслуг (v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10).
• Документ.ПоступлениеТоваровУслуг.Товары, также без базового типа, свойство Строка имеет внутренний тип Документ.ПоступлениеТоваровУслуг.Товары.Строка (v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10).
• И наконец тип для самой строки Документ.ПоступлениеТоваровУслуг.Товары.Строка (базовый тип не заполняем), который наполняем необходимыми расширенными реквизитами:

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

Готовый XDTO-пакет экспортируем в КД3 (процедура экспорта описана ранее).

2. Наполнение XDTO-пакета свойствами

После создания XDTO-пакета его следует наполнить, определив в нем свойства объектов и типы объектов. Сделать это можно средствами конфигуратора (вручную добавить каждый новый тип объекта, тип значения для него и ключевые свойства, затем добавить свойства объектов), а затем выгрузить расширяемый пакет в КД3 для дальнейшей настройки обмена.

Однако программный продукт КД3 может упростить процесс редактирования и наполнения созданного пакета, рассмотрим как именно.

Для этого выгрузим расширяющий пакет в КД3: в конфигураторе экспортируем пакет ExchangeMessage, оригинальный пакет EnterpriseData_1_10_3 и только что созданный расширяющий XDTO-пакет в каталог на ПК для дальнейшей загрузки их в КД3.

Переходим в КД3, в справочник «Версии формата»:

Стандартные версии ED располагаются в предопределенной группе Enterprise data, версии расширений хранятся в отдельной группе справочника. Отдельную группу создавать вручную нет необходимости, она будет создана автоматически при импорте пакетов. В списке справочника «Версии формата» нажимаем кнопку «Загрузка структуры формата». В форме выбора выбираем сразу все 3 пакета, которые ранее экспортировали из конфигурации, и нажимаем «Загрузить»:

Программа создаст новый элемент справочника версии с признаком «Расширение», а также новый каталог с признаком «Расширение» и заполненным шаблоном пространства имен (версия ED в шаблоне не указывается):

Ничего править не нужно, убедимся лишь в корректности загрузки. Далее перейдем в регистр сведений «Взаимосвязи версий форматов и расширений» и добавим запись для того, чтобы КД3 могла распознать, какой версии ED какое расширение соответствует:

На основании записи в этом регистре КД3 сможет дополнять типовой формат 1.10 расширяющими свойствами и объектами из пакета-расширения.
Теперь переходим к наполнению самого расширяющего формата свойствами и объектами, для этого воспользуемся обработкой «Дерево объектов формата» («Формат данных» → «Сервис» → «Дерево объектов формата»):

Выбираем в поле «Версия формата» расширяющую версию, а в подменю «Еще» → «Редактировать структуру формата». Теперь с деревом структуры появляется возможность работать. Однако, наше дерево пустое и со строкой «Общее» никаких действий произвести не получается. Если же мы посмотрим на структуру 10 версии ED, то увидим, что она содержит и перечисления, и описания типов, общих ТЧ, справочников и документов:

Есть небольшая хитрость, к которой мы и прибегнем, чтобы наполнить наше дерево минимальной структурой. Вернемся в конфигуратор, и добавим в расширяющий пакет 1 тестовый тип, 1 тестовый тип под перечисление (базовый тип у него String, атомарный) и 2 тестовых типа объектов (Справочник.<любое наименование> и Документ.<любое наименование>).

Затем вновь экспортируем пакет и загрузим для уже существующей версии-расширения с отметкой, что грузить будем только дополнительные свойства:

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

Рассмотрим пример добавления справочника — разрешаем редактирование объектов дерева (подменю «Еще») и выделим строку «Справочники», нажимаем «Добавить», открывается форма создания нового объекта формата:

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

Наименование уже содержит подсказку того, как оно должно быть заполнено — начинается со «Справочник.». Допишем только название нашего справочника, например, рестГруппыМодификаторов, нажимаем «Записать и закрыть», Обновляем дерево в форме и видим, что КД3 автоматически создала новый ссылочный тип для нашего справочника и подчиненную строку КлючевыеСвойства (свойство объекта формата):

Посмотрим, как выглядит описание Ключевых свойств на стороне КД3:

Пока Ключевые свойства пустые. Добавим в них свойство Ссылка («Добавить строку» в дереве объектов формата) и попробуем загрузить такой пакет обратно в 1С — для этого перейдем «Формат данных» → «Сервис» → «Выгрузка объектов формата», сохраним пакет в xsd файл, а на стороне 1С импортируем его в наш пакет-расширение:

Мы можем увидеть, что корректно создались тип значений СправочникСсылка.рестГруппыМодификаторов, типы объектов КлючевыеСвойстварестГруппыМодификаторов и Справочник.рестГруппыМодификаторов с необходимыми созависимостями.

Единственное, стоит обратить внимание на то, что, в типе объекта Справочник.рестГруппыМодификаторов не проставлен базовый тип, он должен быть Object, сделаем это вручную:

Также у типа значений не проставился (сбился) базовый тип Ref — дополним его:

Если посмотреть на выгруженный xsd , то базовые типы в нем были определены:

Также как и директива импорта с базовым пространством имен:

Но при импорте базовые типы слетают, и этот важный момент следует учитывать и не забывать сразу указывать корректные базовые типы. Также неприятный момент заключается в том, что КД3 выгружает пакет без директивы импорта с URI базового формата ED, так что на стороне конфигуратора ее придется добавить заново:

Несмотря на это, КД3 все же облегчает и ускоряет процесс наполнения структуры пакета, т.к. объекты визуально представлены в удобном формате дерева. Кроме того, создание XDTO-пакета в КД3 позволяет избежать лишних действий по созданию типов объектов и типов значений для сложных объектов (справочники и документы).

3. Создание конвертации для расширяющего формата и наполнение ее правилами

Следующая задача — доработать правила конвертации для работы с расширениями, поэтому доработаем модуль МенеджерОбменаЧерезУниверсальныйФормат с помощью КД3. Поскольку структуру конфигураций ФФ 2.3 и ФФ 3.0 мы загружали в КД3 ранее, эти действия не повторяем. Создаем новую конвертацию:

В табличной части «Версии формата» обязательно указываем 10-й формат обмена. Затем загружаем модуль менеджера для созданной конвертации:

Теперь можем перейти в его настройку: «Конвертации» → «Настройка правил конвертации». На форме обработки настроек правил конвертации видим, что текущие правила загружены и представлены по вкладкам ПОД, ПКО и ПКПД:

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

3.1. Добавление ПКПД

Рассмотрим на примере перечисления рестТипыНоменклатуры:

В расширении формата ему соответствует тип с добавленными элементами перечислений:

В КД3 на вкладке ПКДП создаем новый элемент и заполняем его в следующей последовательности:

1. Выбираем объект формата:

   

   В списке выбора он появился благодаря тому, что в самой конвертации указана версия формата 1.10, а в РС «Взаимосвязи версий и форматов расширений» указана связь с расширяющим форматом:

   

2. Выбираем объект конфигурации, который при обмене будет сконвертирован в/из объект формата:

   

3. Выбираем область применения правила: только для отправки, только для получения или для обоих случаев. В нашем случае с перечислением оно будет сконвертировано в обе стороны одинаково, поэтому выберем «для отправки и получения»:

   

4. И только после предыдущий этапов заполним поле «Идентификатор» по кнопке «Заполнить». В таком случае идентификатор заполнится автоматически по шалблону:

   

5. Осталось настроить сопоставление элементов перечисления элементам перечисления формата. Если наименования повторяют друг друга, можно воспользоваться кнопкой «Сопоставить автоматически»:

   

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

3.2. Добавление ПКО

Следующий этап — создание правил конвертаций объектов для таких типов объектов как справочники и документы. Для этого перейдем на вкладку настроек ПКО.

Пример: в ПКО для справочника «рестВидыМеню» для свойств Бренд, ВидЦены и Родитель необходимо указать, по какому правилу будут сконвертированы данные свойства при отправке.

Рассмотрим доработки ПКО для новых объектов формата и уже существующих. Для новых объектов формата ПКО пока не созданы, поэтому добавляем новое правило.

Добавление нового правила 

Рассмотрим пример создания правил ПКО для загрузки и выгрузки справочника рестМодификаторы (будем обмениваться полной иерархией). Нам потребуется создать 2 правила «Для отправки» (ПКО для элемента и ПКО для группы справочника), а также 2 правила «Для получения» (также элемента и группы). Начнем с создания правил для группы — рестМодификаторы:

Заполняем ПКО в следующей последовательности: «Объект формата», «Объект конфигурации», «Область применения», затем генерируем «Идентификатор».

Записываем и переходим на вкладку «Правила конвертации свойств». Здесь настроим правила обмена реквизитами и табличными частями. Если не требуется обрабатывать свойства в обработчике «При отправке», то можно создать правила автоматически, воспользовавшись кнопкой «Настройка ПКС»:

Перед нами откроется форма настроек правил конвертации:

Для автоматического создания ПКС нажмем сперва «Автоматическое сопоставление», а затем «Создать правила конвертации свойств».

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

А также строку 160:

Перезапустим базу КД3 и убедимся, что в форме автоматического сопоставления представлены свойства расширения формата.

Для группы справочника мы определяли в формате только ключевые свойства, которые заполнились автоматически:

Далее создаем ПКО для отправки элемента справочника:

Заполним его в той же последовательности, что и правило для Группы. Затем на вкладке ПКС настроим конвертацию свойств — откроем форму «Настройка ПКС» и нажмем кнопку «Автоматическое сопоставление». После нажимаем «Создать правила конвертации» и видим, что реквизиты конфигурации сопоставлены со свойствами формата автоматически, кроме того, для ссылочных реквизитов автоматически подставилось правило конвертации:

Рассмотрим редактирование свойства на примере свойства «ЕдиницаИзмеренияКлассификатора»:

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

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

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

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

Для разработчиков обменов в КД3 напротив каждого обработчика есть подробная справка по нажатию на знак «?»:

Рассмотрим еще одну задачу, для решения которой используем обработчик ПКО «При отправке».

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

Изменение существующего правила типового объекта

Рассмотрим расширение формата типового справочника «Номенклатура». Объект XDTO мы дополнили отраслевыми свойствами для справочника «Номенклатура»:

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

Как видим, таких правил 2 — для элемента справочника для отправки и для получения (флаги «Отправка» и «Получение» в таблице).

Рассмотрим корректировку правила для получения. Перейдем на вкладку ПКС и убедимся, что пока созданы ПКС только для типовых свойств. Затем как и в случае с настройкой в отраслевом объекте нажимаем «Настройка ПКС» → «Автоматическое сопоставление». Существующие ПКС при этом не пропадут, а будут только дополнены новыми ПКС для отраслевых свойств объекта. В завершении обработки автоматического создания ПКС создались как реквизиты «шапки»:

Так и ПКС для табличной части рестГастрономическиеТеги:

В обработчики ПКО также можно вносить коррективы. Но для нашей задачи доработки не понадобятся:

Отключение правила типового и замена на доработанное правило

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

В таком случае правило не будет сохранено в измененный модуль менеджера обмена, выгружаемого из КД3, но в самом КД3 останется. В дальнейшем можно его будет обратно включить, отключив альтернативное при необходимости.

3.3. Создание ПОД для новых объектов формата

Здесь также важна последовательность заполнения. В первую очередь указываем «Область применения», «Объект выборки» и только после этого автоматически заполняем «Идентификатор правила».

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

В данном случае в структуру ИспользованиеПКО мы записали значения ключей (они соответствуют именам ПКО, определенным на первой вкладке ПОД) . Значение ключа Истина будет означать, что выгрузка будет произведена по ПКО, указанному в ключе структуры.

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

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

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

Следует отметить, что параметр «ЭтоОбменЧерезПланОбмена» влияет на много показателей, и его нужно держать всегда либо включенным, либо выключенным.

4. Выгрузка модуля менеджера из КД3 и загрузка в конфигурацию

Когда настройка правил конвертации завершена, необходимо выгрузить модуль менеджера. Выгрузку можно произвести по кнопке «Сохранить модуль менеджера обмена» в форме настройки правил конвертации:

Ранее мы определили путь сохранения модуля менеджера в карточке «Конвертации»:

В указанный для конвертации каталог будет выгружен модуль, сформированный КД3:

Скопируем текст модуля из файла и перенесем в конфигурацию 1С, для которой создавалась конвертация:

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

Что касается загрузки модуля менеджера в конфигурацию, то возможны следующие варианты — определить новый общий модуль менеджера, либо откорректировать существующий. В случае с добавлением нового модуля, необходимо будет заменить использование типового модуля «МенеджерОбменаЧерезУниверсальныйФормат» в соответствии ВерсииФормата. Например:

ВерсииФормата.Вставить("1.10", МенеджерОбменаЧерезУниверсальныйФормат_Расш);

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

5. Доработки конфигурации для обеспечения работы с механизмом расширений

Доработки силами 1С разработчика

Для включения возможности работы с расширенным форматом ED разработчику потребуется изменить процедуру «ПриПолученииДоступныхРасширенийФормата» общего модуля ОбменДаннымиПереопределяемый . В процедуре следует определить соответствие РасширенияФормата — указать Ключ = URI пространству имен расширяющего пакета, а значение — номер расширяемой версии формата:

Доработки модуля менеджера, полученные из КД3 (автоматически сформированные)

Рассмотрим, как изменился МенеджерОбменаЧерезУниверсальныйФормат, сформированный автоматически из КД3 после доработки правил обмена расширенных объектов и свойств формата.

Во-первых, в ПКО расширяемых объектов формата добавился вызов процедуры ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта:

Во-вторых, в ПКО расширяемых объектов для свойств, которые характерны для расширенного формата, определен шестой параметр с пространством имен расширенного пакета «v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10»:

Кроме того, дополнен текст процедуры ЗаполнитьПравилаОбработкиДанных вызовами инициализации ПОД для расширенного формата, как, например, ДобавитьПОД_Справочник_рестМеню_Отправка(ПравилаОбработкиДанных);

Аналогично дополнены тексты процедур ЗаполнитьПравилаКонвертацииОбъектов, ЗаполнитьПравилаКонвертацииПредопределенныхДанных. Если мы определяли в правилах обработчики ВыборкаДанных, ПриОбработке, ПриОтправкеДанных, ПриКонвертацииДанныхXDTO и т. д., то условия их вызова добавятся в процедуры ВыполнитьПроцедуруМодуляМенеджера и ВыполнитьФункциюМодуляМенеджера. И, конечно, модуль менеджера будет содержать все процедуры ПКО и ПОД для новых объектов расширенного формата.

6. Доработка правил регистрации

Поскольку обмен в формате ED выполняется с помощью плана обмена, то для того чтобы можно было зарегистрировать новые объекты формата для узла, нам необходимо доработать состав плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат:

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

В результате создастся элемент справочника «Регистрации». В элементе есть возможность выгрузить правила регистрации, а также есть выбор, куда производить выгрузку — в файл xml или в общий модуль:

Перейдем в «Регистрации» → «Правила регистрации объектов» и добавим правила для новых объектов расширенного формата. При необходимости в ПРО пропишем условия отбора для выгрузки:

После выгрузки правила перенесем в макет плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат.

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

И, конечно, для регистрации нужно не забыть добавить новые объекты в источники подписок на события, например, СинхронизацияДанныхЧерезУниверсальныйФорматРегистрация.

Примеры выгруженных объектов расширенного формата

Рассмотрим несколько отличительных особенностей объектов расширенного формата в файле выгрузки.

Во-первых, в <msg:AvailableObjectTypes> мы увидим добавленные в расширенном пакете типы объектов наряду с объектами базового 10 формата:

Во-вторых, в тэге Body добавится атрибут с расширенным пространством имен:

Типовой объект ED с расширенными свойствами будет выглядеть по своей структуре следующим образом: свойства типового объекта Справочник.Номенклатура не будут ничем отличаться от классической выгрузки в универсальном формате; свойства же расширенного формата будут дополнены «ext1»:

Если посмотреть на новый объект формата (рассмотрим Справочник.рестСтолы), добавленный в XDTO-пакет-расширирение, то мы увидим, что теги как всех свойств объекта, так и сам объект, содержат конструкцию «ext1».

Заключение

Прежде всего следует отметить, что описанная технология расширения формата ED решила самое большое ограничение в применении этого замечательного подхода, а именно, что же делать, если среди объектов формата нет подходящего для нашего случая.

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

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

Обратную связь по нашим экспертным статьям читатель может дать в чате нашего Telegram-канала.

Глоссарий принятых сокращений

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

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

КД2 — программный продукт «1С:Конвертация данных 2.x».

КД3 — программный продукт «1С:Конвертация данных 3.x».

Выгрузка-загрузка данных XML — обработка для полной или частичной выгрузки и загрузки данных информационной базы в файл в формате XML. Обработка может использоваться только в тех случаях, когда информационная база, в которой осуществлялась выгрузка данных, и та, в которой данные загружаются, являются однородными (конфигурации идентичны, данные могут различаться), либо все выгружаемые объекты практически полностью идентичны по составу и типам реквизитов и табличных частей, свойствам «ведущего» объекта метаданных и т. д. Внешняя обработка Выгрузка и загрузка данных XML.epf для запуска в «1С:Предприятии» версии 8.3 находится в каталоге EXE/EXTREPS/UNIREPS83/UploadToXML.

ED — формат обмена данными Enterprise Data. Это формат, позволяющий описать объект информационной базы (контрагента, накладную и т. п.) или сообщить о факте удаления этого объекта.Формат ED включают в себя описание бизнес-сущностей из различных областей хозяйственно-экономической деятельности предприятия и является расширяемым.

УПО — программный продукт «1С:Управление предприятием общепита» , разработан на базе «1С:Управление нашей фирмой 3.0».

БП — программный продукт «1С:Бухгалтерия предприятия».

Обмен данными ED — это обмен с помощью «Конвертации данных 3.x». Эту технологию называют по-разному — «Обмен через XDTO», «Обмен в формате EnterpriseData», «Обмен с помощью Конвертации данных 3.0», «Обмен через Универсальный формат», каждый из вариантов правильный.

ФФ2.3 — программный продукт от компании «1С-Рарус» «1С:Фастфуд. Фронт-офис, ред. 2.3». Создан на базе типового решения «1С:Розница, ред. 2.3».

ФФ3.0 — программный продукт от компании «1С-Рарус» «1С:Фастфуд. Фронт-офис, ред. 3.0 ». Создан на базе типового продукта «1С:Розница, ред. 3.0». На момент выхода статьи находится на этапе разработки.

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

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

ПКПД — правила конвертации предопределенных данных.

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

ПРО — правила регистрации объектов.

БСП — программный продукт «1С:Библиотека стандартных подсистем».

Перейти к началу статьи »

Эффективная работа программ 1С Предприятие 8.3 обусловлена правильностью настройки обмена данными между ними, то есть выгрузки и загрузки справочников, а также другой информации. В некоторых ситуациях для настройки обмена в 1С достаточно воспользоваться обработкой «Универсальный обмен данными XML» или имеющимися типовыми правилами переноса, к примеру, при переходе с одной редакции программ на другую. Они могут быть встроены в программу с определенным списком правил обмена или находиться в папке установленного обновления. Например, AccountingBase («Бухгалтерия», базовая версия) и там находится папка «Обмен данными».

Настройка стабильного и безошибочного обмена между любыми программами 1С быстро и с гарантией

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

Правила конвертации данных в 1С 8.3

Для описания метаданных используется внешняя обработка MD83Exp.epf – для продуктов на платформе «1С:Предприятие 8.3» (управляемое приложение), MD82Exp.epf – для обычного приложения, в формате XML-файла. Обычно файл обработки располагаются в каталоге шаблонов, куда установлена конфигурация. К примеру, C:\Program Files\1Сv8\tmplts\1С\Conversion\3_0_5_3\. В нашем примере используется «1С:Конвертация данных, ред. 3.0» (релиз 3.0.5.3).

Подготовка файла конвертации заключается в формировании XML-файла правил обмена. Рассмотрим на небольшом примере ход его создания.

Шаг 1. Программу можно скачать с сайта ИТС или установить с диска ИТС (доступ и диск предоставляется в рамках абонентского сопровождения 1С для версий КОРП и ПРОФ). Предположим, нам необходимо выгрузить справочник «Контрагенты» из «Бухгалтерии» в «УТ 8.3». Первая программа у нас – «База-источник», а вторая – «База приемник». Отметим, что обмен настраивается не только между базами 8.3, но и между 7.7 и 8.3 и другими.

Шаг 2. Выгружаем в файл XML структуру метаданных баз, задействованных в обмене, с помощью обработки MD83Exp.epf. Для этого в «Базе-источнике» и «Базе-приемнике» в режиме «1С Предприятие» открываем указанную обработку и выгружаем с ее помощью структуру конфигураций, указав имя формируемого файла. Для примера, так и назовем файлы – «База источник» и «База приемник».

По окончании выгрузки у нас получилось два файла с описанной структурой двух конфигураций.

Шаг 3. Выполняем экспорт xml-схемы формата обмена. Это файл с расширением «xsd». Получить его можно и из «Источника», и из «Приемника». Для этого откроем информационную базу в режиме «Конфигуратор» («Открыть конфигурацию»), в дереве метаданных раздел «Общие» и подраздел XDTO-пакеты.

Найдем строки с именем «EnterpriseData» (разные цифры – это разные версии формата) и, нажав правой кнопкой мышки, выберем команду «Экспорт XML-схемы».

Укажем путь выгрузки и выгрузим.

Шаг 4. Добавляем структуру базы выгруженных конфигураций (источника и приемника) в базу «1С:Конвертация данных». Для этого в пункте меню «Конфигурация» для каждого сформированного файла (источник и приемник) выполняем «Загрузку структуры конфигурации».

Указываем путь к нашему файлу, способ загрузки выбираем – «В новую версию конфигурации», и нажимаем кнопку «Выполнить загрузку».

После загрузки файлов, если мы зайдем в раздел меню «Конфигурации», мы увидим две наших загруженных конфигурации.

Шаг 5. Загружаем структуры формата обмена. В пункте меню «Формат данных» выбираем команду «Загрузка структуры формата».

Указываем ранее выгруженный файл и нажимаем кнопку «Выполнить загрузку».

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

Шаг 6. Создание конвертации. Для выполнения поставленной нами задачи, создаем две конвертации. Первая – для выгрузки справочников «Сотрудники» и «Контрагенты» из «Бухгалтерии», а вторая – для загрузки в «УТ». Перейдем в меню «Конвертации».

Для каждой операции указываем наименование, например – «Выгрузка из БП», «Загрузка в УТ», название – БухгалтерияПредприятия, УправлениеТорговлей и версию формата (который мы загрузили, в нашем примере 1.6).

Шаг 7. Для создания правил в том же пункте меню найдем пункт настроек.

Открыв отдельно каждую операцию, настроим ее. На закладке «Правила конвертации объектов» нажимаем кнопку «Создать».

На закладке «Основные сведения» указываем идентификатор нашего правила (например, Справочник_Контрагенты_Выгрузка), объект конфигурации и объект формата. Область применения – «Для отправки».

Жмем «Автосопоставление», а нажатием кнопки «Создать правила конвертации свойств» сохраняем результат.

При необходимости другие поля настраиваются для конвертации вручную.

Шаг 8. Аналогично настраивается правило конвертации для загрузки, в нашем примере в «Управление торговлей». Обращаем внимание, что область применения – «Для получения».

На закладке «Правила конвертации свойств» выполняем автосопоставление и, нажав кнопку «Создать правила конвертации свойств», сохраняем результат.

Шаг 9. В обоих созданных правилах конвертации создаем правило конвертации предопределенных данных, перейдя на одноименную закладку, нажав кнопку «Создать», при этом сопоставив значения в таблице из конфигурации и формата. Область применения – «Для получения и отправки».

Аналогично выполняем действия для правила «Загрузка в УТ».

Указываем новое правило конвертации свойства «ЮридическоеФизиескоеЛицо» для нашего справочника. Откроем правило конвертации объекта «Справочник_Контрагенты_Выгрузка».

На закладке «Правила конвертации свойств» добавим правило конвертации свойства, указав в нем «Перечисление_ЮридическоеФизическоеЛицо».

Действие аналогично и для второго правила «Справочник_Контрагнеты_Загрузка».

Шаг 10. Создаем правило обработки данных. Действия одинаковы для обоих созданных нами правил. Перейдя в правило конвертации, нажимаем кнопку «Создать на основании» — «Правило обработки данных».

Данные в него попадают автоматически.

Аналогично формируем правило для загрузки.

Шаг 11. Выгрузить модуль менеджера обмена, или в правиле конвертации, нажав «Сохранить модуль менеджера обмена», или через пункт «Конвертация» — «Выгрузка модуля».

Аналогично поступаем с правилом конвертации для загрузки справочника.

Далее открываем конфигурацию, для которой предназначается наш модуль, и в дереве метаданных ищем «МенеджерОменаЧерезУниверсальныФормат», открываем его и вставляем туда свой скопированный в буфер обмена модуль.

При настройке обмена рассматриваемая программа имеет пока единственную функцию – формирование текстов общих модулей МенеджерОбменаЧерезУниверсальныйФормат для каждой из баз, используя структуру метаданных конфигураций, участвующих в обмене, и схемы универсального формата. Эти модули лучше сформировать и применять на исходном этапе настройки обмена, а продолжать их доработку стоит прямо в тексте модуля конфигуратора.

Редакция конфигурации «Конвертация данных 3.0» – новая, но прогрессивная технология упрощения обмена между конфигурациями, которая, используя универсальный формат обмена EnterpriseData, позволяет эффективно ответить на вопрос «Как перенести данные из одной 1С в другую?».

Перенос данных между любыми конфигурациями 1С

Конвертация данных, редакция 3.0

Урок 1. Подготовка работы с КД3.0

Конвертация данных, редакция 3.0 (далее КД3.0) – является одним из компонентов технологии обмена данными через формат EnterpriseData.  КД3.0 не является заменой конфигурации Конвертация данных, редакция 2.0 (далее КД2.0).  Это новый стандарт, который   сильно отличается от КД 2.0 .   Главное назначение КД3.0 – это  создание  программный код модуля менеджера обмена , состоящий из процедур и функций, в которых реализована логика загрузки данных, представленных в формате EnterpriseData, а также логика выгрузки данных в формат.

КД3.0 можно скачать на сайте https://users.v8.1c.ru/

Редакция 3.0.5.3 , предназначена для использования с версией системы
1С:Предприятие 8.3 не ниже 8.3.10,  а  редакция 3.0.4.3 –  для использования с версией системы 1С:Предприятие 8.3 не ниже 8.3.8.

Поставка КД3.0 содержит следующие внешние обработки

•   Обработка MD83Exp.epf   “Выгрузка описания структуры метаданных конфигурации 8.3” – предназначена для выгрузки описания структуры метаданных любой конфигурации, реализованной на платформе “1C:Предприятие 8.3”.
• Обработка Выгрузка правил синхронизации.epf  “Выгрузка правил синхронизации через универсальный формат” используемую при подготовке файлов правил конвертации, предназначенных для последующей загрузки в конфигурацию “Конвертация данных”, редакция 3.0.
• Файл “Описание конфигурации.htm” содержит краткое описание
  основных функциональных возможностей конфигурации
  “Конвертация данных”, редакция 3.0.

Дополнительные сведения по конфигурации “Конвертация данных”, редакция 3.0
см. http://its.1c.ru/db/metod8dev#content:5846:hdoc

1. Подготовка к настройке правил

1.1 Обработка “Загрузка структуры формата”

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

Необходимо выгружать все пакеты, которые связаны с форматом. Имена файлов при этом принципиального значения не имеют. Необходимо также выгружать  XDTO-пакет ExchangeMessage

После выполнения загрузки  формата XDTO в КД 3.0 происходит заполнение справочников “Объекты формата”, “Свойства формата”, “Значения формата”

В  справочник “Объекты формата” загружаются :

• Объекты с типом “ТипОбъектаXDTO”, которые отражают ссылочные типы данных (документы, справочники)
• Объекты с типом “ТипЗначенияXDTO”, содержащие перечисление. Они отражают предопределенные данные (например, перечисления)

В справочник “Свойства формата”  загружаются :

• Свойства объектов “ТипОбъектаXDTO”. При этом сами объекты – те что были загружены в “Объекты формата”
• Объекты с типом “ТипОбъектаXDTO” и их свойства, которые отражают табличные части и реквизиты табличных частей

В справочник “Значения формата”  загружаются свойства объектов “ТипЗначенияXDTO”, представляющие собой элементы предопределенных данных. При этом сами объекты – те что были загружены в “Объекты формата”

 1. 2. Обработка “Загрузка структуры конфигурации”

Данная обработка выполняет загрузку структуры метаданных конфигурации в информационную базу Конвертация данных ред.3.

Для выгрузки информации о структуре информационной базы используется обработка MD83Exp.epf, входящая в комплект поставки конфигурации КД3.0

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

1. Открыть информационную базу в режиме “Предприятие”.
2. Открыть внешнюю обработку  MD83Exp.epf (Меню Файл — Открыть).
3. Указать имя файла, в который  следует сохранить структуру информационной базы.
4. Проверить настройки в форме обработки (все флаги должны быть сняты).
5. Нажать кнопку Выгрузить.

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

• Объекты метаданных
• Свойства объектов
• Значения объектов.

Справочник Объекты метаданных  содержит информацию об объектах метаданных конфигурации. Тип объектов фиксируется в соответствующем реквизите. В зависимости от значения реквизита Тип, заполняются реквизиты, описывающие свойства объекта метаданных. Реквизиты объектов метаданных описываются в подчиненном справочнике Свойства объектов. Значения объектов (значения перечислений и имена предопределенных элементов) описываются в подчиненном справочнике Значения объектов.

1.3. Загрузка правил синхронизации через универсальный формат из файлов

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

1.3.1 Подготовка файлов для загрузки правил

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

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

Для подготовки файла с модулем менеджера необходимо войти в информационную базу в режиме Конфигуратор и сохранить общий модуль МенеджерОбменаЧерезУниверсальныйФормат в текстовый файл. Имя файла можно указать любое.

Все подготовленные файлы должны располагаться в одном каталоге.

1.3.2  Загрузка правил синхронизации

Выполняется в информационной базе Конвертация данных ред.3 с помощью обработки Загрузка правил синхронизации из файлов.

В форме обработки указать:

• Каталог обмена, в котором расположены подготовленные ранее файлы
• Конвертацию
• Состав загружаемых данных
  • либо указать вариант “все”
  • либо выбрать выборочную загрузку, и настроить перечень правил, которые следует загружать
• Файл с модулем менеджера обмена (не требуется, если производится выборочная загрузка и не выполняется загрузка обработчиков)

1.3.3 Особенности загрузки в непустую базу

• Если загружаемое правило существует, и оно принадлежит только одной конвертации (текущей) – правило будет изменено. При этом не выполняется анализ отличий между существующим и загружаемым правилом, правило перезаполняется и записывается безусловно.
• Если загружаемое правило существует, и оно принадлежит нескольким элементам справочника Конвертации, включая текущую конвертацию – будет создано новое правило и привязано к текущей конвертации. “Старое” правило останется без изменений, и останется привязанным к другим конвертациям.
• Группы правил не загружаются. Но если правило было отнесено к какой-то группе, при повторной загрузке в это правило данная информация сохранится.