Перенос данных между различными конфигурациями 1С 7.7, 1С 8.1, 1С 8.2

Перенос данных между различными конфигурациями 1С 7.7, 1С 8.1, 1С 8.2

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

Введение

В данной статье речь пойдет об использовании конфигурации “Конвертация данных, редакция 1.0” (разработчик – фирма 1С). Будут описаны процессы формирования правил, приведены наиболее часто встречающиеся примеры переноса данных. В связи с достаточной мощностью механизмов, реализованных в конфигурации, ее использование может сэкономить массу времени при переносе данных. Автор не претендует на полноту изложения всех возможностей конфигурации. Кроме того, статья отражает личное мнение автора и не претендует на полноту освещения всех изложенных вопросов.

Обычно для переноса данных из одной конфигурации в другую использовались либо универсальные внешние обработки от “1С” (Выгрузка/Загрузка справочников), либо обработки сторонних производителей, либо каждый программист изобретал свою схему переноса данных.

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

Однако круг решаемых вопросов оставался практически одним и тем же:

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

     

  • Обеспечение “слияния” или “раздвоения” справочников по определенным признакам с сохранением иерархии и подчинения.

     

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

     

  • Обеспечение создания (обновления) документов и/или трансформация документов одного вида в документы другого вида (видов).

     

  • Перенос остатков и/или итогов на определенную дату.

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

“Конвертация данных” – это конфигурация, разработанная фирмой “1С” специально для решения проблем по переносу данных из одной конфигурации в другую. Согласно утверждениям “1С”, данный механизм призван унифицировать процесс переноса данных в произвольных конфигурациях, а также унифицировать формат файлов передаваемых данных.

Желания рассказывать о терминологии, составе и структуре конфигурации “Конвертация данных” у автора статьи нет, поскольку каждый, у кого есть ИТС, может со всем этим ознакомиться самостоятельно. Речь в статье пойдет о конкретных вопросах и об их решениях, найденных автором в процессе использования данной конфигурации.

Как начать работу

Самая большая проблема, с которой мне пришлось столкнуться, это собственно начало работы. Не совсем ясно, как начинать работу по формированию правил. Вот есть несколько практических советов:

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

     

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

     

  3. Если вы работаете с типовыми конфигурациями, измененными под клиента, то надо ориентироваться на наиболее близкие типовые конфигурации.

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

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

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

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

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

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

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

Правила переноса данных

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

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

Правила объектов

Правила объектов описывают переход данных в терминах объектов метаданных конфигураций 1С. По их списку можно в общем судить о том, какие объекты метаданных источника переходят в какие объекты метаданных приемника. Правило объекта имеет примерно следующий вид: элементы справочника “Номенклатура” переходят в элементы справочника “Товары”.

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

Параметры использования правил объектов

Параметр использования правил объектов определяет объем переносимой информации. Данный параметр может принимать два значения: выборка и по ссылкам. На самом деле это значение принципиально влияет на процесс.

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

Наложение условий для правил объектов

На применение того или иного правила объекта можно, при желании, наложить условие. Под условием понимается либо формализованный путем использования построителя условий набор ограничений, либо выполнение описанной пользователем функции. В том случае, если результатом проверки условия будет “ИСТИНА”, то правило выполнится, в противном случае правило будет проигнорировано. Если условие описано пользователем при помощи функции, то она должна возвращать единицу в случае необходимости обработки по правилу.

Преобразование объектов

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

Функция выборки объектов

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

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

Правила реквизитов

Правила реквизитов представляют из себя описание правил перехода реквизитов объекта-источника в реквизиты объекта(ов)-приемника. Соответственно, правила реквизитов нельзя рассматривать в отрыве от правил объектов. Если правила объектов описывают, что куда переходит, то правила реквизитов описывают, как объект-источник переходит в объект-приемник. Рассмотрим те возможности, которые предоставляет “Конвертация данных” для составления правил конвертации реквизитов.

Преобразование реквизитов

В правиле обработки реквизита можно непосредственно задать преобразование, совершаемое над реквизитом или объектом, к которому этот реквизит относится. Это означает, что значение, которое при загрузке примет реквизит-приемник, может не совпадать со значением реквизита-источника, а может быть получено, исходя из каких-то других реквизитов объекта-источника. Самое распространенное преобразование на моей памяти – дополнение кода справочника-источника до длины кода справочника-приемника.

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

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

Наложение условий для правил реквизитов

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

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

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

Правило конвертации

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

Способы выгрузки

Способы выгрузки описывают именно способы выгрузки ;-). Либо выгружаем, либо нет. Либо выгружаем историю периодических реквизитов, либо выгружаем актуальное значение. Для документов либо перебираем табличную часть, либо нет.

Способы загрузки

Особенно полезен режим “!!!Поиск”. Если использовать его, то при загрузке обработка пытается найти экземпляр объекта-приемника по совокупности выгруженных значений его реквизитов (тех, для которых установлен данный режим загрузки) и в случае неудачи создает новый экземпляр. Это дает почву для синхронизации объектов не только по коду или наименованию, но и по произвольному набору реквизитов, в т.ч. и агрегатного типа. Ряд других способов загрузки мною не использовался, но для задач по переносу данных “!!!Поиск” подходит в 90% случаев.

Использование скриптов

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

Если есть скрипты, то есть и исполняющая выгрузка, если вы сумели обойтись без них, то эта обработка вам и не нужна.

Параметры обмена

В правилах обмена прописываются такие характеристики, как перенос пометки удаления, статус документов (проведен/не проведен).

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

Конвертация значений

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

Перенос бухгалтерских остатков и операций

Для переноса операций необходимо три вещи: правило конвертации операций как документа, правило конвертации объекта метаданных вида “Операция”, а также конвертация значений для плана счетов вместе с сформированными правилами конвертации субконто для каждой строки таблицы конвертации плана счетов.

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

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

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

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

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

Источник: http://www.mista.ru/articles1c/hare/article.60.html