Получить из входящих данных конвертация 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, так же нужна. Всем удачи в изучении и освоении.

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

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

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

а) происходило создание или синхронизации ранее созданных в БП КОРП 3.0 банковских счетов физических лиц, но только тех, у которых в ЗУП создан только один лицевой счет (если несколько – должно быть предупреждение без обмена данными) и только если номер счета задан (если задан номер карты и не задан номер счета – не выгружать);

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

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

а) происходит в полностью автоматическом режиме без участия пользователей;

б) частота выгрузки данных – 1 раз в сутки в промежутке с 02:00 до 02:10 по московскому времени;

в) продолжительность выгрузки данных – не более 5 минут,

г) выполняется для данных базы Общества и всех филиалов.

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

1) в базе ЗУП отбираются все записи регистра «Лицевые счета сотрудников организаций» при условии, что:

а) в ЗУПе у физ лица в организации только один счет (если несколько – то не участвует в обмене);

б) в ЗУПе у физ лица задан номер счета (если номер счета не задан — то не участвует в обмене, даже если задан номер карты ).

2) отобранные записи регистра «Лицевые счета сотрудников организаций» базы ЗУП перегружаются в справочник «Банковские счета» базы БП КОРП.

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

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

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

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

Загружаем в конфигурацию КД 2.1 структуры метаданных конфигураций Источника (ЗУП 2.5) и Приемника (БП КОРП 3.0). Для этого нам потребуюется обработка из состава поставки конфигурации «Конвертация данных» ред. 2.1, которая называется « MD82Exp.epf ». Открываем эту обработку в ЗУП 2.5 и выгружаем структуру с помощью « MD82Exp.epf » в xml файл (настройки флажков в обработке не меняем). Чтобы открыть обработку в БП КОРП надо запустить бухгалтерию как толстый клиент в обычном режиме, для этого в свойствах строки ИБ надо написать: /RunModeOrdinaryApplication

Параметры запуска БП КОРП 3.0 для выгрузки структуры метаданных

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

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

Находим на рабочем столе конфигурации КД 2.1 кнопку «Правила обмена данными», создаем папку «ЗУП 2.5 -> БП КОРП 3.0» в справочнике «Конвертации».

В папке « ЗУП 2.5 -> БП КОРП 3.0 » создаем новый элемент и в открывшемся окне заполняем два верхних реквизита Источник и Приемник.

При записи нового элемента справоника «Конвертации» появится окно помошника авто создания правил обмена – отказываемся от его услуг и закрываем его.

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

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

В другой статье я писал о том, как правильно определить ПВД в п. 4.3: //buh.ruboard.ru/public/695916/

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

Создадим в конвертации новое ПВД и заполним как показано на рисунке

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

Создаём ПКО без использования встроенных помощников!

Рассмотрим настройки каждого из трех ПКО подробнее.

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

6.2 ПКО СправочникСсылка.Контрагенты-> СправочникСсылка.Банки

Контрагенты мы будем конвертировать в Банки из-за различий хранения данных в ЗУП 2.5 и БП КОРП 3.0. В ЗУП 2.5 измерение в регистре сведений «Лицевые счета работников организаций» хоть и называется «Банк», но тип имеет «СправочникСсылка.Контрагенты». «Ох уж эти сказочники» – вспоминаю методологов ЗУПа (особенно когда надо разобрать сборные из лоскутов запросы расчета в куче общих модулей).

6.3 ПКО РегистрСведенийЗапись.ЛицевыеСчетаРаботниковОрганизации -> СправочникСсылка.БанковскиеСчета, флаг ПКС Получать из входящих данных

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

Три ПКС создайте как показано на рисунке.

Колонку «Источник» для ПКС очистим, а в колонке «Получать из входящих данных» поставим везде флажок – мы это делаем потому, что будем организовывать выгрузку записей регистра используя процедуру ВыгрузитьПоПравилу(, , ИсходящиеДанные, , " ВедомостьНаВыплатуЗарплатыВБанк "); , которую поместим в обработчик «Перед выгрузкой» ПВД (об этом подробнее ниже). Мы полностью берем на себя подготовку исходящих данных на стороне Источника, отказываясь от конструктора – только так мы сможем реализовать два условия фильтрации выгружаемых данных.

Немногие знают, что конфигурация «Конвертация данных» ред. 2.1 позволяет создавать глобальные параметры Конвертации типа структура, которые могут быть доступны как на стороне Источника, так и на стороне Приемника; а так же в обработчиках ПВД и ПКО. Я НЕ могу себе представить профессионала по конвертации КД 2.1, который бы не умел пользоваться глобальными параметрами.

Для решения задачи выполним следующую последовательность действий с глобальными параметрами

Методы « Параметры » и « Запросы » служебные и зарезервированы в конфигурации КД 2.1 для режима предприятия. Просто запомните их.

Параметр « Выборка_ЛицевыеСчетаФизЛицВедомости » будет хранить выборку записей регистра, который нам надо выгрузить в БП КОРП, будем использовать этот параметр только на стороне Источника.

Параметр « СтрокаТаблицаКодовФизЛицИБанковСоСчетом » будет заполняться на стороне Источника форматированной строкой, содержащей коды физ лиц, банков и номера счетов и передаваться в Приемник, где строка будет парситься в таблицу значений, для обновления реквизита «Основной счет» физ лиц, с учетом заданных задачей условий.

Обратите внимание на строчку:

В ней создается свойство структуры с именем « Выборка_ЛицевыеСчетаФизЛицВедомости », в которое помещается ВЫБОРКА из запроса. Сам текст запроса заранее написан и помещен на закладку «Алгоритмы/Запросы»:

Запрос «ЛицевыеСчетаФизЛицВедомости» отбирает только те записи регистра сведений «Лицевые счета работников организаций», которые согласно условию задачи содержат записи:

а) с физ лицами в организации с одним счетом (если несколько – то не выгружаются);

б) с физ лица с заданным номером счета (если номер счета не задан — то не участвует в обмене, даже если задан номер карты).

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

7.2 Записи регистра полученные из параметра Выборка_ЛицевыеСчетаФизЛицВедомости выгружаем с помощью метода ВыгрузитьПоПравилу() в процедуре ПВД «Перед обработкой», там же заполняем параметр СтрокаТаблицаКодовФизЛицИБанковСоСчетом

В процедуре ПВД «Перед обработкой» пишем код, который сам за себя говорит:

Используя метод « ВыгрузитьПоПравилу(…) » мы полностью взяли на себя подготовку передаваемых записей регистра, при этом мы заполнили глобальный параметр «СтрокаТаблицаКодовФизЛицИБанковСоСчетом», который будем передавать в базу Приемник в строке

И не забудем написать в процедуре «Перед выгрузкой» Отказ=Истина.

Преобразуем строку из параметра СтрокаТаблицаКодовФизЛицИБанковСоСчетом в таблицу значений. Эту таблицу значений подаем как параметр в запрос ФизЛицаДляУстановкиОсновногоСчета , который определен на закладке «Алгоритмы/Запросы». Запрос возвращает выборку физ лиц и банковских счетов, которые надо установить физ лицам в качестве основных.

Так же можно организовать создание простейшего ЛОГ файла, который будет содержать информацию об измененных в базе Приемнике объектах: основных счетов физ лиц, которые были изменены и другой полезной информации. Файл можно хранить в папке «Users1C_Agent_StarterAppDataLocalTemp».

8.1 Если Объект.ОбменДанными.Загрузка Тогда

Часто в базе Приемнике в процедурах ПередЗаписью и ПриЗаписи подгружаемых объектов можно встретить колоссальные проверки на наполненность различных реквизитов. В этих процедурах первой строкой идет проверка на режим обмена данными: если объекты записываются при выгрузки из другой базы (а не руками пользователя), то проверки НЕ ДЕЛАЮТСЯ.

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

8.2 Повторное использование COM соединения

Суть в том, что КАЖДОЕ COM соединение к базе Приемнику занимает ВРЕМЯ, бывает и дольше 30 секунд. Представьте, что пользователь сам нажимает кнопку «Выгрузить документ» и каждый раз ждет эти несколько десятков секунд. Решается проблема помещением во временное хранилище соединения. Это описано кратко и ясно в публикации: //buh.ruboard.ru/public/331683/

8.3 Используем приемы оптимизации и ускорения на практике

В статье //buh.ruboard.ru/public/695916/ уже писал про некоторые приемы, например, про флаг «Использовать быстрый поиск объекта при выгрузке и загрузке». Его надо ставить когда выгружаемые справочники содержат мало элементов (до 1000).

Рекомендую прочесть статью по оптимизации конвертации данных:

Применим приемы оптимизации в нашем примере:

1) поставим флаг « Выбирать данные для выгрузки одним запросом » в ПВД «РегистрСведенийЗапись.ЛицевыеСчетаРаботниковОрганизации»;

2) в ПКО «РегистрСведенийЗапись.ЛицевыеСчетаРаботниковОрганизации в СправочникСсылка.БанковскиеСчета» поставим флаг « Не запоминать выгруженные объекты »;

3) в ПКО «Р СправочникСсылка.ФизическиеЛица в СправочникСсылка.ФизическиеЛица» поставим флаг « Использовать быстрый поиск при загрузке » — имеет смысл если число элементов справочника не велико (до 1000);

4) для ПКО справочников поставим флаг « Не выгружать объекты свойств по ссылкам » — при выгрузке будет выгружен сам объект и информация для поиска всех его ссылок, но полная информация о зависимых элементах выгружена не будет;

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

Описанный способ решения задачи не является единственным.

Механизмы и транспорт обмена данными. Пример создания в КД 2.1 правил обмена данными ЗУП 2.5 -> БП 3.0. Выгрузка ведомостей и банковских счетов: //buh.ruboard.ru/public/695916/

В конце публикации вы можете скачать архив содержащий: описанные правила выгрузки «Выгрузка лицевых счетов из ЗУП 2_5 в БанковскиеСчета БП КОРП 3_0» и текст этой статьи в формате MS Word .

Буду рад узнать ваше мнение о статье в комментариях и благодарен за оценку.

Вопросы, предложения сотрудничества и замечания пишите в комментариях, в личку или по адресу Panteleev@Inbox.ru

Резюме автора : //infostart.ru/job/resume/537490/

С пожеланием творческих успехов всем посетителям сайта ИС, Пантелеев Иван.

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

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

Либо сделать это в обработчике "При выгрузке" нужно нам свойства, воспользовавшись выражением:

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

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

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

Первым делом нам понадобится служебное правило конвертации объекта. Добавляем ПКО и в мастере создания заполняем:

• Объект информационной базы источника. Оставляем пустым.
• Объект информационной базы приемника. Выбираем ссылку на объект метаданных (в моем случае «СправочникСсылка.ПодразделенияОрганизаций»).
• Имя правила конвертации объектов. Указываем имя правила. Я в качестве имени указал «Агенты_ПодразделениеОрганизаций».

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

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

• Источник. Оставляем поле пустым.
• Приемник. Выбираем «Код».
• Ставим флаг «Поиск объекта при загрузке по свойству»;
• В обработчике события «Перед выгрузкой» пишем незамысловатую строчку кода:

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

Источник. Наш реквизит, содержащий код для поиска в другом справочнике (КОНТ_Подразделение);

Приемник. Реквизит приемник. В моем случае «ПодразделениеОрганизации»;

Правило. Созданное нами ПКО – «Агенты_ПодразделениеОрганизаций»;

На картинке это выглядит следующим образом:

Все, на этой ноте можно поставить жирную точку. Нестандартное правило готово и можно приступать к тестированию.