Как восстановить обмен в РИБ, если центральная база была утеряна и восстановлена из старого бэкапа?

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

Этап 1: Подготовка к восстановлению

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

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

Этап 2: Синхронизация номеров сообщений

Обмен данными в системе РИБ жестко контролируется номерами пакетов. В каждом узле фиксируется номер последнего принятого (ReceivedNo) и отправленного (MessageNo) сообщения. Если после восстановления базы номера в центре окажутся меньше, чем в дочерних узлах, система безопасности платформы заблокирует обмен, считая его устаревшим.

Для решения этой проблемы мы рекомендуем выполнить следующие действия:

1. В головной базе откройте форму настроек узлов обмена.
2. Для каждого дочернего узла принудительно обновите номера сообщений.
3. Если ручная правка невозможна стандартными средствами, воспользуйтесь универсальным редактором реквизитов.
4. Самый простой и надежный способ — сбросить номера в 0 как в головной, так и в дочерних базах. Это вынудит систему пересчитать актуальность данных заново.

Этап 3: Регистрация изменений для повторной передачи

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

Разберем, как это реализовать:

• В дочерних узлах воспользуйтесь встроенными обработками для регистрации изменений.
• Выберите нужный ПланОбмена и конкретный узел центральной базы.
• Массово зарегистрируйте объекты, которые должны «улететь» в головную базу: ЧекиККМ, ПеремещенияТоваров, АктыРасхождения и другие.

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

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

Этап 4: Выполнение обмена и финальная проверка

После того как вы настроили номера и зарегистрировали изменения, приступайте к обмену:

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

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

Если в процессе возникают конфликты GUID (уникальных идентификаторов ссылочных объектов), проверьте, не был ли создан дочерний узел «с нуля» при восстановлении. В РИБ критически важно, чтобы идентификаторы узлов в плане обмена совпадали с теми, что были до сбоя. Если вы восстанавливали узел из копии, убедитесь, что GUID остался прежним.

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