При автоматизации учета на предприятиях часто возникает классическая дилемма: основная управленческая деятельность ведется в старой, сильно кастомизированной базе на обычных формах (например, на базе 1С:Управление производственным предприятием 1.3 или старой самописной конфигурации), а регламентированный учет необходимо сдавать в актуальной и регулярно обновляемой 1С:Бухгалтерии предприятия 3.0 (БП 3.0). Встает сложная техническая задача: как организовать надежный, производительный и простой в поддержке двусторонний обмен данными между этими конфигурациями?
В этой статье мы подробно разберем, как решить эту задачу на практике. Мы проанализируем различные архитектурные подходы — от классических правил конвертации на базе КД 2.1 до современных веб-технологий (REST API, HTTP-сервисы) и универсального формата EnterpriseData (КД 3.0). Выясним все плюсы и минусы каждого метода, а также разберем готовые примеры кода для реализации интеграции.
---
Большинство специалистов по 1С «старой школы» отлично знают конфигурацию «Конвертация данных 2.1» (КД 2.1). Она позволяет создавать гибкие правила конвертации объектов (ПКО) и правил выгрузки данных (ПВД) в формате XML. Однако при попытке настроить двусторонний обмен с БП 3.0 разработчики сталкиваются с проблемой: в интерфейсе БП 3.0 механизмы прямой загрузки сторонних правил КД 2.1 скрыты или вырезаны, так как фирма «1С» активно продвигает формат EnterpriseData (КД 3.0).
Тем не менее, запустить полноценный двусторонний обмен по правилам КД 2.1 абсолютно реально. Рассмотрим два практических способа реализации.
Способ А. Использование встроенных механизмов БСП (Библиотека стандартных подсистем)
Конфигурация БП 3.0 разработана на базе БСП, в которой сохранен весь необходимый программный код для работы с планами обмена и правилами КД 2.1. Чтобы задействовать этот механизм, выполним следующие шаги:
ПланОбмена.Способ Б. Автоматизация обмена через обработку «Универсальный обмен данными в формате XML»
Если мы не хотим вносить изменения в конфигурацию БП 3.0 (оставляя её на замке для максимально простого обновления), мы можем автоматизировать обмен с помощью внешней обработки V8Exchan83.epf (версия для управляемых форм). Разберем по шагам, как запустить этот процесс программно.
Мы можем написать регламентное задание в БП 3.0 или запускать внешнюю обработку через планировщик задач операционной системы. Ниже приведен пример программного вызова обработки V8Exchan83.epf для автоматической выгрузки данных по правилам КД 2.1:
// Пример программного запуска обработки универсального обмена данными
ПутьКОбработке = "C:\Exchange\V8Exchan83.epf";
ОбработкаОбмена = ВнешниеОбработки.Создать(ПутьКОбработке, Ложь);
// Заполняем параметры выгрузки
ОбработкаОбмена.ИмяФайлаПравилОбмена = "C:\Exchange\Rules_From_BP_to_Custom.xml";
ОбработкаОбмена.ИмяФайлаДанных = "C:\Exchange\ExportData.xml";
ОбработкаОбмена.РежимОбмена = "Выгрузка";
ОбработкаОбмена.ЗаписыватьРегистрыВыбора = Истина;
// Настройка параметров правил (если они есть)
ПараметрыАлгоритмов = Новый Соответствие;
ОбработкаОбмена.ПараметрыНастройки = ПараметрыАлгоритмов;
// Выполнение выгрузки данных
Попытка
ОбработкаОбмена.ВыполнитьВыгрузку();
ЗаписьЖурналаРегистрации("Интеграция", УровеньЖурналаРегистрации.Информация, , , "Выгрузка данных успешно завершена.");
Исключение
ИнформацияОбОшибке = ОписаниеОшибки();
ЗаписьЖурналаРегистрации("Интеграция", УровеньЖурналаРегистрации.Ошибка, , , "Ошибка при выгрузке: " + ИнформацияОбОшибке);
КонецПопытки;
Аналогично настраивается и процедура загрузки на стороне БП 3.0. Для этого параметр РежимОбмена устанавливается в значение "Загрузка", указываются соответствующие пути к файлу данных, и вызывается метод ОбработкаОбмена.ВыполнитьЗагрузку(). Главным минусом этого подхода является необходимость ручной поддержки файлов правил XML при обновлении БП 3.0, так как структура метаданных бухгалтерии периодически меняется.
---
Если рассматривать разработку «на перспективу», то использование КД 3.0 является наиболее верным и поддерживаемым решением. КД 3.0 базируется на концепции единого универсального формата данных — EnterpriseData.
Давайте выясним, в чем главное преимущество этого подхода. При использовании КД 2.1 вам необходимо создавать правила конвертации «Напрямую» между базой А и базой Б. Если одна из баз обновляется, правила ломаются. В КД 3.0 интеграция строится иначе: база А выгружает данные в универсальный XML-формат по стандартной схеме XDTO, а база Б загружает эти данные из универсального формата в свои объекты.
Поскольку БП 3.0 — это типовая конфигурация, в ней уже встроены и постоянно обновляются разработчиками 1С все механизмы для работы с EnterpriseData. Вам не нужно писать правила выгрузки или загрузки для БП 3.0! Все, что вам нужно сделать, это настроить интеграцию со стороны вашей старой конфигурации.
Но что делать, если у вашей команды нет глубоких компетенций в КД 3.0 и XDTO-пакетах? Существует обходной путь:
ЗаписьXML формирует XML-файл, строго соответствующий схеме EnterpriseData (схема является открытой, ее описание легко найти в составе дистрибутивов или на ИТС).---
Если мы хотим полностью уйти от файлов обмена (XML, CSV, ZIP-архивов) и реализовать обмен в режиме реального времени (On-line), отличным современным решением станет использование встроенного REST API платформы 1С — интерфейса OData.
Этот интерфейс включается буквально в несколько кликов в конфигураторе БП 3.0 без изменения самой конфигурации. Платформа 1С автоматически генерирует HTTP-эндпоинты для всех справочников, документов и регистров базы данных.
Рассмотрим, как это применить на практике. Из нашей старой конфигурации (на обычных формах) мы можем напрямую отправлять HTTP-запросы в БП 3.0 для создания, изменения или чтения данных. Обмен происходит в легком формате JSON.
Проанализируем пример кода на стороне старой конфигурации для автоматического создания нового контрагента в базе БП 3.0 через OData:
// Настройка соединения с базой БП 3.0 через HTTP
Сервер = "192.168.1.100"; // IP-адрес или имя сервера БП 3.0
Порт = 80;
Пользователь = "ODataUser";
Пароль = "SecurePassword123";
Заголовки = Новый Соответствие;
Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
// Формируем тело запроса в формате JSON для создания контрагента
ТелоЗапроса = "{
| ""Наименование"": ""ООО Новые Технологии"",
| ""ИНН"": ""7701020304"",
| ""КПП"": ""770101001"",
| ""ЮридическоеФизическоеЛицо"": ""ЮридическоеЛицо""
|}";
HTTPСоединение = Новый HTTPСоединение(Сервер, Порт, Пользователь, Пароль);
HTTPЗапрос = Новый HTTPЗапрос("/BP3_Base/odata/standard.odata/Catalog_Контрагенты", Заголовки);
HTTPЗапрос.УстановитьТелоИзСтроки(ТелоЗапроса, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);
Попытка
HTTPОтвет = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
Если HTTPОтвет.КодСостояния = 201 Тогда
Сообщить("Контрагент успешно создан в БП 3.0 через REST API!");
Иначе
Сообщить("Ошибка создания. Код ответа сервера: " + HTTPОтвет.КодСостояния);
Сообщить("Ответ сервера: " + HTTPОтвет.ПолучитьТелоКакСтроку());
КонецЕсли;
Исключение
Сообщить("Не удалось установить соединение с сервером БП 3.0: " + ОписаниеОшибки());
КонецПопытки;
Использование REST API OData позволяет отказаться от промежуточных файлов обмена, планов обмена на стороне БП 3.0 и обеспечивает моментальное отражение хозяйственных операций в учетной системе бухгалтерии.
---
Иногда стандартный интерфейс OData кажется избыточным или небезопасным, так как он открывает доступ сразу ко всей структуре метаданных. В таких случаях рекомендуется использовать **HTTP-сервисы**, созданные вручную на стороне БП 3.0.
В отличие от классических, медленных и сложных в поддержке SOAP Web-сервисов, HTTP-сервисы работают по легковесному протоколу REST. Вы можете создать в БП 3.0 один HTTP-сервис с простыми методами (например, POST /create_doc для создания документов или GET /get_balance для получения взаиморасчетов). Старая база будет обращаться к этим методам, передавая компактные структуры данных в формате JSON. Это обеспечивает максимальное быстродействие и абсолютную безопасность, так как код обработки входящих данных полностью контролируется разработчиком 1С.
---
В процессе обсуждения интеграции часто всплывают старые проверенные методы, такие как COM-соединение (V83.COMConnector) и прямые SQL-запросы к базе данных. Проанализируем, почему от этих технологий в современных реалиях необходимо категорически отказаться.
ReadOnly) для анализа, но не для интеграционного обмена.---
Если ваши базы данных характеризуются высокой интенсивностью транзакций (сотни и тысячи документов в час), традиционные обмены файлами или синхронные HTTP-запросы могут приводить к зависаниям систем и блокировкам базы данных. В таких архитектурных сценариях рекомендуется использовать асинхронную интеграцию через брокеры сообщений (Message Brokers), такие как RabbitMQ или специализированное решение 1С:Шина.
Схема взаимодействия выглядит следующим образом:
---
Подводя итоги нашего глубокого анализа, сопоставим варианты интеграции в зависимости от требований проекта:
V8Exchan83.epf в БП 3.0 или через кастомный план обмена БСП. Но помните о затратах на поддержку правил при обновлениях БП 3.0.Выбирайте наиболее подходящий для вашей компании стек технологий, следуйте лучшим практикам разработки на платформе 1С:Предприятие 8.3, и ваша интеграция будет работать стабильно и эффективно!