Сравнение и объединение правил обмена, регистрации
Имеется хорошо дописанная УТ и типовая БП. Стояли типовые (!) правила обмена. БП обновил до последней версии и теперь правила обмена необходимо корректировать, т.к. типовыми теперь обмен не проходит — разница в релизах конфигураций уже большая. Так подозреваю, что проще всего отладить правила с помощью конвертации данных через сравнение и объединение правил обмена.
Подскажите, пожалуйста, где и что почитать на эту тему чтобы закрыть пробел в данной области.
(3) Спасибо за ссылки. Материал изучил, но совершенно непонятен порядок действий при создании своих правил обмена и регистрации так, чтобы потом правильно происходил обмен.
Имеются типовые правила, выгруженные из конфигураций:
Если я правильно понимаю, то необходимо сравнить и объединить правила 2 и 3. Так? Или в том числе и правила 1 необходимо сравнивать и объединять с правилами, которые созданы для обмена с более новой версией БП?
Кто разбирается — ответьте, пожалуйста.
И так же стоит вопрос по литературе в данном вопросе.
Дело гиблое с документацией.
Есть 2 часовой курс от специалиста по обмену, в свободном доступе. В нем по тихой — работа с конвертацией.
(4) Конечно, можно сравнивать типовые правила 2 и 3. Цель — понять, какие изменения были внесены разработчиками.
Но обработка сравнения, объединения правил предназначена не только для того, чтобы выявить эти изменения, но и выполнить слияние СОБСТВЕННЫХ (модифицированных) правил с новыми правилами поставщика.
Поэтому, берем правила ДО обновления (Ваши модифицированные) и сравниваем их с НОВЫМИ правилами поставщика. Цель — перенести изменения разработчика в свои рабочие правила.
Если изменения вносились и в правила регистрации, то для слияния правил типовая конфигурация "1С:Конвертация данных" инструментов не содержит. Обработка сравнения, слияния правил регистрации здесь — http://o-systems.ru/software/soft/UnionRegistrationRules/
(9) (8) Ребята, благодарю за ответы.
У меня правила типовые и не измененные — мне в итоге в любом случае, чтобы получить результат нужно пользоваться сравнением и объединение правил обмена, правильно? Или это только необходимо при слиянии собственных правил с новыми правилами поставщика?
Если да, то как мне их сравнивать и объединять — последовательно релиз за релизом или сразу можно не смотря на большую разницу в релизах сравнивать и объединять то что было до обновления и текущий последний релиз правил?
Прочитал "Конвертация данных. Обмен данными между прикладными решениями — Бояркин В.Э, Филатов А.И", но ответа на свои вопросы не получил.
Мои наблюдения — обработка "Сравнение, объединение правил обмена" в конфигурации "Конвертация данных 2.1.8.2" работает очень КРИВО — как можно, сравнивая две только что загруженные одинаковые конвертации из одного файла в целях эксперимента, находить различия.
Да и сама конфигурация работает криво — приходится править некоторые моменты — один из них: при копировании элемента справочника конвертации — обрезает названия ПКО, ПВД в правилах до 45 символов. Сами 1С-ники создают правила с такими длинными названиями и сами же режут при копировании. Ну ладно не суть — это правится очень быстро.
Вопрос в другом — я так не нашел никакой информации по работе с обработкой "Сравнение и объединение правил обмена". Пробовал разобраться сам, но вопросов возникает больше, чем ответов.
1) Как проверить корректность созданных правил?
2) Как будучи в Конвертации данных понять, есть ли ошибки в правилах, а именно в сопоставлении реквизитов, свойств, значений?
3) Как все эти манипуляции делали раньше — без обработки "Сравнение, объединение правил обмена". Мне ведь всего то необходимо изменить типовые правила, т.к. пришлось обновить одну из конфигураций.
Люди, подскажите что знаете — можете?
P.S. может быть есть ресурсы, где люди обсуждают только "Конвертацию данных"?
Пробовал:
1) сравнивать и объединять старые правила с новыми правилами поставщика. получается каша, учитывая, что обработка сравнения работает криво. при загрузке этой каши в конфигурацию — понятное дело ругается на отсутствие реквизитов в шапке документов, либо в табличных частях. Не получилось. Понимаю, что делаю что-то неправильно.
2) пробовал брать новые правила обмена из последней конфигурации и изменять конфигурацию в них, с последующим закрытием ошибок на которые ругается 1С, когда пытаешься загрузить правила в 1С-ку (ошибки регистрируются в журнале регистраций). Но даже если закрыть все ошибки (поправить в правилах), где гарантия, что правильно работают запросы и прочее в правилах? ведь если на текущий момент нет документа к обмену, то и не запускается ПКО. А значит проверить сразу правила обмена в полном объеме не представляется возможным.
Какая должна быть процедура по корректировке типовых правил обмена под типовые конфигурации при обновлении одной из конфигураций?
1. Форма настройки правил обмена — Сервис — Проверка
2. См. п.1
3. Сравнивали XML, было очень неудобно. Первый раз тему сравнение, объединение правил обмена я поднял летом 2008 года https://partners.v8.1c.ru/forum/topic/598798. Через некоторое время появилась первая версия обработки сравнения.
Не совсем понятно, что означает "работает очень КРИВО". Да, в ней есть ошибки, но не настолько критичные. Различия могут быть например в кодах ПКС (для этого в настройке обработки можно выбрать способ сопоставления ПКС). Может отличаться порядок выполнения и другие свойства, которые автоматически назначаются при записи элементов правил (чтобы не выявлялись различия, нужно отключить эти реквизиты сравнения).
Да и вообще, вопросы по КД логичнее задавать на партнерском форуме https://partners.v8.1c.ru/forum/
(13) Спасибо за ответ!
Хорошо, что мне ответил сам разработчик. По поводу "работает очень КРИВО" — действительно, я погорячился, скорее всего по причине непонимания как работать с ней правильно.
Первая проблема с которой я столкнулся — это сравнивание копий одних и тех же правил. Обработка находила постоянные различия и даже после объединения — это повторялось. Но тут я понял, что частично проблема была в копировании обработки средствами конфигурации "Конвертация данных".
После того, как проблему исправил — всё равно путаница была при объединении ПКС (это видимо то о чем вы написали), но я пробовал переключать режим с "по коду" на "по наименованию" и обратно. Всё так же каждый раз находились различия для объединения. Я понимаю, что я что-то делаю неправильно.
Ещё момент — после объединения правил большая часть объектов в правилах красные и в том числе часть свойств красные и часть значений. При этом если вручную у этих свойств назначать реквизиты, то они перестают быть красными.
По поводу проверки правил в КД. Совершенно не могу понять, как ей пользоваться — данная проверка даже на типовые правила ругается.
Владислав, подскажите, пожалуйста, порядок работы с обработкой и вообще в каком порядке что делать. Я сейчас напишу, как я вижу, а Вы подкорректируйте, если есть возможность.
1)Загрузка правил из текущей УТ (необновленная, старая)
4)Сравнение и объединение правил БП (аналогичный вопрос)
5)Как быть с правилами регистраций? Правила регистраций остаются те же, что и должны быть для данных версий конфигураций?
6)Проверка правил. Какая процедура правильная?
Благодарю ещё раз за ответ, Владислав!
Механизм сопоставления данных при обмене через универсальный формат
Логично ожидать, что при синхронизации данных, как начальной, так и основанной на регулярной основе, одинаковые данные в приложениях будут сопоставлены между собой.
Для решения этой задачи как раз и предназначен механизм сопоставления данных.
В идеальном случае данные синхронизируемых приложений могли бы сопоставляться по уникальным внутренним идентификаторам объектов (GUID). Но для этого необходимо, чтобы добавление данных, подлежащих синхронизации, осуществлялся только в одном приложении, а в другом эти данные появлялись исключительно в результате синхронизации. В этом случае GUID в двух приложениях у одинаковых объектов будут одинаковыми, и по ним можно будет однозначно сопоставить объекты.
На практике соблюдать данное требование не всегда возможно, особенно в случае настройки синхронизации между приложениями, работа в которых велась независимо. Это связано с тем, что у двух одинаковых объектов, созданных параллельно в каждом приложении, будет два разных GUID.
В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).
Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ ). Структура регистра представлена в таблице:
ПланВидовХарактеристикСсылка,
ДокументСсылка
При получении данных записи в регистре могут появляться на нескольких этапах (см. рисунок 1). Подробное описание самих алгоритмов сопоставления см. далее.
Рисунок 1. Этапы, на которых могут быть сделаны записи в РПИ
Этапы, помеченные пунктиром, опциональные: при выполнении сеанса обмена в автоматическом режиме отсутствуют этапы 1 и 2, при выполнении в интерактивном режиме этап 2 может быть пропущен пользователем.
Записи в РПИ создаются и на стороне отправителя при подтверждении получения данных корреспондентом через механизм квитирования. В поле Идентификатор в таких записях устанавливается исходный идентификатор объекта. Регистрация таких записей необходима для того, чтобы при получении других данных от корреспондента можно было понимать, что данный объект должен быть исключен из процедуры поиска по полям и по уникальному идентификатору.
В процессе обмена данные РПИ обеспечивают следующую функциональность:
- Сопоставление объектов при получении данных (см. рисунок 2-а).
- Обработка получаемых данных (замена ссылок) с целью обеспечения ссылочной целостности (см. рисунок 2-b).
- Обработка отправляемых данных (замена ссылок) для исключения повторного сопоставления на стороне приложения-корреспондента уже сопоставленных данных (см. рисунок 2-b).
Рисунок 2. Использование данных РПИ при получении и при отправке данных.
Прикладная логика, определяющая порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных.
Все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки (подробнее в статье Методика работы с конфигурацией "Конвертация данных 3.0" ) формируют так называемый менеджер обмена . Код менеджера обмена разрабатывается в общем модуле (подробное описание см. в документации по БСП , в разделе Обмен через универсальный формат ). Модуль создается автоматически с помощью КД3.0 на основе настроенных правил обмена либо вручную в конфигураторе (см. пример — общий модуль _ДемоМенеджерОбменаЧерезУниверсальныйФормат демо-конфигурации БСП ).
Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО и может принимать одно из трех значений:
- ПоУникальномуИдентификатору — идентификация по GUID,
- СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска — идентификация по GUID и полям поиска,
- ПоПолямПоиска — идентификация по полям поиска,
Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.
Рисунок 3. Настройки идентификации в модуле менеджера и в КД3.0.
В таблице 1 представлено описание использования данных настроек при автоматическом сопоставлении на разных этапах получения данных:
Этап анализа данных (при загрузке через помощник синхронизации данных)
Ручное сопоставление (при загрузке через помощник синхронизации данных)
Идентификация по РПИ .
Идентификация по GUID.
Запись соответствий в РПИ: делается, если соответствие нашлось при выполнении п.3.
Запись соответствий в РПИ: делается по результатам сопоставления.
Идентификация по РПИ .
Идентификация по GUID среди объектов, отсутствующих в РПИ .
Запись соответствий в РПИ: делается для либо с исходным GUID, либо с вновь сгенерированным, п. 1 не дал результата но объект с таким GUID уже есть в РПИ .
Аналогично варианту "По GUID".
Идентификация по РПИ .
Идентификация по GUID.
Запись соответствий в РПИ: см. выше.
См. колонку "Загрузка данных"
Запись соответствий в РПИ: не делаются.
Таблица 1. Правила работы настроек идентификации.
Происходит последовательное применение вариантов поиска, заданных в свойстве ПоляПоиска ПКО, используемого при загрузке объекта.
Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска.
Переход к следующему варианту осуществляется в двух случаях:
- У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
- Вариант поиска не дал результата.
Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта "По GUID" или "По GUID и полям поиска", то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.
В остальных случаях поиск осуществляется среди всех объектов информационной базы соответствующего типа.
Особенность.
При сопоставлении на этапе анализа данных у загружаемых объектов не проверяется заполнение полей, участвующих в поиске.
Особенность.
На этапе анализа данных соответствие будет установлено только в том случае, когда для одного объекта отправителя был найден один объект получателя.
На этапе загрузки данных соответствие будет установлено и в том случае, когда для одного объекта отправителя нашлось несколько объектов получателя. В такой ситуации соответствие будет установлено с одним из них.
Особенность.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.
Лайфхаки конвертации данных 2.1 (часть 2)
Если в базе источника реквизит имеет тип «Строка», а в базе приемника тип «Справочник», то необходимо разработать отдельное правило конвертации объектов. Обязательно в правиле оставить Объект-источник пустым, иначе при выгрузке будет выдаваться ошибка. В конвертации объекта описать поля поиска, а также реквизит, в который будет грузиться значения реквизита объекта источника, и при необходимости описать заполнение остальных реквизитов справочника. В правиле в обработчике «Перед выгрузкой» реквизита написать следующий алгоритм (см. рисунок 1).
Рисунок 1 – Описание обработчика «Перед Выгрузкой».
Конвертация строки в перечисление
Если в базе источника реквизит имеет тип «Строка», а в базе приемника тип «Перечисление», то отдельное правило конвертации объектов разрабатывать не нужно, все действия описываются в конвертации свойств. Необходимо в обработчике «Перед выгрузкой» свойства описать алгоритм заполнения перечисления объекта приемника от значений реквизита объекта источника, то есть:
Конвертация справочника в строку
Если в базе источника реквизит имеет тип «Справочник», а в базе приемника тип «Строка», то отдельное правило конвертации объектов разрабатывать не нужно, все действия описываются в конвертации свойств. Необходимо в обработчике «Перед выгрузкой» свойства описать алгоритм заполнения реквизита объекта приемника от реквизита справочника объекта источника, то есть:
Конвертация перечисления в строку
Если в базе источника реквизит имеет тип «Перечисление», а в базе приемника тип «Строка», то отдельное правило конвертации объектов разрабатывать не нужно, все действия описываются в конвертации свойств. Необходимо в обработчике «Перед выгрузкой» свойства описать алгоритм заполнения реквизита объекта приемника от перечисления объекта источника, то есть:
Конвертация справочника в перечисление (перечисление в справочник)
Конвертация справочника в перечисление
Данная задача становится актуальной с учетом изменения перечисления «Ставки НДС» на справочник в новых конфигурациях. Теперь при конвертации объектов из новых конфигураций (тип: справочник) в конфигурации, где ставки НДС еще являются перечислением, необходимо будет разрабатывать соответствующее правило конвертации объектов.
1. Необходимо в правиле конвертации объектов на вкладке «Настройки», включить свойство «Не запоминать выгруженные объекты» (см. рисунок 2).
Рисунок 2 – Не запоминать выгруженные объекты.
Иначе система будет перезаписывать выгрузку одного и того же значения перечисления.
2. Не использовать конвертацию значений (предопределенные значения справочника в значения перечисления).
Будет использоваться обработчик «При выгрузке», а при использовании данного обработчика конвертация значений не отрабатывает.
3. В конвертации объекта в обработчике «При выгрузке» необходимо прописать следующий код:
То есть нам необходимо в переменную «УзелСсылки» присвоить значение метаданных перечисления, которое соответствует базе приемника, тогда система автоматически при загрузке определит нужное значение.
Конвертация перечисления в справочник
Для конвертации перечисления в справочник, потребуется отдельное правило конвертации объектов. В данном правиле можно воспользоваться конвертацией значений (конвертация значений перечисления в предопределенные значения), и необходимо описать поля поиска, а также реквизит, в который будет грузиться значение перечисления (например: реквизит — наименование), и при необходимости описать заполнение остальных реквизитов справочника. В правиле в обработчике «Перед выгрузкой» реквизита написать следующий алгоритм (см. рисунок 1).
Отключение проверки полей поиска
В созданных правилах конвертации объектов, по которым не заполнена колонка «Поля поиска» при сохранении правил, система предложит указать автоматически поля поиска (см. рисунок 3).
Рисунок 3 – Предупреждение – не указаны поля поиска.
При каждом сохранении правил, система будет выдавать данное сообщение. Если при достаточно большом количестве правил случайно нажать «Да», то система создаст поля поиска по всем правилам, и может потребоваться достаточно большое время восстанавливать обратно. Чтобы избежать таких неприятных ситуаций, данную проверку можно отключить (путь: Сервис – Настройки пользователя) (см. рисунок 4).
Рисунок 4 – Отключение проверки полей поиска.
Не регистрировать документы к обмену при определенных действиях
Документы регистрируются к обмену по правилам регистрации объектов при любых действиях (проведение, выполнение различных обработок и т.д.). Если необходимо не регистрировать документы при определенных действиях (например: при выполнении обработки по перепроведению документов), то можно использовать функционал дополнительные свойства.
В месте изменения документа, который не должен регистрироваться к обмену, нужно установить дополнительное свойство. В правилах регистрации объектов по документу в обработчике событий «После обработки» добавить:
В таком случае документ при групповом перепроведении не будет регистрироваться к обмену.
Общий алгоритм для всех объектов одного типа метаданных
Если необходимо учитывать один алгоритм для всех объектов одного типа метаданных (например: не выгружать помеченные на удаления справочники), то можно воспользоваться глобальными обработчиками, в них прописать один раз алгоритм, который будет действовать для всех существующих и новых объектов. Такой подход позволяет избежать дублирования кода и не забыть написать необходимый алгоритм для новых справочников.
Например, для задачи – не выгружать помеченные на удаления справочники, необходимо в глобальном обработчике «Перед выгрузкой объекта» написать следующий алгоритм:
Перенос субконто по своим правилам
У одного типа субконто могут присутствовать несколько правил выгрузки объекта, и система в таком случае будет по умолчанию выбирать одно определенное правила согласно приоритету и наименованию. Если же необходимо выгрузить субконто не по выбранному по умолчанию правилу, то можно воспользоваться следующим алгоритмом:
1. Для реквизита «Субконто» в обработчике «Перед выгрузкой»:
2. Перенос плана видов характеристик «Виды Субконто Хозрасчетные» (см. рисунок 5):
Рисунок 5 – Перенос плана видов характеристик.
3. Для реквизита «Субконто» в обработчике «При выгрузке»:
Описывается последовательность действий для каждого типа субконто.
Важный момент. Обязательно нужно прописать алгоритм выгрузки для каждого возможного типа субконто. После того, как добавлен код в обработчик «При выгрузке», типовое определение правила от типа субконто не срабатывает.
Поиск полей
Конвертация данных позволяет разрабатывать собственные алгоритмы поиска элементов на стороне приемника, для этого предназначен обработчик «Поля поиска».
В обработчике «Поля поиска» могут участвовать только те реквизиты, у которых установлен признак «Поиск» в конвертации свойств (см. рисунок 6). Данные реквизиты не обязательно должны участвовать в поиске нужного элемента, они могут присутствовать в различной другой логике алгоритма (например: в условиях алгоритма обработчика «Поля поиска»).
Рисунок 6 – Реквизиты доступные для обработчика «Поля поиска»
Пример обработчика «Поля поиска»:
В обработчике мы можем задать до 10 итераций через переменную «НомерВариантаПоиска». В каждой итерации в зависимости от условий задать поля поиска элемента через переменную «СтрокаИменСвойствПоиска» (наименование полей задаются, как они заданы у приемника). Получить значение поля поиска можно через структуру «СвойстваПоиска» (наименование полей задаются, как они заданы у приемника). Для прекращения поиска нужно использовать переменную «ПрекратитьПоиск».
Реквизиты узлов источника и приемника
В конвертации данных можно обращаться к реквизитам плана обмена. Это может быть необходимо, например, при тиражировании правил обмена на несколько баз и некоторые особенности функционала отличаются между базами (данные особенности будут учитываться с помощью реквизитов плана обмена).
На стороне источника, чтобы обратиться к узлу плана обмена, необходимо использовать переменную: «УзелДляОбмена».
Например, в правилах обмена на стороне источника можно обратиться к ИНН выбранной организации в плане обмена:
На стороне приемника, чтобы обратиться к узлу плана обмена, необходимо использовать переменную: «УзелОбменаЗагрузкаДанных».
Например, в правилах обмена на стороне приемника можно обратиться к ИНН выбранной организации в плане обмена:
Протокол (лог) синхронизации между базами
Важным элементом обмена между базами является протокол (лог) синхронизации. Данный протокол должен показывать в удобном виде всю необходимую информацию об обмене (количество выгруженных элементов; список выгруженных элементов; ошибки обмена и т.д.). Чем сложнее алгоритмы обмена, тем более расширенный должен быть лог (например: у нас несколько документов на стороне источника объединяются в один документ на стороне приемника, в таком случае протокол должен показывать, как документы объединялись). Лог должен содержать значимую информацию, которая оперативно поможет разобраться с вопросами связанными с синхронизацией.
Можно выделить три наиболее частых варианта создания протокола (лога) синхронизации между базами без кастомизации баз источника и приемника:
1) Записывать всю необходимую информацию в журнал регистрации. Данный подход имеет существенные недостатки. Чаще всего журнал регистрации имеет большой объем информации, это влияет на скорость анализа нужной информации (журнал регистрации может работать медленно), и предоставление данных в журнале регистрации не всегда удобно для анализа данных.
2) Отправлять все необходимые данные на электронную почту. После каждой синхронизации записывать данные в регистр сведений (ОтправкаEmail) для последующей отправки необходимым адресатам. В данном случае недостаток в том, что может возникнуть большое количество писем за день, и в них будет сложно проводить анализ.
3) Записывать всю необходимую информацию во внешний источник (файлы excel и т.д.). Данный подход является наиболее предпочтительный, т.к. можно создать 1 файл в день, в него дописывать всю нужную информацию за день в удобном виде для анализа.
Можно выбрать любой из данных подходов или кастомизировать базы источника и приемника для хранения лога в самих базах, но наличие подробного протокола (лога) может помочь во многих вопросах, связанных с синхронизацией между базами.
Передача параметра из источника в табличную часть приемника
При возникновении задач заполнения на стороне приемника в табличной части колонок, отсутствующих на стороне источника по данным колонок, которые отсутствуют на стороне приемника. Можно воспользоваться функционалом передачи значений отсутствующих колонок на стороне приемника в параметры табличной части и на основании этих данных заполнять нужную колонку.
Передача значений табличной части из источника в параметры табличной части приемника имеет ряд особенностей:
1. Необходимо в конвертации свойств табличной части приемника создать необходимый параметр. Если параметр имеет не примитивный тип, то указать также правило конвертации (см. рисунок 7).
Рисунок 7 – Создание параметра в конвертации свойств табличной части приемника.
2. Важный момент! Заполнение параметра должно всегда происходить в переменную «Значение» в обработчике «Перед выгрузкой». Из входящих данных параметр не сможет заполниться (будет выдаваться сообщение об ошибки) (см. рисунок 8).
Рисунок 8 – Заполнение параметра в конвертации свойств табличной части.
3. На стороне приемника обращение к параметрам табличной части происходит в обработчике «После загрузки» через соответствие «ПараметрыОбъекта» по следующему правилу:
если параметр был создан в табличной части, то обращение будет типа: [Наименование табличной части] + ТабличнаяЧасть (например: «ТоварыТабличнаяЧасть»);
если параметр был создан в наборе движений регистра, то обращение будет типа: [Наименование набора движений регистра] + Набор записей (например: «ХозрасчетныйНаборЗаписей»);
Например: 
Рассмотренные приемы работы позволят повысить производительность и эффективность работы с программой «Конвертация данных 2.1». Описанные приемы в данной статье и в первой статье затрагивают наиболее частые нетривиальные задачи использования конвертации данных, изучив обе статьи, подобные задачи уже не будут вызывать сложностей.