Как перенести данные независимого регистра сведений из УТ 11 в БП 3.0 при использовании КД 3.0?

При использовании технологии Конвертации данных 3.0 (КД 3.0) и формата Enterprise Data (ED) разработчики часто сталкиваются с жесткими ограничениями типизированных XDTO-пакетов. Если ваша задача — перенос данных из независимого РегистрСведений, который отсутствует в стандартном формате обмена, возникает дилемма: стоит ли модифицировать формат или искать обходные пути. Давайте разберем, какие стратегии существуют для решения этой задачи.

Почему стандартный подход через КД 3.0 вызывает сложности?

Технология КД 3.0 опирается на строгую структуру Enterprise Data. Изменение типового XDTO-пакета — это «красная зона» в разработке. Любая модификация схемы данных усложняет последующее обновление конфигураций и может привести к конфликтам при переходе на новые релизы БП 3.0. Поэтому, прежде чем приступать к доработке структуры пакетов, давайте рассмотрим альтернативные подходы, которые не требуют вмешательства в базовые механизмы обмена.

Вариант 1: Использование перепроведения документов (Логический подход)

Часто перенос записей регистра не является самоцелью. Если ваш независимый РегистрСведений хранит статусы, которые зависят от данных документа, попробуйте проанализировать, можно ли восстановить эти записи в приемнике автоматически.

Порядок действий:

1. Выгружаем только сам документ ПриобретениеТоваровИУслуг через штатный механизм КД 3.0.
2. В базе-приемнике (БП 3.0) настраиваем автоматическое проведение документов при загрузке.
3. В модуле объекта документа или через подписки на события реализуем алгоритм, который при проведении документа анализирует данные и самостоятельно формирует записи в нужный регистр.

Этот метод считается «чистым», так как данные регистра всегда будут актуальны относительно движений документа, а не перенесены «как есть» в статичном виде.

Вариант 2: Вынос обмена в отдельную процедуру (Интеграционный подход)

Если данные регистра независимы и не привязаны к движениям конкретных документов, попытка «впихнуть» их в Enterprise Data может быть неоправданно трудоемкой. В таких случаях мы рекомендуем реализовать отдельный, легковесный механизм обмена.

Рассмотрим шаги реализации:

• Создание отдельной обработки: Напишите внешнюю обработку или регламентное задание, которое будет работать параллельно с обменом КД 3.0.
• Выгрузка в JSON/XML: Сформируйте простой файл обмена или передайте данные напрямую через HTTP-сервис.
• Загрузка: На стороне БП 3.0 создайте процедуру, которая «разбирает» полученный файл и записывает данные в регистр сведений, используя объект РегистрСведенийЗапись или НаборЗаписей.

Этот подход позволяет избежать «раздувания» правил конвертации и делает систему обмена более гибкой и понятной в отладке. Ниже представлен пример кода, который можно использовать для записи в независимый регистр через МенеджерЗаписи:

// Пример записи в независимый регистр сведений
Запись = РегистрыСведений.ВашРегистрСведений.СоздатьМенеджерЗаписи();
Запись.Измерение1 = Объект1;
Запись.Измерение2 = Объект2;
Запись.Ресурс1 = Значение;
Запись.Записать();

Вариант 3: Использование внешних сервисов (HTTP или Web-сервисы)

Если базы находятся в одной сети или имеют доступ друг к другу, самым оперативным способом получения данных будет прямое обращение из БП 3.0 к УТ 11. Для этого мы можем создать HTTP-сервис в УТ 11, который будет отдавать текущие статусы по запросу.

Почему это удобно:

• Вы не меняете структуру обмена.
• БП 3.0 всегда получает максимально актуальные данные, а не «слепок» на момент обмена.
• Регламентное задание в БП 3.0 может запускаться с любой частотой (например, раз в час), не перегружая основной обмен Enterprise Data.

Анализ ситуации: стоит ли «колоть свинку»?

Проанализировав поставленную задачу, мы можем сделать вывод: если объем данных небольшой, а доработки конфигураций планируются в будущем, лучше избегать изменений XDTO-пакетов. Если вы решите использовать КД 3.0 «на полную», помните про Дополнительные сведения, которые можно передавать через обработчики событий ПриВыгрузке и ПриЗагрузке. Это сложнее в реализации, но позволяет передать произвольные данные внутри уже существующего сообщения без изменения схемы XDTO.

Подводя итог: для «простых» задач по переносу одного регистра лучше всего подойдет автономная загрузка/выгрузка или HTTP-сервисы. Это сэкономит ваше время на отладку правил и позволит сохранить конфигурацию в типовом состоянии, насколько это возможно.