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

← На главную

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

Рассмотрим подробно причины возникновения такой ситуации и разберем по шагам варианты устранения неисправности.

Причина 1. Принудительное игнорирование записи в БСП и некорректные настройки узла

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

Чаще всего это происходит по следующим причинам:

Слетела привязка магазина в плане обмена. Нам необходимо проверить табличную часть узла обмена как в ЦБ, так и в подчиненной базе. Если поле магазина оказалось пустым, типовые алгоритмы отфильтруют поступающие данные.
Несоответствие кода узла и настроек в XML. В 1С:Розница настройки узла хранятся в служебной константе НастройкиПодчиненногоУзлаРИБ. В этой константе содержится XML-структура с параметрами магазина, складов и кодом узла. Если код узла в XML не совпадает с кодом текущего узла в плане обмена (например, в XML указан код 03, а фактический код узла 89), механизм обмена считает данные предназначенными для другой базы и игнорирует их.

Для устранения проблемы с настройками узла проанализируем и исправим содержимое XML-структуры константы в подчиненном узле:


// Пример перезаписи служебных настроек подчиненного узла
НастройкиXML = Константы.НастройкиПодчиненногоУзлаРИБ.Получить().Получить();
// Проверяем соответствие кодов и идентификаторов магазина
// После корректировки XML записываем значение обратно:
Константы.НастройкиПодчиненногоУзлаРИБ.Установить(Новый ХранилищеЗначения(ОбновленнаяXMLСтрока));

Причина 2. Рассогласование номеров принятых и отправленных сообщений

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

Рассмотрим способы исправления номеров сообщений:

Вариант А. Корректировка номеров вручную

Выясним номер последнего выгруженного сообщения. В базе-источнике (ЦБ) установим номер отправляемого сообщения больше текущего (например, 350), а в базе-приемнике (подчиненном узле) установим номер принятого сообщения на единицу меньше (например, 349).

Вариант Б. Полный сброс номеров сообщений

Выполним обнуление номеров сообщений в обоих узлах с помощью программного кода или стандартной обработки сброса номеров:


УзелОбмена = ПланыОбмена.ПоМагазину.НайтиПоКоду("89").ПолучитьОбъект();
УзелОбмена.НомерОтправленного = 0;
УзелОбмена.НомерПринятого = 0;
УзелОбмена.Записать();

После обнуления номеров в ЦБ и подчиненном узле выполним повторную регистрацию необходимых объектов и запустим обмен.

Причина 3. Рассогласование идентификаторов объектов метаданных

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

Для исправления проанализируем состояние идентификаторов и выполним их обновление в обеих базах. Запустим сеанс 1С с параметром командной строки:

/C ОбновитьИдентификаторыОбъектовМетаданных

Также можно вызвать обновление программно через процедуры БСП:

Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();

Причина 4. Кэширование сеансов после создания начального образа

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

Альтернативный вариант: Создание подчиненного узла из копии ЦБ

Если стандартный механизм создания начального образа из-за сбоя жестких фильтров БСП продолжает игнорировать данные, применим альтернативный способ разворачивания подчиненного узла:

Создадим полную копию центральной информационной базы.
В созданной копии программно отвяжем главный узел с помощью команды: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Удалим лишние узлы из плана обмена, оставив только текущий узел и центральный.

Укажем центральный узел в качестве главного:


ГлавныйУзел = ПланыОбмена.ПоМагазину.НайтиПоКоду("ЦБ");
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);

Очистим непрофильные данные магазина и выполним повторный запуск синхронизации.