Почему в 1С:Розница не передаются изменения конфигурации через РИБ после обновления платформы?

← На главную

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

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

Выясним причину: регрессионный баг платформы 8.3.13

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

Система «считает», что изменений в структуре конфигурации нет, и поэтому при выгрузке сообщения обмена (.xml файла) узел-источник просто не включает в него блок обновления конфигурации. При этом программный код и данные могут передаваться исправно, что создает иллюзию работающего обмена, пока не потребуется изменение метаданных (добавление реквизитов, новых справочников или документов).

Влияние расширений и режима совместимости

Рассмотрим подробнее дополнительные факторы, которые могут усугублять ситуацию:

Модернизация расширений: В линейке 8.3.13 появилась глубокая интеграция расширений с механизмом РИБ. Механизмы «старого» обмена (основной конфигурацией) и «нового» (расширениями) в первых сборках этой платформы конфликтовали между собой. Если в базе используются расширения, меняющие структуру данных, это могло полностью заблокировать передачу основной конфигурации.
Режим совместимости: Если конфигурация «Розница» переводится на новый режим совместимости, соответствующий 8.3.13, без предварительного обновления платформы на всех узлах, возникают сбои в правилах хэширования метаданных. Узел-приемник в таком случае не может корректно распознать пришедшие изменения.

Решение 1: Обновление платформы до исправленной версии

Самый простой и надежный способ — это установка исправленного релиза. Практика показывает, что начиная с версии 8.3.13.1644, ошибка с передачей конфигурации была устранена разработчиками 1С.

Разберем алгоритм действий:

Установите платформу версии 8.3.13.1644 (или более позднюю из веток 8.3.14, 8.3.15 и т.д.) на главном узле.
Выполните аналогичное обновление на всех периферийных узлах. Важно, чтобы версии платформы в рамках РИБ совпадали для корректной работы механизмов сериализации.
После обновления запустите базу в режиме Конфигуратор, внесите любое незначительное изменение (например, добавьте пробел в комментарий любого общего модуля) и сохраните конфигурацию. Это принудительно инициирует механизм регистрации изменений.
Выполните синхронизацию данных.

Решение 2: Откат на стабильную ветку 8.3.12

Если требования вашей конфигурации (например, 1С:Бухгалтерия или 1С:УНФ) позволяют использовать более ранние версии, мы рекомендуем рассмотреть переход на ветку 8.3.12. Сборка 8.3.12.1714 или 8.3.12.1790 зарекомендовала себя как наиболее стабильная для работы распределенных баз в тот период.

Обратите внимание: если вы уже успели изменить режим совместимости конфигурации на 8.3.13, простой даунгрейд платформы может не сработать. В этом случае придется сначала вернуть режим совместимости в конфигураторе под управлением 8.3.13, и только затем запускать базу на 8.3.12.

Решение 3: Принудительная ручная регистрация изменений

Если обновление платформы временно невозможно, проанализируем способ принудительной регистрации объекта конфигурации для узла. Для этого можно воспользоваться встроенной обработкой «Регистрация изменений для обмена данными».

Посмотрим на программный метод, который позволяет зарегистрировать изменения конфигурации для конкретного узла через код:


// Выберем узел, для которого нужно зарегистрировать изменения
УзелОбмена = ПланыОбмена.Розница.НайтиПоКоду("ПФ1"); 

Если Не УзелОбмена.Пустая() Тогда
    // Регистрируем изменения всей конфигурации для узла
    ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, Метаданные.Конфигурация);
    Сообщить("Изменения конфигурации зарегистрированы принудительно.");
КонецЕсли;

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

Решение 4: Ручное обновление периферийного узла через файл .cf

В ситуациях, когда РИБ окончательно «сломался» и не передает метаданные, используем проверенный административный метод:

В главном узле в режиме Конфигуратор выполним команду Конфигурация -> Сохранить конфигурацию в файл... (получаем файл 1cv8.cf).
В периферийном узле запустим Конфигуратор.
Для возможности внесения изменений может потребоваться временно «отвязать» узел от главного. Рассмотрим команду: ПланыОбмена.УстановитьГлавныйУзел(Неопределено); (выполняется в обработке).
Загружаем полученный файл через Конфигурация -> Загрузить конфигурацию из файла....
Снова устанавливаем главный узел: ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);.
Важный момент: номера сообщений обмена в главном и подчиненном узлах должны быть выровнены. После ручного обновления обязательно проверьте, чтобы номер принятого сообщения в периферии соответствовал номеру отправленного из центра, иначе обмен выдаст ошибку.