Почему расширение в главном узле блокирует обмен РИБ, если оно не включено в состав обмена?

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

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

Суть проблемы и текст ошибки

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

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

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

Разбор механизма проверки идентичности структуры

Выясним причину такого поведения платформы. Основной принцип работы РИБ — это требование идентичности структуры таблиц базы данных во всех узлах. Это необходимо для корректной десериализации данных и работы механизмов регистрации изменений.

Когда мы добавляем в расширение объект (справочник, документ или регистр), платформа создает реальные физические таблицы в СУБД. С этого момента структура метаданных центрального узла меняется. Платформа 1С формирует определенную «контрольную сумму» (хеш) всех метаданных, которые влияют на структуру хранения.

Рассмотрим, что происходит в момент обмена:

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

Важно понимать различие: флаг Используется в РИБ отвечает исключительно за автоматическую транспортировку расширения. Если флаг снят, платформа просто не упакует расширение в файл обмена. Но она не игнорирует факт его наличия! Получается патовая ситуация: расширение нужно для идентичности структуры, но мы запретили его передачу.

Типы расширений: влияющие и не влияющие на структуру

Проанализируем ситуацию глубже. Не каждое расширение вызывает подобную проблему. Платформа разделяет их на две категории:

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

Если ваше расширение содержит только исправление логики проведения документа в МодулеОбъекта через &Вместо, то отсутствие такого расширения в подчиненном узле не вызовет ошибки обмена. Структура таблиц СУБД остается прежней. Но как только появляется новый РегистрСведений, требования к идентичности становятся жесткими.

Версионные особенности платформы (8.3.15+)

Начиная с версии 8.3.15, контроль целостности в РИБ был существенно усилен. В более ранних версиях платформы иногда удавалось совершать обмены, если добавленные объекты не были задействованы в миграции данных. В современных реалиях проверка происходит на этапе чтения заголовка сообщения. Это гарантирует, что база данных не будет повреждена попыткой загрузить данные в несовместимую структуру.

Варианты решения задачи

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

Вариант 1. Перенос объекта в основную конфигурацию

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

Алгоритм действий:

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

В этом случае таблицы будут существовать везде, что обеспечит идентичность структуры, но в подчиненных узлах они всегда будут оставаться пустыми.

Вариант 2. Использование расширения с передачей в РИБ

Если вы принципиально хотите использовать расширение, необходимо разрешить его передачу.

Пошаговая настройка:

1. В свойствах расширения установите флаг Используется в РИБ.
2. В свойствах Плана обмена установите флаг Включать расширения конфигурации.
3. После этого при очередном сеансе синхронизации расширение само прилетит в подчиненный узел и применится там.

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

Если НЕ ПланыОбмена.ПоМестуУстановки.ЭтоГлавныйУзел() Тогда
    Возврат;
КонецЕсли;

Вариант 3. Внешнее хранилище данных

Если вам критично не менять структуру подчиненных узлов (например, они очень большие или находятся на слабом оборудовании), рассмотрите возможность хранения «локальных» данных центра вне базы 1С. Для этих целей подойдут:

• Внешние файлы (JSON, XML, SQLite).
• Механизм ВнешниеИсточникиДанных для связи с другой базой SQL.

Резюме

Мы выяснили, что ошибка обмена РИБ при использовании расширений — это не баг, а защитный механизм платформы. Любое расширение, добавляющее физические таблицы (объекты или реквизиты), обязано присутствовать во всех узлах распределенной системы. Игнорирование этого правила через снятие флагов в плане обмена приводит к остановке синхронизации. Оптимальным выходом для создания «центральных» регистров остается их добавление в основную конфигурацию с исключением из состава плана обмена.