Как включить регистр сведений из одного расширения в состав плана обмена из другого расширения?

В процессе сопровождения типовых конфигураций (например, УТ 11, ERP или КА) часто возникает ситуация, когда разные разработчики создают свои расширения для решения специфических задач. Со временем эти доработки начинают пересекаться. Рассмотрим типичную проблему: в Расширении 1 создан ПланОбмена, а в Расширении 2 — новый РегистрСведений. Перед разработчиком встает задача: как включить этот регистр в состав уже существующего плана обмена, чтобы изменения данных мигрировали в другие системы, в том числе через обмены через брокеры?

Проанализируем ситуацию и выясним, почему стандартными средствами платформы 1С это сделать невозможно, и какие существуют пути решения данной архитектурной задачи.

Разберем техническое ограничение платформы

Первое, что нам необходимо усвоить: в платформе 1С:Предприятие 8.3 расширения имеют строгую иерархию видимости. Любое расширение «видит» объекты основной конфигурации и может их заимствовать или расширять. Однако расширения практически не «видят» объекты, созданные в других расширениях, когда речь идет о настойке метаданных через визуальные редакторы.

Посмотрим на причины, почему ПланОбмена из одного расширения не может содержать в своем составе РегистрСведений из другого:

1. Изоляция метаданных: Визуальный конструктор состава плана обмена в Расширении 1 просто не покажет в списке доступных объектов те метаданные, которые физически отсутствуют в основной конфигурации или в этом же расширении.
2. Отсутствие перекрестных ссылок: Даже если настроить зависимости между расширениями, платформа не позволяет «дополнять» состав объекта метаданных (такого как план обмена), если сам этот объект был создан в другом расширении.
3. Порядок применения: Платформа применяет расширения последовательно. Если Расширение 1 применится раньше Расширения 2, то в момент его инициализации объекта из второго расширения еще «не существует» в контексте базы данных.

Решение №1: Объединение расширений

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

Проанализируем шаги по объединению:

1. Выгрузим оба расширения в файлы конфигурации (.cfe).
2. Выберем одно расширение в качестве основного (например, то, где больше объектов).
3. Выполним операцию Сравнить и объединить с конфигурацией из файла, выбрав файл второго расширения.
4. После объединения РегистрСведений и ПланОбмена окажутся в одном расширении.

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

Решение №2: Использование основной конфигурации

Рассмотрим более фундаментальный подход. Опытные разработчики часто придерживаются правила: если объект (справочник, документ, регистр или план обмена) является ключевым для бизнес-логики и должен хранить данные длительное время, его лучше создавать в основной конфигурации.

Многие опасаются снимать конфигурацию с поддержки, боясь замедления обновлений. Разберем, почему это заблуждение:

Для добавления новых объектов не нужно полностью снимать конфигурацию с поддержки. Достаточно перевести ее в режим «Объект поставщика редактируется с сохранением поддержки». Это позволяет:

• Добавлять новые собственные объекты (планы обмена, регистры).
• Использовать стандартные механизмы сравнения и объединения при обновлении (трехстороннее объединение).
• Обеспечить максимальную сохранность данных. Данные в расширениях могут быть безвозвратно удалены платформой при случайном удалении самого расширения или изменении его уникального идентификатора.

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

Решение №3: Программная регистрация изменений через подписки

Если по каким-то причинам мы не можем объединить расширения или менять основную конфигурацию (например, расширения поставляются разными вендорами), воспользуемся программным методом. Выясним, как это реализовать.

В Расширении 2, где находится наш РегистрСведений, мы можем создать объект ПодпискаНаСобытие. В качестве источника выберем наш регистр, а в качестве события — ПриЗаписи. Для управления такими процессами удобно использовать массовый редактор событий. Однако здесь есть важный нюанс: чтобы эта подписка могла обратиться к плану обмена из Расширения 1, нам придется использовать механизмы, обходящие жесткую типизацию, или вызывать общий модуль.

Пример логики в обработчике подписки:

Процедура ПриЗаписиРегистраДляОбмена(Источник, Отказ, Замещение) Экспорт
    
    // Определяем узлы, для которых нужно зарегистрировать изменения
    // ПланОбменаОбъект может быть недоступен напрямую, если он в другом расширении
    // Поэтому используем универсальные методы или поиск по имени
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Ссылка
        |ИЗ
        |   ПланОбмена.НашПланОбменаИзРасширения1 КАК План";
    
    Выборка = Запрос.Выполнить().Выбрать();
    
    Пока Выборка.Следующий() Цикл
        // Программная регистрация изменений
        ПланыОбмена.ЗарегистрироватьИзменения(Выборка.Ссылка, Источник);
    КонецЦикла;
    
КонецПроцедуры

Важное предостережение: Данный метод сработает только в том случае, если платформа позволит выполнить запрос к таблице плана обмена из другого расширения в контексте выполнения кода. Часто для корректной работы такой связки требуется, чтобы ПланОбмена все же находился в основной конфигурации.

Почему не стоит злоупотреблять расширениями для хранения данных?

Проанализируем риски, о которых часто забывают при активном использовании расширений:

1. Распределенные информационные базы (РИБ): Если ваша система использует РИБ, помните — объекты расширений не участвуют в стандартном обмене данными между узлами автоматически. Вам придется вручную описывать логику их передачи, что крайне трудозатратно.
2. Риск потери данных: Если администратор базы данных случайно удалит расширение из списка, платформа немедленно удалит все таблицы этого расширения в СУБД вместе с данными. Восстановить их можно будет только из бэкапа.
3. Производительность: Большое количество расширений (более 10-15) может начать сказываться на скорости запуска сеанса и общей производительности системы из-за сложности сборки конфигурации.

Итоговые рекомендации

Подведем итог нашему анализу. Если вы столкнулись с невозможностью включить объект из одного расширения в состав плана обмена другого, рекомендуем следующий порядок действий:

1. Оцените возможность объединения: Если это ваши собственные доработки — объедините расширения. Это самый «чистый» способ с точки зрения архитектуры 1С.
2. Рассмотрите перенос в основную конфигурацию: Если план обмена и регистр являются важными частями системы, включите возможность изменения в основной конфигурации и создайте их там. Это упростит поддержку и гарантирует сохранность данных.
3. Используйте расширения по назначению: Помните, что расширения идеально подходят для исправления ошибок (патчей), изменения поведения существующих форм или добавления временных отчетов, но не для проектирования сложных взаимосвязанных структур данных.

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