← На главную

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

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

Причина 1. Рассинхронизация номеров входящих и исходящих сообщений

В механизме планов обмена 1С реализован строгий контроль последовательности пакетов. Для каждого узла в системе хранятся два ключевых реквизита: Номер отправленного и Номер принятого. Если на торговой точке используется нестабильное подключение (например, 3G/4G модем), обмен часто прерывается.

Проанализируем механику сбоя:

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

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

1. Откроем типовую обработку Регистрация изменений для обмена данными через меню Администрирование или через функции для технического специалиста.
2. Выберем соответствующий узел плана обмена и перейдем к просмотру его параметров.
3. Сверим номер пакета внутри реального файла обмена (его можно увидеть в заголовке XML-файла в атрибуте MessageNo) со значениями в реквизитах узла.
4. Скорректируем вручную Номер принятого сообщения в базе-приемнике так, чтобы он был строго на единицу меньше номера входящего файла, либо сбросим номера в обеих базах в согласованное состояние.

Причина 2. Особенности прав доступа в клиент-серверном режиме (SQL / Сервер 1С)

Если база работает в клиент-серверном режиме под управлением 1С:Предприятие (сервер) и MS SQL Server / PostgreSQL, регламентные задания обмена выполняются не в контексте текущего пользователя Windows, а от имени системной службы сервера (по умолчанию учетная запись USR1CV8).

Рассмотрим типичные ошибки при указании путей к файлам:

1. Использование букв сетевых дисков (например, Z:\): Подключенные сетевые диски существуют исключительно в сеансе конкретного интерактивного пользователя. Серверная служба 1С сетевых букв дисков не видит. Пути к каталогам обмена необходимо указывать исключительно в формате UNC: \\ServerName\ShareName\Exchange.
2. Размещение каталогов обмена в профилях пользователей: Пути вида C:\Users\ИмяПользователя\YandexDisk\obmen часто блокируются политиками безопасности ОС, так как учетная запись службы 1С не имеет прав на доступ к чужим пользовательским каталогам. Каталог обмена необходимо выносить в корень диска или на отдельный общий ресурс, выдав учетной записи USR1CV8 полные права на чтение и запись.

Причина 3. Блокировки файлов утилитами синхронизации облачных дисков

Использование сторонних клиентов (Яндекс.Диск, Облако Mail.ru и др.) в качестве транспорта обмена часто приводит к коллизиям доступа:

1. Файловые блокировки: Как только 1С начинает формировать архив Message_XX_YY.zip, клиент облачной синхронизации мгновенно перехватывает файл для отправки на сервер, накладывая файловую блокировку (lock). В этот момент 1С не может завершить запись или перезаписать файл, получая отказ операционной системы.
2. Неполная загрузка архива: На узле-приемнике фоновое задание 1С может попытаться прочитать архив обмена до того, как утилита облака завершит его скачивание из сети. Попытка распаковки неполного архива вызывает ошибку Файл не обнаружен или сбой структуры ZIP.

Причина 4. Настройка транспорта FTP для мобильного интернета

Если обмен настраивается через протокол FTP на узлах с модемами, обязательно проверим параметры FTP-соединения в настройках транспорта 1С:

1. Пассивный режим (Passive Mode): Мобильные операторы работают через механизмы CGNAT. Активный режим FTP в таких сетях не работает. В настройках транспорта обмена обязательно должен быть установлен флаг Пассивный режим.
2. Таймаут соединения: Стандартный таймаут ожидания ответа сервера (20–30 секунд) при низкой скорости 3G приводит к обрывам при передаче крупных пакетов. Увеличим таймаут в настройках подключения до 120–300 секунд.
3. Регистр и синтаксис каталогов: Проверим корректность указания каталога на FTP-сервере (наличие или отсутствие начального слеша /), так как некорректно заданный относительный путь может приводить к сохранению файлов в корневую директорию пользователя вместо целевой папки.

Рекомендация по переходу на прямой обмен через веб-сервисы

Для узлов с регулярными обрывами связи файловый обмен через сетевые папки, сторонние облачные клиенты и FTP является наименее надежным решением. Наиболее устойчивый способ — публикация центральной информационной базы на веб-сервере (IIS или Apache) и настройка синхронизации через протокол HTTP/HTTPS. В этом случае 1С передает данные напрямую через веб-сервис без промежуточных файлов и внешних утилит, автоматически обрабатывая повторные попытки передачи пакетов при нестабильном интернет-канале.