Как изменить номера сообщений в плане обмена 1С при рассинхронизации в РИБ?

← На главную

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

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

Разберем теорию: как 1С контролирует номера сообщений

Для каждого узла в плане обмена система хранит два ключевых параметра, которые определяют порядок прохождения данных:

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

Выясним причину ошибки: если вы создали новый образ периферийной базы, её счетчики обнулились. Она отправляет сообщение №1. Но центральная база помнит, что до поломки она уже приняла сообщение №500. Увидев единицу, она отвергает пакет. Наша задача — синхронизировать эти значения.

Способ 1. Изменение номеров через стандартный интерфейс (Обычные формы)

В старых конфигурациях, таких как "Бухгалтерия предприятия 1.6" или "Управление производственным предприятием 1.3", доступ к номерам сообщений можно получить напрямую через список планов обмена. Рассмотрим, как это сделать:

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

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

Способ 2. Использование обработки "Регистрация изменений для обмена"

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

Во многих современных конфигурациях эта обработка встроена. В интерфейсе её можно найти через "Все функции" (или "Функции для технического специалиста") — "Обработки" — "Регистрация изменений для обмена".

Запустим обработку и выберем нужный узел плана обмена.
В верхней части формы или в меню команд обычно присутствует кнопка "Изменить номера сообщений".
В появившемся диалоговом окне установим значения. Например, если центральная база ждет сообщение №501, нам нужно в периферийной базе в поле Номер отправленного поставить 500. Тогда следующая выгрузка получит номер 501 и будет принята.
Нажмем "ОК" или "Записать", чтобы изменения вступили в силу.

Если в вашей конфигурации нет встроенной обработки, её можно найти на диске ИТС или в составе дополнительных инструментов разработчика. Она является универсальным средством для диагностики проблем РИБ.

Способ 3. Программное изменение номеров сообщений

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

Рассмотрим пример кода для изменения номеров:


// Выбираем конкретный план обмена и находим нужный узел по коду
УзелОбъект = ПланыОбмена.Полный.НайтиПоКоду("ПБ").ПолучитьОбъект();

// Устанавливаем новые значения счетчиков
// НомерОтправленного - то, что мы будем отправлять в следующий раз (+1)
УзелОбъект.НомерОтправленного = 500; 

// НомерПринятого - то, что мы якобы уже успешно получили от партнера
УзелОбъект.НомерПринятого = 320;

// Обязательно записываем объект для фиксации изменений в базе
УзелОбъект.Записать();

Сообщить("Номера сообщений успешно обновлены для узла: " + УзелОбъект.Наименование);

В данном примере ПланыОбмена.Полный — это имя вашего плана обмена в метаданных. Замените его на актуальное. Метод НайтиПоКоду("ПБ") ищет периферийный узел с кодом "ПБ".

Последствия ручного изменения номеров и восстановление данных

Проанализируем риски. Просто изменить номера — это только половина дела. Важно понимать, что происходит с данными:

Квитирование (подтверждение): Когда 1С получает сообщение с номером 501, она понимает, что все изменения, отправленные в сообщениях с 1 по 500, были успешно доставлены. Система автоматически удаляет регистрацию этих изменений из своих таблиц, чтобы не перегружать файлы обмена.
Потерянные данные: Если вы вручную увеличите Номер отправленного, система может "подумать", что старые изменения уже доставлены, хотя на самом деле это не так. В результате в периферийной базе могут отсутствовать документы, созданные в центральной базе в период сбоя.

Чтобы избежать потери данных, рекомендуется выполнить принудительную регистрацию объектов. Рассмотрим, как это сделать через ту же обработку "Регистрация изменений для обмена":

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

Проблема "пустых" сообщений

Иногда после сброса номеров полезно выполнить "прогонку" обмена с нулевыми изменениями. Для этого можно использовать метод ПланыОбмена.ВыбратьИзменения(). Посмотрим на программный пример, который упоминался в обсуждении на форуме, для тонкой настройки регистрации:


// Пример программной регистрации конкретного объекта для узла
Узел = ПланыОбмена.Полный.НайтиПоКоду("ПБ");
СсылкаНаОбъект = Документы.РеализацияТоваровУслуг.НайтиПоНомеру("00001", ТекущаяДата());

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

Подводя итог, отметим: изменение номеров сообщений — это стандартная процедура при обслуживании РИБ. Главное — помнить, что номера должны идти строго по порядку, и любое "перепрыгивание" через значения должно сопровождаться анализом того, не остались ли важные документы незарегистрированными в плане обмена. Мы рекомендуем после любой правки номеров проверять актуальность данных в обеих базах и при необходимости использовать ручную перерегистрацию изменений за проблемный период. Для решения этой задачи можно использовать инструмент для регистрации документов и справочников после определенной даты.