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

← На главную

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

Систематический сбой номеров сообщений обмена с ошибкой «Номер сообщения меньше либо равен ранее принятому».
Эффект «пинг-понга», когда проведенные в подчиненном узле документы (например, «Отчет о розничных продажах») прилетают в центр непроведенными, либо распроводятся обратно после очередного сеанса синхронизации.

Давайте подробно проанализируем причины возникновения этих ошибок и выработаем четкую методику их устранения.

---

Часть 1. Сбой номеров сообщений РИБ при использовании Яндекс.Диска

Причиной первой проблемы часто становится замена классического FTP-сервера на облачные сервисы синхронизации (Яндекс.Диск, Облако Mail.ru, Dropbox и др.) напрямую в качестве каталога обмена 1С. Рассмотрим подробнее, почему это приводит к сбоям.

Технические причины рассинхронизации в облаке:

Асинхронность работы облачного клиента. Когда главный узел 1С выгружает файл обмена (например, Message_001_002.xml), он записывает его на локальный диск компьютера. В ту же секунду 1С считает обмен завершенным и инкрементирует (увеличивает на 1) номер отправленного сообщения в своей базе данных. Однако облачный клиент Яндекс.Диска начинает загрузку этого файла в облако с некоторой задержкой (латентностью), которая зависит от скорости интернета и размера файла. Если подчиненный узел запускает обмен до того, как файл полностью загрузился в облако и скачался на его сторону, он прочитает предыдущий (устаревший) файл. Платформа обнаружит несоответствие номеров и выдаст ошибку.
Конфликтные копии файлов. Если расписание обменов настроено некорректно и сеансы на узлах пересекаются во времени, облачный клиент обнаруживает одновременное изменение одного и того же файла в двух местах. Вместо перезаписи облачный софт переименовывает один из файлов, создавая копию вида Message_001_002 (Конфликтный...).xml. База 1С продолжает обращаться к основному файлу, который откатывается к старой версии или блокируется, вызывая сбой счетчиков.
Монопольный захват файлов. В момент загрузки или скачивания файла облачный клиент блокирует его на уровне операционной системы. Если в этот момент 1С пытается прочитать или перезаписать файл, происходит ошибка доступа. Транзакция обмена прерывается, но счетчики номеров сообщений в базе данных могут перезаписаться некорректно.

Методика решения проблемы с номерами сообщений

Для надежного устранения этой проблемы рассмотрим три последовательных шага.

Шаг 1. Возврат к проверенным протоколам обмена

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

Шаг 2. Буферизация обмена (если облако необходимо оставить)

Если отказаться от Яндекс.Диска невозможно, настройте схему обмена с промежуточным буфером. Никогда не указывайте папку Яндекс.Диска напрямую в настройках обмена 1С. Вместо этого настройте обмен следующим образом:

Укажите в настройках 1С локальный каталог обмена на диске, например: C:\1C_Exchange\Temp\.
Напишите простой скрипт (cmd, PowerShell) или используйте встроенный язык 1С для копирования файлов. Например, после завершения выгрузки из 1С файл перемещается из папки C:\1C_Exchange\Temp\ в папку Яндекс.Диска.
Перед началом загрузки в принимающей базе скрипт должен скопировать файл из папки Яндекс.Диска во временную локальную папку, и только после успешного копирования (когда файл гарантированно скачан полностью) запускается чтение в 1С.

Шаг 3. Программное восстановление сбившихся номеров сообщений

Если номера сообщений уже сбились, и вы постоянно получаете ошибку, их нужно выровнять. Для этого можно открыть заголовок XML-файла обмена в текстовом редакторе и посмотреть правильные номера в тегах <v8msg:MessageNo> и <v8msg:ReceivedNo>. Затем в 1С с помощью внешней обработки «Выполнение алгоритмов» или создав простую обработку, выполним следующий код:


// Выравнивание номеров сообщений для конкретного узла
УзелОбъект = СсылкаНаУзел.ПолучитьОбъект();
УзелОбъект.НомерПринятого = НужныйНомерПринятого; // Значение из XML
УзелОбъект.НомерОтправленного = НужныйНомерОтправленного; // Значение из XML
УзелОбъект.Записать();

---

Часть 2. Самопроизвольное распроведение документов после обмена

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

Технический механизм проблемы:

При загрузке данных РИБ платформа записывает объекты в режиме загрузки: ОбменДанными.Загрузка = Истина. В этом режиме отключаются стандартные проверки конфигурации, чтобы документ записался ровно в том виде, в каком он был выгружен из источника. Вместе с документом передаются и его движения по регистрам.

Однако если документ в источнике был проведен, а в приемнике он становится непроведенным, это сигнализирует о сбое при записи движений или о наличии кастомного кода конфигурации, который некорректно отрабатывает при обмене.

Пошаговая методика поиска и решения проблемы

Шаг 1. Анализ Журнала регистрации (основной инструмент)

В момент проведения обмена в главном узле обязательно откройте Журнал регистрации. Установите отбор:

по периоду (время проведения обмена);
по событию: «Данные.Данные обмена»;
по метаданным: документ «Отчет о розничных продажах».

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

Шаг 2. Анализ доработок конфигурации

Если база «слегка дописана» (например, внедрены доработки прав доступа или кастомные проверки), разработчики могли забыть поставить проверку режима загрузки. Проанализируйте модули документа «Отчет о розничных продажах», а также подписки на события ПередЗаписью, ПриЗаписи и ОбработкаПроведения.

В самом начале обработчиков обязательно должен стоять следующий код:


Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    
    // Если идет загрузка данных обмена, прерываем выполнение кастомного кода
    Если ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    
    // Далее идет ваш доработанный код
    ...
КонецПроцедуры

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

Шаг 3. Анализ контроля остатков и учетной политики

Часто в розничных точках (подчиненных узлах) отключают контроль отрицательных остатков, чтобы продажи не останавливались при пересортице. В центральной же базе контроль остатков может быть жестко включен. При попытке загрузить отчет о продажах в центр, система пытается списать товар по регистрам. Из-за отсутствия остатка в центре проведение отклоняется, и документ сохраняется непроведенным.

Решением является выравнивание учетных политик или отключение контроля остатков при проведении документов в режиме обмена.

Шаг 4. Устранение эффекта «обратного сброса» (петли обмена)

Почему документ, будучи проведенным в подчиненном узле, после исправления в центре снова распроводится? Происходит следующее:

В подчиненном узле документ проведен. Он улетает в центр.
В центре при загрузке происходит сбой проведения (см. Шаги 1-3). Документ записывается в центре как непроведенный.
Так как статус документа в центре изменился, платформа автоматически регистрирует этот документ к отправке обратно в подчиненный узел.
При следующем обмене «непроведенный» статус из центра прилетает обратно в подчиненный узел и затирает там исходный проведенный документ.

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

---

Резюме

Для стабильной работы РИБ в «1С:Управление торговлей 10.3» следуйте простым правилам: используйте надежные протоколы передачи файлов (FTP), всегда проверяйте свойство ОбменДанными.Загрузка во всех доработках конфигурации и внимательно анализируйте Журнал регистрации при возникновении любых коллизий с проведением документов.