Как исправить ошибку РИБ «Номер сообщения меньше или равен номеру ранее принятого сообщения»?

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

Причины возникновения ошибки

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

1. Восстановление базы из резервной копии. Если центральная или периферийная база была восстановлена из бэкапа, ее внутренние счетчики номеров сообщений откатываются назад во времени, в то время как во второй базе счетчики уже ушли вперед.
2. Повторная загрузка старого файла обмена. Ошибка может возникнуть, если в сетевой каталог обмена, на FTP-сервер или электронную почту по ошибке был выгружен или вручную подставлен уже ранее обработанный файл сообщения.
3. Сбой транзакции при фиксации обмена. В случае аварийного завершения сеанса 1С или обрыва связи файл мог быть записан и передан, но сам узел не успел зафиксировать успешное изменение номера отправленного сообщения в базе-источнике.
4. Параллельное выполнение регламентных заданий. Несколько одновременно запущенных фоновых заданий обмена могут создать коллизию файлов с одинаковыми номерами.

Способ 1. Программная корректировка номеров в узле плана обмена

Рассмотрим основной способ решения проблемы, когда интерфейс конфигурации блокирует прямое редактирование реквизитов узла плана обмена. Нам необходимо скорректировать реквизит НомерПринятого в узле-приемнике так, чтобы он стал меньше номера, указанного во входящем файле сообщения (обычно на единицу меньше номера входящего сообщения).

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

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

Если УзелОбъект <> Неопределено Тогда
    // Устанавливаем номер принятого сообщения меньше номера входящего пакета
    УзелОбъект.НомерПринятого = 9; 
    // При необходимости можно скорректировать и номер отправленного
    // УзелОбъект.НомерОтправленного = 9;
    
    УзелОбъект.Записать();
    Сообщить("Счетчики сообщений успешно обновлены!");
Иначе
    Сообщить("Узел плана обмена с указанным кодом не найден!");
КонецЕсли;

Проанализируем логику номеров: если из удаленной базы пришел файл с номером 10, то в текущей базе для этого узла значение НомерПринятого должно быть установлено в 9. После этого метод НачатьЧтение() успешно обработает входящий пакет.

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

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

1. Откроем раздел Администрирование > Синхронизация данных (или запустим обработку Регистрация изменений для обмена данными).
2. Выберем нужную настройку синхронизации и нажмем на кнопку редактирования состава изменений.
3. В открывшемся окне перейдем в свойства узла плана обмена.
4. В полях Номер отправленного и Номер принятого вручную укажем согласованные значения и сохраним изменения.

Способ 3. Определение номеров через XML-файл обмена

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

В теге MessageNo указан номер текущего пакета данных, а в теге ReceivedNo — номер последнего пакета, успешно принятого отправителем. Сверив эти параметры с реквизитами узла в базе-приемнике, можно безошибочно выставить требуемое значение НомерПринятого.

Опасность потери данных и правила работы с бэкапами

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

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

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

1. Выровняем номера сообщений в узлах обмена описанными выше способами.
2. Выполним принудительную перерегистрацию всех объектов для проблемного узла с помощью типовой обработки регистрации изменений или программного метода ПланыОбмена.ЗарегистрироватьИзменения().
3. Выполним полный цикл обмена данными в обе стороны до полной синхронизации всех зарегистрированных изменений.