При интеграции систем на базе устаревших платформ (например, 1С:Управление производственным предприятием) с современными решениями на базе Библиотеки стандартных подсистем (1С:Бухгалтерия предприятия 3.0) разработчики регулярно сталкиваются с дилеммой: использовать классическую технологию Конвертация данных 2.0 (КД 2.0) или переходить на современный формат EnterpriseData и Конвертацию данных 3.0 (КД 3.0). Ситуация усложняется, если обе конфигурации являются отраслевыми и содержат значительное количество нетиповых метаданных.
Разберем детально, достаточно ли возможностей КД 2.0 для решения этой задачи, с какими подводными камнями можно столкнуться при загрузке в БП 3.0 и в каких случаях внедрение КД 3.0 действительно оправдано.
Проанализируем архитектурные различия двух подходов применительно к связке УПП и БП 3.0:
Правила конвертации строятся по принципу прямого сопоставления метаданных «источник — приемник». Это проверенный временем инструмент, не требующий изменений в структуре конфигурации-источника (УПП). Достаточно стандартной обработки УниверсальныйОбменДаннымиXML. Главное преимущество в контексте отраслевых баз — легкая работа с добавленными документами, справочниками и регистрами. Если в обеих базах есть уникальные реквизиты и таблицы, в КД 2.0 они связываются напрямую в визуальном редакторе.
В КД 3.0 обмен строится через промежуточный формат — единую шину данных на основе XML-схем (XDTO). Каждая программа конвертирует свои объекты во внутренний формат EnterpriseData и обратно. Это дает гибкость при обновлении типовых баз, но создает огромные трудозатраты при наличии отраслевых реквизитов. Чтобы передать нетиповой реквизит или документ через КД 3.0, разработчику требуется вручную расширять XDTO-пакет, вносить изменения в правила обработки данных в обеих конфигурациях и переопределять модули менеджеров обмена через расширения.
Таким образом, для задачи обмена отраслевыми данными, где большинство передаваемых сущностей являются нетиповыми, КД 2.0 не просто достаточно — это наиболее рациональный и быстрый выбор. Внедрение КД 3.0 в УПП потребует либо серьезного переписывания конфигурации, либо подключения сторонних громоздких библиотек, а доработка схемы EnterpriseData под отраслевую специфику неоправданно увеличит бюджет интеграции.
Рассмотрим специфические технические моменты, которые необходимо учитывать при настройке загрузки по правилам КД 2.0 в конфигурацию БП 3.0, функционирующую на БСП:
В современных релизах БП 3.0 типовые планы обмена постепенно выводятся из эксплуатации или заблокированы в пользу EnterpriseData. Для реализации автоматической загрузки по расписанию внешнюю или встроенную обработку УниверсальныйОбменДаннымиXML регистрируют в подсистеме «Дополнительные отчеты и обработки» с назначением регламентного задания либо организуют запуск выгрузки/загрузки пакетным запуском через командную строку.
При вызове обработки через механизм дополнительных отчетов и обработок БСП по умолчанию включает безопасный режим. Если алгоритмы в обработчиках событий КД («После загрузки», «При загрузке») обращаются к файловой системе, сетевым ресурсам или используют привилегированный режим, загрузка завершится ошибкой. При регистрации обработки в БП 3.0 необходимо обязательно снимать флаг безопасного режима. Кроме того, помним, что в БП 3.0 код выполняется на сервере — любые клиентские интерактивные вызовы (открытие форм, предупреждения) приведут к аварийной остановке сеанса.
По умолчанию обработка загрузки XML устанавливает для всех записываемых объектов флаг ОбменДанными.Загрузка = Истина. Это отключает проверки заполнения и формирование движений в обработчиках проведения. Документы попадут в БП 3.0 непроведенными (либо проведенными формально, но без проводок в регистре бухгалтерии). Чтобы сформировать бухгалтерские проводки, разберем типовой прием: в правиле конвертации документа в событии ПослеЗагрузки можно выполнить программное проведение, предварительно сняв режим загрузки:
// Обработчик "После загрузки" в КД 2.0 для документа-приемника
Если Объект.Проведен Тогда
Объект.ОбменДанными.Загрузка = Ложь;
Попытка
Объект.Записать(РежимЗаписиДокумента.Проведение, РежимПроведенияДокумента.Неоперативный);
Исключение
ЗаписьЖурналаРегистрации("Ошибка проведения при обмене",
УровеньЖурналаРегистрации.Ошибка,
Объект.Метаданные(),
Объект.Ссылка,
ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
Если документов передается много, эффективнее загружать их в режиме обмена, а проведение выносить в отдельную регламентную процедуру группового перепроведения, чтобы не тормозить процесс трансляции данных.
В БП 3.0 проводки жестко завязаны на регистры сведений «Счета учета номенклатуры» и «Счета учета расчетов с контрагентами». В УПП логика счетов может отличаться. Поэтому в правилах КД 2.0 рекомендуется либо напрямую заполнять счета учета в табличных частях приемника, либо при загрузке программно вызывать типовые методы БП 3.0 для автоподстановки счетов.
Если использование внешних файлов обмена КД 2.0 по каким-либо причинам не подходит (например, требуется обмен в режиме реального времени онлайн), рассмотрим альтернативные решения:
В БП 3.0 публикуется собственный HTTP-сервис или задействуется стандартный интерфейс OData. Конфигурация УПП при проведении документов отправляет JSON- или XML-пакет напрямую в БП. Данный вариант изолирован от версий БСП и позволяет полностью контролировать транзакции и валидацию данных на стороне приемника.
Использование объекта V83.COMConnector для прямой записи объектов из УПП в БП 3.0. Метод прост в разработке, но чувствителен к несовпадению разрядности платформ (32/64 бит) и нестабильности локальной сети.
Вывод: Конвертации данных 2.0 более чем достаточно для создания надежного и управляемого обмена между нетиповыми УПП и БП 3.0. Она позволяет быстро связать отраслевые метаданные без модификации типовой конфигурации УПП и без сложного расширения схемы EnterpriseData.