← На главную

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

Почему ломается обмен при откате на копию?

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

Вторая проблема — рассогласование GUID. Если за время с момента создания бэкапа до момента аварии в магазинах создавались новые справочники (номенклатура, дисконтные карты), то в восстановленной ЦБ их нет. При обмене могут возникнуть дубли или ошибки ссылочной целостности.

Шаг 1. Полная очистка и подготовка базы

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

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

Шаг 2. Пересоздание настроек синхронизации

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

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

Шаг 3. Устранение ошибок при создании начального образа

Часто при попытке штатного создания начального образа РИБ возникает ошибка. Разберем причины и способы их устранения:

Выясним причину ошибки через отладчик. Чаще всего проблема кроется в правилах регистрации данных. В «Рознице 2.2» правила регистрации могут быть доработаны или повреждены. Если используются типовые правила, попробуем выгрузить их из чистой конфигурации того же релиза и загрузить в нашу базу через справочник «Правила конвертации объектов».

Также проверим наличие кириллицы в путях временных папок. Процедура создания образа активно использует системный Temp. Попробуем переопределить переменные окружения пользователя на пути вида C:\Temp.

Шаг 4. Экспертный метод «ручного» создания узла (обход штатного механизма)

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

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

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

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

Шаг 5. Синхронизация номеров сообщений

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

В обоих узлах (ЦБ и Магазин) номера принятых и отправленных сообщений должны позволять системе принять пакет. Если магазин отправил сообщение №150, а центр после восстановления ждет №100, нужно в центре вручную установить номер принятого от этого узла сообщения как 149. Это делается через стандартную обработку «Регистрация изменений для обмена данными».

Шаг 6. Исправление «пустых» движений

В «Рознице 2.2» часто встречается проблема: документ в узел пришел, а движений по регистрам накопления нет. Рассмотрим, почему это происходит. Система использует фильтрацию по магазину. Если в документе реквизит Магазин заполнен некорректно или его нет в правилах регистрации для данного узла, движения не будут зарегистрированы.

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

Резюме и рекомендации

Для предотвращения подобных ситуаций в будущем, при работе с РИБ в «1С:Розница 2.2» придерживайтесь следующих правил:

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

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