← На главную

Рассмотрим ситуацию, с которой часто сталкиваются специалисты при настройке синхронизации между конфигурациями на платформе 1С:Предприятие (например, между «1С:Управление торговлей» и «1С:Бухгалтерия предприятия»). Настроен односторонний обмен через FTP-каталог или сетевую папку. Выгрузка из базы-источника проходит успешно, файл формируется и появляется в нужной папке (например, с именем Message_УТ_ОП.xml). Однако база-приемник отказывается его загружать, выдавая ошибку вида:

«Обработка: ТранспортСообщенийОбменаFILE: В каталоге обмена информацией не был обнаружен файл сообщения с данными. Каталог обмена информацией: "W:\obmen" Имя файла сообщения обмена: "Message*_1fb34ad3-7dfa-4034-af29-452388c06db4_ОП.xml"»

Проанализируем эту ситуацию. Мы видим явное несовпадение ожиданий: источник отправляет файл, где код узла — это привычный строковый префикс УТ, а приемник отчаянно ищет файл, где вместо кода источника фигурирует длинный уникальный идентификатор (GUID) 1fb34ad3-7dfa-4034-af29-452388c06db4. Разберем по шагам, откуда берутся эти длинные имена, почему ручное переименование не помогает и как навсегда «подружить» базы.

Выясним причину: почему префиксы меняются на GUID?

Если мы зайдем в план обмена в базе-приемнике и вручную изменим поле «Код узла» с непонятного GUID на нужный нам префикс УТ, то первый же сеанс обмена может пройти успешно. Но затем мы с удивлением обнаружим, что код узла снова самостоятельно перезаписался на GUID. Посмотрим, почему так происходит.

Описанное поведение — это не баг, а задокументированный механизм Библиотеки стандартных подсистем (БСП). В определенный момент фирма «1С» изменила логику формирования кодов узлов в планах обмена при переходе на универсальный формат EnterpriseData (начиная с версии формата 1.9). Строковые префиксы (например, УТ или БП) перестали удовлетворять требованиям масштабируемости, так как при настройке сложных распределенных баз данных возникали коллизии имен (разные базы могли иметь одинаковые префиксы). Для этой задачи есть настройка стабильной синхронизации по EnterpriseData.

Чтобы избежать дублирования узлов, алгоритмы 1С стали использовать уникальные идентификаторы (GUID). Процесс выглядит так:

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

В итоге, УТ выгружает данные с префиксом, а БП после обновления требует файлы с GUID. Возникает тупик синхронизации.

Разберем решения проблемы

Рассмотрим два самых действенных способа исправить этот сбой, не прибегая к сложной модификации кода конфигурации или используя готовые правила обмена для УТ 11 и БП 3.0 (для этого подойдёт альтернативный перенос документов из УТ в БП).

Способ 1. Временное понижение версии формата обмена (EnterpriseData)

Это быстрое и эффективное решение, если вы не хотите полностью пересоздавать настройки синхронизации.

1. Зайдите в обе базы (и в УТ, и в БП).
2. Откройте список настроек синхронизации данных.
3. Перейдите в форму настройки узла плана обмена.
4. Нажмите кнопку «Еще» в правом верхнем углу и выберите пункт «Изменить форму».
5. В открывшемся окне настройки формы отметьте галочкой все скрытые элементы. Ваша цель — сделать видимой вкладку «Служебная информация». Примените изменения.
6. Перейдите на появившуюся вкладку «Служебная информация». Найдите поле «Версия формата обмена».
7. Измените значение версии формата с текущего (например, 1.10 или 1.11) на более старое значение 1.8. Сделайте это синхронно в обеих базах.
8. Запустите сеанс обмена. Формат 1.8 еще не использовал жесткую привязку к GUID, поэтому обмен пройдет корректно, и базы сопоставят свои узлы без конфликта имен.
9. После успешной синхронизации система может автоматически вернуть версию формата на актуальную (например, 1.10). Однако коллизия имен файлов больше возникать не будет, так как служебные регистры сопоставления уже корректно проинициализировались.

Способ 2. Полное пересоздание настройки синхронизации

Если понижение формата не дало результатов, самым надежным, «чистым» решением станет перенастройка обмена с нуля. Под капотом 1С сопоставление узлов привязывается к системным регистрам (бывает, что обмен переполнен документами и не может быть выгружен в адекватное время). (например, регистр сведений ПубличныеИдентификаторыСинхронизируемыхОбъектов). Когда база ловит "клин" между префиксами и GUID, эти регистры могут содержать противоречивую информацию.

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

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

Если вы исключили проблему с подменой имени файла из-за GUID (имена файлов, которые ищет БП и которые формирует УТ, абсолютно идентичны), но ошибка «В каталоге обмена информацией не был обнаружен файл...» всё равно появляется, обратите внимание на следующие внешние факторы:

1. Блокировка антивирусным ПО: Антивирус или встроенный защитник ОС на сервере может реагировать на появление новых XML/ZIP файлов в сетевой папке. Файл Message_...xml может блокироваться для проверки, моментально удаляться или помещаться в карантин. Попробуйте добавить каталог обмена в исключения антивируса.
2. Недостаток прав доступа: Если обмен выполняется в фоновом режиме (через регламентные задания), процесс выполняется под учетной записью пользователя ОС, от имени которого работает служба Агента сервера 1С (обычно это USR1CV8). Убедитесь, что у этого пользователя есть полные права на чтение и запись в папку обмена (настройка разрешений NTFS на уровне Windows).
3. Сбой прямого подключения (COM-соединение): Иногда, если базы настроены на прямой обмен (когда одна база подключается к другой напрямую, а не через файл), после обновления платформы или изменения паролей COM-соединение может "отвалиться". В такой ситуации система, не сумев передать данные напрямую, пытается найти файлы в каталоге резервного файлового обмена. Так как файл туда никто не выгружал, появляется ошибка отсутствия файла. В этом случае нужно перенастроить или восстановить параметры прямого подключения в узле.

Следуя этим шагам, вы сможете точно локализовать проблему и восстановить штатную работу обмена данными между вашими информационными базами 1С.