Почему в РИБ 1С:Управление торговлей 11 не загружаются данные и горит красный индикатор обмена

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

Разберем основные причины такого поведения и пошагово рассмотрим способы восстановления корректного цикла обмена.

Причина 1. Несовпадение релизов платформы 1С:Предприятие на узлах

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

Для устранения этой проблемы выполним следующие действия:

1. Проверим точный номер сборки платформы на всех узлах распределенной базы через меню «Справка» — «О программе».
2. Обновим платформу 1С:Предприятие на всех рабочих станциях и серверах до единого стабильного релиза.
3. Перезапустим сеансы 1С и выполним тестовую итерацию выгрузки и загрузки.

Причина 2. Сбой и рассинхронизация номеров пакетов обмена

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

Если цикл обмена был прерван, файл перезаписан вручную или база восстанавливалась из резервной копии, номера сообщений рассинхронизируются:

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

Способ исправления: программный сброс номеров сообщений

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

ИмяПланаОбмена = "ПланОбменаРИБ"; // Укажите имя плана обмена конфигурации
КодУзла = "ПР1"; // Код узла, с которым нарушена синхронизация

УзелОбъект = ПланыОбмена[ИмяПланаОбмена].НайтиПоКоду(КодУзла).ПолучитьОбъект();
Если УзелОбъект <> Неопределено Тогда
    УзелОбъект.НомерПринятого = 0;
    УзелОбъект.НомерОтправленного = 0;
    УзелОбъект.Записать();
КонецЕсли;

После сброса счетчиков в 0 выполним полный цикл обмена: сначала сформируем выгрузку из первой базы, загрузим ее во вторую, после чего сделаем ответную выгрузку и примем ее в первой базе. Номера пакетов начнут отсчет заново, и квитанции доставки будут зафиксированы корректно.

Способ исправления: корректировка через штатную обработку БСП

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

1. Откроем раздел «НСИ и администрирование» — «Синхронизация данных» — «Настройки синхронизации данных».
2. Нажмем на кнопку «Состав отправляемых данных» (обработка РегистрацияИзмененийДляОбменаДанными).
3. В открывшемся окне выберем нужный узел плана обмена и перейдем в меню параметров узла (кнопка с изображением параметров или «Номера сообщений»).
4. Вручную скорректируем реквизиты Номер принятого и Номер отправленного в соответствии с реальными номерами в заголовке файла обмена либо установим их в 0 на обоих узлах.

Особенности обмена через облачные папки (Dropbox, Яндекс Диск)

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

1. Блокировка доступа: пока облачный клиент загружает zip-архив на диск, он держит файловый дескриптор открытым. Платформа 1С не может прочитать заблокированный архив и прерывает операцию.
2. Конфликты имен: при одновременной записи сервис может переименовать файл (например, добавив имя пользователя или пометку конфликта). Так как 1С ожидает строго регламентированное имя вида Message_КодОтправителя_КодПолучателя.zip, переименованный файл игнорируется.

Для стабильной работы рекомендуется настроить обмен через прямой сетевой каталог (SMB), FTP-сервер либо убедиться, что фоновая синхронизация облака не блокирует временные файлы обмена.

Где посмотреть детальный лог ошибки

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

1. Откроем «Журнал регистрации» (раздел «НСИ и администрирование» — «Обслуживание») и установим отбор по событию Синхронизация данных. Там отображаются ошибки XML-парсера, коллизии версий и сбои транзакций записи объектов.
2. В форме настроек синхронизации нажмем меню «Еще» — «События получения данных» и «События отправки данных» для просмотра детального протокола последнего сеанса.