При переходе со старых, зачастую сильно переписанных или отраслевых конфигураций на современную 1С:Бухгалтерию предприятия 3.0 (БП 3.0), разработчики часто сталкиваются с дилеммой: какой инструмент выбрать для разового или регулярного переноса данных? Современным стандартом обмена для 1С является формат EnterpriseData (ED). Однако старые базы не всегда поддерживают его "из коробки".
В этой статье мы подробно разберем, можно ли использовать Конвертацию данных 3.0 (КД 3.0) для работы с "древними" конфигурациями, как реализовать выгрузку в ED программно и какие нюансы нужно учитывать при работе в облачных сервисах (например, 1С:Фреш).
Прежде всего, нам необходимо уяснить фундаментальное различие между второй и третьей версиями конфигурации "Конвертация данных". Если КД 2.0 генерирует XML-файл правил, который интерпретируется универсальной обработкой, то КД 3.0 работает по принципу генерации программного кода. Результатом настройки в КД 3.0 является модуль менеджера обмена, который содержит алгоритмы преобразования данных в формат XDTO и обратно.
Рассмотрим, почему это важно для нашей задачи. Если мы планируем загружать данные в типовую БП 3.0, нам не нужно писать правила загрузки на стороне приемника — они там уже есть и работают с форматом EnterpriseData. Наша задача — заставить конфигурацию-источник "выплюнуть" XML в нужном формате.
Многие ошибочно полагают, что КД 3.0 подходит только для современных баз на БСП (Библиотеке стандартных подсистем). Проанализируем, так ли это на самом деле. На самом деле, конфигурацию КД 3.0 можно использовать для подготовки правил конвертации даже для баз с нестандартной структурой.
Пошаговый план действий в КД 3.0:
ВыгрузкаМетаданных.epf (идет в комплекте с КД 3.0) и загружаем её в базу КД.EnterpriseData нужной версии (например, 1.15). Эту схему можно взять с сайта ИТС или выгрузить из самой БП 3.0.EnterpriseData. Здесь мы настраиваем ПОД (Правила обработки данных) и ПКО (Правила конвертации объектов).Проблема "старой базы": Основная сложность заключается в том, что сгенерированный код КД 3.0 активно обращается к функциям БСП. Если в вашей старой базе БСП отсутствует или она очень древняя, этот код просто не запустится. В таком случае у нас есть два пути: либо вручную переписать вызовы общих модулей (например, заменить вызовы ОбщегоНазначения.ЗначениеРеквизитаОбъекта() на стандартные запросы), либо создать внешнюю обработку-контейнер, которая будет содержать в себе все необходимые "заглушки" и имитировать работу модулей обмена.
Если объем переносимых данных невелик (например, нужно перенести только справочники и пару видов документов), использование тяжеловесной КД 3.0 может быть избыточным. Рассмотрим альтернативу — написание выгрузки "руками" с использованием механизмов XDTO платформы 1С.
Проанализируем преимущества этого метода: вам не нужно внедрять в базу сложный код менеджера обмена, вы полностью контролируете процесс формирования файла. Для этого нам понадобится схема EnterpriseData (файл .xsd).
Пример логики формирования объекта через XDTO:
// Пример инициализации фабрики XDTO по схеме ED
ЧтениеСхемы = Новый ЧтениеXML;
ЧтениеСхемы.ОткрытьФайл(ПутьКФайлуСхемы);
ПостроительСхем = Новый ПостроительСхемXML;
Схема = ПостроительСхем.Создать(ЧтениеСхемы);
НаборСхем = Новый НаборСхемXML;
НаборСхем.Добавить(Схема);
МояФабрикаXDTO = Новый ФабрикаXDTO(НаборСхем);
// Создание объекта "Документ_РеализацияТоваровУслуг"
ТипОбъекта = МояФабрикаXDTO.Тип("http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.15", "Документ.РеализацияТоваровУслуг");
ОбъектED = МояФабрикаXDTO.Создать(ТипОбъекта);
ОбъектED.Номер = "00001";
ОбъектED.Дата = ТекущаяДата();
// Заполнение остальных реквизитов...
После заполнения объекта его остается только записать в файл XML. БП 3.0 примет такой файл через стандартную обработку "Загрузка данных из EnterpriseData", так как структура будет строго соответствовать ожидаемой схеме.
Выясним еще один эффективный сценарий, который часто используется при ограниченном бюджете и сжатых сроках. Если разработчик в совершенстве владеет КД 2.0, но не хочет тратить время на освоение КД 3.0 для "древней" базы, можно применить схему с промежуточным звеном.
КД 2.0 переносим данные из старой отраслевки в эту промежуточную базу. Это сделать легко, так как оба источника — обычные конфигурации 1С.БП 3.0 штатным механизмом синхронизации через EnterpriseData.Этот метод кажется более длинным, но он минимизирует риски ошибок в структуре XML, так как за формирование итогового файла ED отвечает типовой код 1С.
Разберем важный момент, затронутый в обсуждении: работу в облаке 1С:Фреш. В облачных сервисах действуют жесткие требования безопасности. КД 2.0 использует механизм "Выполнить()", который позволяет исполнять произвольный код, написанный в правилах обмена. В облаке это запрещено по соображениям безопасности.
В свою очередь, КД 3.0 генерирует обычный программный код, который проходит аудит при публикации расширения или конфигурации в облаке. Поэтому, если ваша БП 3.0 находится во Фреше, использование формата EnterpriseData — это практически единственный легальный способ загрузки данных извне без написания сложных API-интерфейсов.
Проанализируем, как упростить процесс отладки при использовании КД 3.0:
КД 3.0 — это код, вы можете ставить точки останова в модуле менеджера обмена и смотреть, какие значения принимают свойства объектов перед записью в XML. Это гораздо удобнее, чем отладка "черного ящика" в КД 2.0.1.16, а ваша БП 3.0 поддерживает только до 1.15, загрузка выдаст ошибку о несоответствии пространства имен.Выбор технологии зависит от ваших компетенций и сложности задачи. Если вы планируете долгосрочную поддержку обмена или работу с облаками — осваивайте КД 3.0. Несмотря на порог вхождения, она дает более стабильный и "чистый" результат. Если же вам нужно быстро перекинуть пару справочников один раз — используйте ручное формирование XDTO или промежуточную базу с привычной КД 2.0. Главное — обеспечить на выходе валидный файл EnterpriseData, который типовая бухгалтерия примет без лишних вопросов.