Номер сообщения обмена в 1С: почему сбился и как его поправить

Изменить номер отправленного сообщения в 1С можно, но не кнопкой в программе, а через объект узла плана обмена: у каждого узла есть свойства НомерОтправленного и НомерПринятого, их меняют кодом или в форме узла, если поля на неё выведены. Типовые формы синхронизации данных эти поля не показывают специально, чтобы их не трогали случайно.

Чаще всего номер правят в трёх случаях: базу восстановили из копии, узел пересоздали, или обмен падает с ошибкой «сообщение уже принято». Самый безопасный вариант почти всегда один и тот же: поднять номер у отправителя, а не опускать у получателя. Ниже разобрано, почему так, и как это сделать без потери данных.

Как устроена нумерация сообщений обмена

Номер сообщения — это не реквизит документа и не счётчик в справочнике. Это служебный счётчик платформы, который живёт в каждом узле плана обмена.

У узла два числа:

• 📤 НомерОтправленного — номер последнего сообщения, которое эта база выгрузила для узла;
• 📥 НомерПринятого — номер последнего сообщения, которое база загрузила от этого узла.

При выгрузке платформа берёт НомерОтправленного + 1, записывает это число в заголовок сообщения и сохраняет у узла. В тот же заголовок попадает и НомерПринятого — так получатель узнаёт, что отправитель уже получил.

При загрузке происходят две вещи:

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

Пропуски в нумерации допустимы. Если после сообщения 120 пришло 125, оно загрузится. Опасно только обратное движение — когда номер «назад».

Почему номер нельзя просто поменять в программе

В типовых конфигурациях на БСП нет команды «изменить номер сообщения». Это не забывчивость разработчиков, а защита механизма.

Если опустить номер не на той стороне, получится одно из двух:

• 🔁 Повторная загрузка. Получатель примет уже загруженное сообщение ещё раз. Для РИБ это повторная запись тех же объектов, для обменов с конвертацией — возможные дубли.
• 🕳 Потеря изменений. Отправитель удалит регистрацию изменений, которые получатель на самом деле не видел. Данные перестанут уходить, и никакой ошибки не будет.

Вторая ситуация хуже: обмен «работает», а расхождение копится неделями.

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

Когда номер действительно нужно изменить

Типовые причины, при которых счётчики двух баз расходятся:

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

Как посмотреть и сравнить номера в двух базах

Перед любой правкой выпишите четыре числа: по два из каждой базы.

Самый доступный способ — открыть узел через «Все функции»:

1. Включите команду: Главное меню (☰) → Сервис → Параметры → Отображать команду «Все функции».
2. Откройте Главное меню → Все функции → Планы обмена и найдите нужный план.
3. В списке откройте узел другой базы, не свой предопределённый узел.
4. Если в форме есть поля номеров отправленного и принятого, запишите значения.

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

ВЫБРАТЬ
    Узлы.Код,
    Узлы.Наименование,
    Узлы.НомерОтправленного,
    Узлы.НомерПринятого
ИЗ
    ПланОбмена.ИмяПланаОбмена КАК Узлы
ГДЕ
    НЕ Узлы.ЭтотУзел

Вместо ИмяПланаОбмена подставьте имя плана из конфигуратора или из списка «Все функции».

Правильная картина выглядит так: НомерОтправленного в базе А больше или равен НомерПринятого в базе Б, и наоборот. Разница в 1–2 — обычное дело, это сообщения «в пути». Если отправленный меньше принятого на другой стороне — вот место поломки.

Изменение номера кодом: пошаговый способ

Это основной рабочий метод. Он подходит и для РИБ, и для обменов через «Синхронизацию данных».

Сделайте резервную копию обеих баз до правки. Если ошибётесь с направлением, вернуться можно будет только из копии.

Шаг 1. Остановите обмен

Отключите регламентное задание синхронизации или расписание в настройках обмена. Убедитесь, что в каталоге обмена (FTP, папка, почта) не лежат необработанные сообщения. Если лежат — решите, загружать их или удалить.

Шаг 2. Определите, какую сторону править

Правило простое:

• если получатель отвергает сообщения как старые — поднимайте НомерОтправленного у отправителя;
• если получатель по ошибке принял лишнее и счётчик у него «убежал» — возвращайте НомерПринятого у получателя.

Поднимать безопаснее, чем опускать. Подъём ничего не удаляет и не приводит к повторной загрузке.

Шаг 3. Запишите новые значения

Код выполняется на сервере с административными правами — через внешнюю обработку или отладку в конфигураторе:

Узел = ПланыОбмена.ИмяПланаОбмена.НайтиПоКоду("02");
Если Узел.Пустая() Тогда
    ВызватьИсключение "Узел не найден";
КонецЕсли;

УзелОбъект = Узел.ПолучитьОбъект();
УзелОбъект.НомерОтправленного = 260;   // больше, чем НомерПринятого в другой базе
УзелОбъект.ОбменДанными.Загрузка = Истина;
УзелОбъект.Записать();

Пример с числами. В центральной базе у узла «02» НомерПринятого = 254. Подчинённую базу восстановили из копии, и там НомерОтправленного = 241. Следующее сообщение получит номер 242 — центр его отвергнет. Ставим в подчинённой базе 260: следующее сообщение уйдёт под номером 261 и загрузится.

Запас в 5–10 номеров не вредит. Пропуски платформа допускает.

Шаг 4. Проверьте регистрацию изменений

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

Шаг 5. Запустите один обмен вручную

Сначала выгрузка из исправленной базы, затем загрузка в другой. Сверьте номера ещё раз и только потом включайте расписание.

Технические варианты: конфигуратор и СУБД

Если открыть базу в режиме «1С:Предприятие» нельзя или внешние обработки запрещены, остаются два пути.

Отладка в конфигураторе. Запустите базу из конфигуратора в режиме отладки, поставьте точку останова в любой серверной процедуре и выполните строки из шага 3 через «Вычислить выражение». Метод для тех, кто уверенно работает с отладчиком.

Прямая правка в СУБД. В таблицах планов обмена есть поля для номеров отправленного и принятого. Менять их SQL-запросом технически возможно, но не нужно:

• ❌ платформа не узнает об изменении, пока не сбросит свои кэши;
• ❌ легко промахнуться таблицей: имена в СУБД обезличены и не совпадают с именами в конфигураторе;
• ❌ прямая запись в таблицы базы минуя платформу нарушает условия лицензионного соглашения 1С.

Полный сброс нумерации обмена

Иногда проще начать счёт заново, чем подгонять числа. Так делают, когда узел пересоздан, а синхронизацию решили инициализировать с нуля.

Порядок:

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

Для РИБ полный сброс почти всегда хуже, чем создание начального образа подчинённого узла заново. Начальный образ сам выставит корректные счётчики и перенесёт данные целиком. Счётчики вручную в РИБ обнуляют, только если образ создать невозможно, например, из-за размера базы и медленного канала.

Как не допускать сбоя нумерации

Большинство сбоев счётчиков — следствие действий людей, а не платформы. Несколько правил закрывают почти все случаи.

Ещё несколько привычек:

• 🧪 Копия рабочей базы для теста. Сразу после развёртывания отключите в ней обмен. В типовых конфигурациях при запуске копии в другом месте программа спрашивает, что это за база, — отвечайте «это копия».
• 🗂 Разные каталоги обмена. Не используйте одну папку для теста и рабочего контура.
• 📝 Журнал регистрации. Перед правкой посмотрите события синхронизации: там видно, когда обмен перестал проходить и с какой ошибкой.
• 🔒 Права. Изменять узлы плана обмена должен только администратор. Обычному пользователю это право не нужно.

Частые вопросы