При работе с распределенными информационными базами (РИБ) в 1С:Розница 2.2 системные администраторы и программисты часто сталкиваются с ситуацией, когда вместо выгрузки только измененных данных система начинает отправлять в периферийную базу (ПБ) абсолютно все объекты. Даже если вручную очистить таблицу регистрации, при следующем сеансе обмена Центральная База (ЦБ) снова помечает тысячи документов и справочников к выгрузке. Рассмотрим детально, почему это происходит и как навести порядок в синхронизации данных.
Первое, что нам необходимо проверить — это механизм подтверждения получения данных, или так называемое квитирование. В РИБ каждое сообщение имеет номер. Когда ЦБ отправляет пакет №10, она ждет от ПБ подтверждения: "Я получила пакет №10". Пока это подтверждение не придет, ЦБ будет хранить в таблицах регистрации все изменения, вошедшие в этот пакет, и при следующей выгрузке (пакет №11) снова их отправит.
Проанализируем ситуацию на конкретном примере номеров сообщений:
Здесь мы видим явный разрыв в логике. Центральная база сообщает, что она успешно приняла 10-е сообщение от периферии. Однако периферийная база "считает", что последнее успешно принятое ею сообщение от центра — это №5. При этом ЦБ уже сформировала или пытается отправить №6. В такой ситуации ЦБ будет постоянно "догонять" разрыв, включая в каждое новое сообщение все данные, которые не были подтверждены (начиная с №5).
Для исправления ситуации можно попробовать программно выровнять номера сообщений. Рассмотрим пример кода, который поможет установить корректные номера в узле плана обмена:
// Пример для запуска во внешней обработке в Центральной Базе
УзелОбъект = ПланыОбмена.ПоМагазинам.НайтиПоКоду("КодВашегоУзла").ПолучитьОбъект();
// Если мы точно знаем, что ПБ приняла наше последнее сообщение (например, №6)
УзелОбъект.НомерПринятого = 10; // Номер сообщения, пришедшего ИЗ периферии
УзелОбъект.НомерОтправленного = 6; // Номер последнего отправленного сообщения
УзелОбъект.Записать();
В конфигурации "1С:Розница 2.2" используется сложный механизм регистрации, завязанный на Библиотеку Стандартных Подсистем (БСП). Одной из ключевых настроек является привязка узла к конкретному магазину. Разберем, как это влияет на обмен.
Если в настройках синхронизации в ЦБ для проблемного узла не выбраны магазины или склады, система может вести себя непредсказуемо. Правила регистрации объектов (ПРО) при отсутствии фильтра могут либо игнорировать объекты, либо, что чаще, регистрировать абсолютно все изменения справочников и документов, считая, что база должна "знать всё".
Проанализируем необходимые шаги для проверки настроек:
Для глубокой диагностики нам понадобится стандартная обработка "Регистрация изменений для обмена" (ее можно найти в составе БСП или через "Все функции" / "Функции для технического специалиста").
Разберем алгоритм работы с ней:
Часто в "Рознице" зацикливание происходит из-за пересчета цен или обработки заказов. Если в ЦБ постоянно меняются какие-то глобальные настройки, они могут инициировать перерегистрацию связанных документов по всей цепочке.
Если манипуляции с номерами сообщений и фильтрами не помогают, самым эффективным (хотя и трудозатратным) способом является пересоздание периферийного узла с новым идентификатором. Это позволяет "обнулить" все системные таблицы регистрации изменений (например, таблицу _ConfigChngRec), где могли накопиться ошибочные записи.
Выполним следующие действия по шагам:
Префикс для этой базы. Например, если был "М1", создайте "М2".Смена префикса критически важна, так как она создает новую уникальную запись в плане обмена. Это исключает влияние "хвостов" от старых настроек, которые могли блокировать очистку регистрации.
Если проблема сохраняется, проанализируем состояние базы данных на техническом уровне. Рассмотрим несколько профилактических мер:
1. Тестирование и исправление (ТиИ). Запустите конфигуратор ЦБ и выполните "Тестирование и исправление". Нас особенно интересует пункт Проверка логической целостности и Реиндексация таблиц. Поврежденные индексы в таблицах регистрации изменений часто становятся причиной того, что физически запись об удалении регистрации не срабатывает.
2. Очистка кэша. На стороне сервера 1С (или локально, если база файловая) необходимо очистить кэш. Бывают случаи, когда старые правила регистрации закэшировались и продолжают работать вопреки обновленным настройкам в интерфейсе.
3. Проверка динамических обновлений. Если вы часто выполняете "демонское" (динамическое) обновление конфигурации в ЦБ, это может привести к сбою в структуре планов обмена. Старайтесь выполнять обновления только в монопольном режиме, особенно если они затрагивают состав плана обмена или модули обмена данными.
Таким образом, мы выяснили, что циклическая регистрация в 1С:Розница 2.2 чаще всего вызвана либо разрывом в цепочке квитирования сообщений, либо отсутствием четких фильтров по магазинам в узле обмена. Использование нового префикса при пересоздании узла является наиболее надежным способом "вылечить" обмен, если стандартные методы очистки регистрации не дают результата.