← На главную

Часто перед разработчиками встает сложная задача: необходимо организовать двустороннюю синхронизацию данных (справочников и документов) между полностью самописной конфигурацией (или отраслевым решением) и типовой «Бухгалтерией предприятия 3.0». При этом ключевым условием является сохранение конфигурации-приемника (БП 3.0) на полной поддержке. Разберем ситуацию подробнее и выясним, как обойти встроенные ограничения платформы 1С и Библиотеки стандартных подсистем (БСП).

Суть проблемы: почему стандартный план обмена в расширении не работает

Если мы создадим новый план обмена, а также правила обмена и регистрации внутри расширения для БП 3.0, мы неминуемо столкнемся с техническим препятствием. Дело в том, что штатный модуль обмена данными (БСП) в типовой конфигурации использует регистры сведений (например, СоответствияОбъектовИнформационныхБаз или ПравилаОбменаДанными), измерения которых имеют составные типы, такие как ПланОбменаСсылка или ЛюбаяСсылка.

Из-за особенностей архитектуры 1С, эти составные типы в основной конфигурации «не видят» новые объекты метаданных, созданные исключительно внутри расширения. Как следствие, типовая подсистема обмена не может записать узел обмена в регистры, что вызывает множественные ошибки при попытке настроить синхронизацию. Рассмотрим несколько рабочих методов решения этой проблемы.

Решение 1: Заимствование типового плана обмена для правил КД 2.0

Если вы хотите остаться на привычных правилах обмена Конвертации данных 2.0 (КД 2), самым простым и надежным путем будет отказ от создания собственного плана обмена в расширении в пользу использования уже существующего в БП 3.0.

Проанализируем этот подход по шагам:

1. Выбираем подходящий типовой план обмена в БП 3.0, например ОбменУправлениеТорговлей103БухгалтерияПредприятия30.
2. Заимствуем этот план обмена в наше расширение.
3. В расширении добавляем в состав заимствованного плана обмена наши новые нетиповые документы или справочники (например, документ «Выставление услуг»). Включаем для них авторегистрацию или прописываем правила регистрации.
4. Пишем правила обмена в КД 2.0, где источником и приемником будут выступать как типовые объекты, так и объекты из расширения.
5. В пользовательском режиме настраиваем стандартную синхронизацию БП 3.0 — УТ 10.3 и подгружаем в нее свой файл с правилами обмена.

Преимущество: Так как узел обмена физически принадлежит основной конфигурации, БСП обрабатывает его штатно. Типы данных в регистрах сведений не конфликтуют с узлом, и обмен начинает работать.

Решение 2: Переход на Универсальный формат (EnterpriseData / КД 3.0)

Поскольку БСП активно развивается в сторону формата EnterpriseData, использование механизма Конвертации данных 3.0 является более перспективным и архитектурно правильным решением. При обмене через универсальный формат нет жесткой привязки к конкретным объектам метаданных в планах обмена.

Посмотрим на пример того, как это можно реализовать:

1. Настраиваем синхронизацию через формат EnterpriseData (для этого в БП 3.0 уже есть встроенные планы обмена, например СинхронизацияДанныхЧерезУниверсальныйФормат).
2. В расширении БП 3.0 перехватываем общий модуль МенеджерОбменаЧерезУниверсальныйФормат с помощью аннотаций &Вместо или &После.
3. В перехваченных процедурах переопределяем правила конвертации и маршрутизации.
4. Если в вашей опербазе есть специфичные реквизиты или документы, их можно передавать через стандартный блок дополнительных свойств (AdditionalInfo) в XML, либо использовать объекты формата Документ.УниверсальныйДокумент, если они предусмотрены используемой версией формата.

В этом случае типовое регламентное задание БП 3.0 само берет на себя всю работу по транспорту и фоновой загрузке сообщений.

Решение 3: Программная регистрация нового плана обмена в БСП

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

Разберем, что потребуется сделать в расширении:

1. Заимствовать общий модуль ОбменДаннымиПереопределяемый.
2. Создать расширяющий метод для процедуры инициализации планов обмена:
   Скопировать код

   
   &После("ПолучитьПланыОбмена")
   Процедура Расш_ПолучитьПланыОбмена(ПланыОбменаПодсистемы)
       ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.НашСобственныйПланИзРасширения);
   КонецПроцедуры
   

3. Заимствовать в расширение все ключевые регистры сведений БСП, отвечающие за синхронизацию (такие как СоответствияОбъектовИнформационныхБаз).
4. Дополнить типы измерений и ресурсов этих регистров в расширении, включив в них ПланОбменаСсылка.НашСобственныйПланИзРасширения и ссылки на новые документы.

Важный нюанс: при таком подходе также может понадобиться доработка команд синхронизации (заимствование общих команд и добавление их для нового плана обмена). Этот путь требует глубокого понимания внутренностей БСП, но позволяет создать полностью изолированный механизм обмена без модификации кода поставщика.