Сброс номеров сообщений при синхронизации в 1С 8.3

Многие думают, что раз обмен «сломался» — базы рассинхронизировались и данные потерялись. На деле почти всегда всё цело: программа просто отказывается принимать сообщение, номер которого она уже видела.

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

Что означает ошибка и как устроена нумерация

Обмен между двумя базами (например, БП 3.0 ↔ УТ 11.4 или Бухгалтерия ↔ ЗУП) работает как переписка с нумерацией писем.

У каждого узла плана обмена есть два счётчика:

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

Правило простое: приёмник принимает сообщение, только если его номер больше значения «Номер принятого». Пришло сообщение №48, а база уже приняла №52 — она отвечает:

⚠️ Сообщение обмена было принято ранее (в некоторых релизах — Номер сообщения меньше либо равен ранее принятому).

То есть отправитель по какой-то причине «откатился» назад и шлёт номера, которые приёмник уже отработал. Данные при этом на месте — застревает только механизм обмена.

Из-за чего сбиваются номера сообщений

Счётчик отправленного/принятого сбрасывается или откатывается почти всегда после манипуляций с базой. Типичная картина — восстановление из архива.

Реже причина — сбой при разрыве связи посреди сеанса: одна база успела записать номер, вторая нет.

Как исправить: сброс счётчиков узла обмена

Идея лечения одна — привести счётчики двух узлов в согласованное состояние. Способы отличаются степенью вмешательства: начните с безопасного.

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

Способ 1. Сброс через «Все функции» (без обработок)

Подходит, когда счётчик нужно поправить в одной базе и нет внешних обработок под рукой.

💡 В некоторых конфигурациях реквизиты «Номер отправленного/принятого» на управляемой форме не показаны. Тогда используйте способ 2.

Способ 2. Сброс кодом через внешнюю обработку

Универсальный вариант: работает даже когда счётчиков не видно на форме. Нужны права администратора и режим внешних обработок.

Создайте внешнюю обработку с обычным модулем и таким кодом (имя плана обмена подставьте своё):

// Код узла берётся из карточки узла-соседа
Узел = ПланыОбмена.СинхронизацияДанных.НайтиПоКоду("000000001");
Объект = Узел.ПолучитьОбъект();
Объект.НомерОтправленного = 0;
Объект.НомерПринятого   = 0;
Объект.Записать();
Сообщить("Счётчики узла обнулены");

То же выполните во второй базе для встречного узла. После этого — синхронизация вручную.

⚠️ Обнуляйте счётчики на обоих узлах. Если сбросить только один — обмен встанет уже с обратной ошибкой Номер сообщения меньше либо равен ранее принятому.

Способ 3. Полный сброс регистрации и повторная синхронизация

Крайний вариант — когда счётчики согласовать не удаётся или данные явно разошлись. Обмен настраивается заново «с чистого листа».

1. В обеих базах откройте Администрирование → Синхронизация данных.
2. Удалите или отключите текущую настройку синхронизации.
3. Очистите каталог обмена (папку с файлами *.xml), если обмен идёт через каталог/FTP.
4. Заново создайте настройку синхронизации и выполните полную первичную выгрузку.

Способ рабочий, но долгий: перегружается весь объём данных. Держите его на случай, когда счётчики не помогли.

Сравнение способов:

Проверка после исправления

Не ограничивайтесь «ошибка пропала». Убедитесь, что данные реально доехали.

• ✅ Запустите синхронизацию вручную — сообщений об ошибке быть не должно.
• ✅ В журнале регистрации (Администрирование → Синхронизация данных → результаты) — статус «Выполнено».
• ✅ Создайте тестовый документ в одной базе, проведите обмен, проверьте его появление во второй.
• ✅ Сверьте пару «свежих» документов, созданных до сбоя, — не потерялись ли они.

Как предотвратить повторение

Почти все случаи ошибки — следствие работы с копиями баз. Пара привычек снимает проблему.

• 🔒 После восстановления рабочей базы из архива сразу сверяйте счётчики узлов с соседом.
• 🧪 В тестовых копиях отключайте синхронизацию до первого запуска обмена (в 1С при первом старте копии обычно спрашивает: рабочая это база или копия — отвечайте «продолжить работу с копией» → обмен отключится).
• 🗂 Не копируйте файлы сообщений вручную между каталогами обмена.
• 📅 Не откатывайте только одну базу из пары — либо обе на один момент, либо потом сброс счётчиков.

Если не помогло

Ошибка держится после сброса — проверьте нетипичные причины:

• Код узла не совпадает. В одной базе правили счётчик не того узла. Сверьте код узла-соседа в обеих базах.
• Обмен идёт по расписанию из фона. Регламентное задание перезапустило старое сообщение. Временно отключите расписание, поправьте счётчики, включите обратно.
• Два обмена на одну базу. Если у базы несколько узлов (например, и с УТ, и с ЗУП), сбрасывайте счётчики только проблемной пары.
• Разные релизы конфигураций. Сильное расхождение версий даёт ошибки формата сообщения — обновите обе базы до совместимых релизов и повторите.
• Каталог обмена переполнен старыми файлами. Очистите папку *.xml и запустите обмен заново.

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