Обмен 1С молчит, документы не доезжают: локализуем сбой за три проверки

12 июня 2026 · infolimp.ru

Обмен между УТ и БП «работает»: регламентное задание отрабатывает, ошибок на экране нет — а документы за вторник в бухгалтерию так и не доехали. Знакомая картина: сбой обмена редко выглядит как сбой, чаще он выглядит как тишина. Перебирать настройки наугад в этой ситуации можно днями; локализовать станцию, на которой застряли данные, — минут двадцать, если есть доступ к журналам обеих баз с правами администратора.

Обмен — это конвейер из трёх станций

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

Станция 1. Зарегистрировано ли изменение

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

ВЫБРАТЬ Изменения.Узел, Изменения.НомерСообщения
ИЗ Документ.РеализацияТоваровУслуг.Изменения КАК Изменения
ГДЕ Изменения.Ссылка = &ПроблемныйДокумент

Пустой результат по нужному узлу означает: изменение не зарегистрировано, дальше можно не искать.

Если объект не зарегистрирован — это и есть ответ. Лечение точечное — одна строка во встроенном языке: ПланыОбмена.ЗарегистрироватьИзменения(Узел, ПроблемныйДокумент.Ссылка), а не «перевыгрузить всё» — полная перерегистрация на живой базе с большим планом обмена легко превращает двадцатиминутную задачу в ночной прогон.

Станция 2. Ушло ли сообщение

У каждого узла плана обмена есть счётчики НомерОтправленного и НомерПринятого — по ним видно, движется ли конвейер вообще. Если номер отправленного не растёт между сеансами обмена — выгрузка не происходит: смотрите журнал регистрации источника за время сеанса, там будет причина — от ошибки в правилах конвертации до недоступного каталога обмена. В типовых конфигурациях на актуальной БСП (БП 3.0, УТ 11 и родня) первая точка осмотра — Администрирование → Синхронизация данных → Предупреждения синхронизации; на старых версиях БСП этого узла может не быть — тогда сразу журнал регистрации. Туда падает то, что механизм обмена счёл некритичным и о чём не стал кричать.

Станция 3. Загрузилось ли в приёмнике

Самая обманчивая станция: сообщение принято, а данных нет. Типовые причины — объект не прошёл проверку при загрузке (непроведённый документ с ошибкой заполнения), конфликт изменений «обе базы правили один объект», битая ссылка на элемент, которого в приёмнике ещё нет. Всё это оставляет следы в журнале регистрации приёмника и в предупреждениях синхронизации — читать их надо за время сеанса загрузки, с отбором по уровню «Ошибка» и «Предупреждение».

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

Чек-лист на двадцать минут

• Доступ: обе базы, права администратора (журнал регистрации + план обмена).
• Воспроизводимый пример: один конкретный документ, который должен был доехать и не доехал.
• Станция 1: зарегистрирован ли он к передаче по узлу в источнике.
• Станция 2: растут ли НомерОтправленного/НомерПринятого, есть ли сообщение на транспорте, что в журнале регистрации источника за сеанс.
• Станция 3: журнал регистрации и предупреждения синхронизации приёмника за сеанс загрузки.
• Найденную станцию чините точечно: повторная регистрация конкретных объектов, восстановление транспорта, разбор конфликта — и только потом контрольный сеанс обмена по тому же документу.

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

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