При построении архитектуры обмена данными в крупном холдинге, где задействовано более 30 периферийных информационных баз (в данном случае 1С:Бухгалтерия предприятия 3.0) и одна центральная (1С:Управление холдингом), выбор технологии интеграции является критически важным решением. Основная дилемма заключается в использовании проверенной временем Конвертации данных 2.1 (КД 2.1), работающей через XML-правила, или современной Конвертации данных 3.0 (КД 3.0), основанной на универсальном формате EnterpriseData. Рассмотрим подробно оба варианта, проанализируем их преимущества, недостатки и выберем оптимальную стратегию развития.
Одной из ключевых сложностей в холдингах является «зоопарк» релизов или необходимость синхронного обновления всех узлов. Разберем ситуацию: представьте, что в типовой конфигурации переименовали реквизит (например, Склад стал МестоХранения). Проанализируем трудозатраты для обеих технологий:
xml), загрузить их в каждую базу и протестировать. Сопровождение становится дорогим и трудоемким.Многие разработчики опасаются КД 3.0 из-за кажущейся жесткости формата EnterpriseData. Однако выясним, как решается задача передачи нетиповых данных. Выделим два основных пути:
Использование AdditionalInfo (Дополнительные данные). Рассмотрим этот механизм как самый простой способ передать специфические реквизиты, такие как ваши Ссылка_локальная или Ссылка_общая, без изменения структуры XDTO-пакета. Это свойство есть практически у каждого объекта в формате EnterpriseData. Мы можем упаковать туда любые данные в виде структуры или XML-строки и разобрать их на стороне приемника в процедуре ПослеЗагрузкиОбъекта.
Доработка XDTO-пакета. Если планируется масштабное расширение состава передаваемых данных, создадим собственный XDTO-пакет на основе типового EnterpriseData. Посмотрим на алгоритм действий:
Такой подход делает КД 3.0 практически такой же гибкой, как и КД 2.1, но сохраняет преимущество типизации.
Проанализируем технические преимущества КД 3.0, которые критичны для централизации НСИ в 1С:Управление холдингом:
В вашем кейсе есть задача «Натурального меппинга» для статей ДДС. Посмотрим, как это реализовать в рамках КД 3.0. При согласовании заявки в УХ заполняются два реквизита. Чтобы передать нужное значение в типовой реквизит СтатьяДДС в БП 3.0, воспользуемся алгоритмом в модуле менеджера обмена.
Пример логики в процедуре выгрузки:
Процедура ПКО_Документ_ПлатежноеПоручение_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Передаем значение из нашего самодельного справочника ДДС_БУХ
// в стандартное поле формата СтатьяДвиженияДенежныхСредств
Если ЗначениеЗаполнено(ДанныеИБ.СтатьяДДС_БУХ) Тогда
ДанныеXDTO.СтатьяДвиженияДенежныхСредств = СформироватьСсылкуВФорматеEnterpriseData(ДанныеИБ.СтатьяДДС_БУХ);
КонецЕсли;
КонецПроцедуры
Рассмотрим альтернативную стратегию, предложенную опытными архитекторами. Чтобы минимизировать риски при обновлении 30 баз, можно реализовать следующую схему:
Это позволяет полностью изолировать логику бизнес-процессов от процесса доставки данных. Если в БП 3.0 изменится логика проведения документа, вам нужно будет поправить только одну локальную обработку «Генератор документов», не трогая правила обмена.
Для проекта с 1С:Управление холдингом и 30 узлами БП 3.0 наиболее разумным выбором является КД 3.0 (EnterpriseData). Выясним основные причины для финального обоснования перед заказчиком:
Таким образом, мы рекомендуем использовать КД 3.0, а специфические реквизиты для однозначной идентификации (Ссылка общая) передавать через расширение типового XDTO-пакета или свойство AdditionalInfo. Это обеспечит стабильность обмена и легкость будущих обновлений конфигураций.