При настройке обмена данными между конфигурациями 1С, например, между «Управление торговлей 11.5» и «Бухгалтерия предприятия 3.0», можно столкнуться с неприятной ситуацией. Первый обмен проходит успешно, но все последующие попытки загрузить данные в базу-приемник завершаются ошибкой: «Обработка: ТранспортСообщенийОбменаFTP: В каталоге обмена информацией не был обнаружен файл сообщения с данными». При этом проверка показывает, что файл выгрузки на FTP-сервере физически существует.
Давайте вместе проанализируем эту проблему, выясним её корневую причину и разберем по шагам, как ее исправить.
В тексте ошибки система сообщает нам две важные детали: каталог на сервере, где она ищет файл, и ожидаемое имя файла. Например:
Каталог обмена информацией на сервере: "/tr83/"
Имя файла сообщения обмена: "Message_e3d2ac20-c5ad-45d9-b743-195c26b5240c_a81b384a-9998-4d8a-a081-e5f0ad21e5e2.xml"
Структура имени файла обмена в 1С обычно следует формату Message_[КодУзлаОтправителя]_[КодУзлаПолучателя].xml. Каждый участник обмена (информационная база) имеет два идентификатора:
Проблема, описанная в теме, чаще всего возникает, когда одна из баз-участников обмена была создана путем копирования другой. В этом случае скопированная база «наследует» тот же самый уникальный код узла, что и у оригинала. Система обмена оказывается в замешательстве: существуют две разные базы с абсолютно одинаковыми внутренними идентификаторами.
Рассмотрим на примере:
e3d2ac20-...a81b384a-...a81b384a-...Когда УТ выгружает данные для новой БП, она формирует файл с именем, предназначенным для узла a81b384a-.... Но когда новая БП пытается загрузить данные, она может некорректно идентифицировать себя в этой паре, так как ее собственный код совпадает с кодом другой базы. В результате она ищет файл, который, по ее логике, должен быть адресован ей, но не находит его из-за путаницы в идентификаторах. Поэтому ключевое решение — обеспечить уникальность кодов узлов.
Главная сложность заключается в том, что поле Код в настройках узла плана обмена в пользовательском режиме обычно заблокировано для редактирования. Система присваивает его автоматически при создании узла и не предполагает штатного изменения. Чтобы обойти это ограничение, нам понадобится специальный инструмент.
Порядок действий:
Находим инструмент. Нам нужна универсальная внешняя обработка «Редактор реквизитов объекта» или «Групповое изменение реквизитов». Это мощные инструменты для администраторов и разработчиков, которые позволяют изменять любые данные в системе, даже те, что скрыты или заблокированы в стандартном интерфейсе. Найти их можно на профильных ресурсах для разработчиков 1С.
Открываем обработку в "проблемной" базе. Запустите 1С в режиме «Предприятие» под пользователем с полными правами в той базе, где нужно сменить код (в нашем случае — в скопированной базе «Бухгалтерии»). Через меню «Файл» → «Открыть» выберите скачанную обработку (файл с расширением .epf).
Выбираем объект для редактирования. В интерфейсе обработки нужно указать, какой именно объект мы хотим изменить. В поле выбора типа объекта найдите и выберите нужный план обмена. Например, План обмена.СинхронизацияДанныхЧерезУниверсальныйФормат.
Находим нужный узел. После выбора типа объекта обработка покажет список всех элементов этого типа. Нам нужен узел, который соответствует текущей информационной базе. Обычно он имеет соответствующее наименование, например, «Эта информационная база» или название, совпадающее с префиксом.
Меняем код. Выбрав нужный узел, вы увидите список его реквизитов. Найдите реквизит с именем Код. Его текущее значение будет совпадать с кодом узла из другой базы. Ваша задача — заменить его на новый, абсолютно уникальный GUID. Сгенерировать новый GUID можно с помощью онлайн-генераторов или прямо в 1С в любой строке кода, выполнив команду:
Сообщить(Новый УникальныйИдентификатор());
Скопируйте полученный результат и вставьте его в поле Код в обработке.
Сохраняем изменения. После замены кода нажмите кнопку «Записать объект» или «Выполнить» в обработке. Код узла будет принудительно изменен.
Перенастраиваем обмен. После смены кода необходимо обновить настройки синхронизации в обеих базах. Системы должны заново «познакомиться» друг с другом и запомнить новые идентификаторы. Проще всего запустить помощник настройки обмена и пройти его шаги заново, указав те же параметры (каталог FTP, логин, пароль). Система обнаружит, что код изменился, и обновит соответствия.
После выполнения этих шагов проблема с поиском файла должна быть решена. Новый обмен создаст файл с корректными и, что самое главное, уникальными кодами отправителя и получателя.
Хотя дублирование кодов — самая частая причина этой ошибки, иногда проблема может крыться в технических аспектах работы FTP. Если вы уверены, что коды узлов уникальны, но ошибка сохраняется, проанализируем другие возможные источники проблемы.
Пользователь, от имени которого 1С подключается к FTP-серверу, должен иметь полный набор прав на указанный каталог: чтение, запись, удаление файлов и, что критически важно, право на просмотр списка файлов в каталоге. Без последней привилегии 1С просто не сможет «увидеть» выгруженный файл, даже если он там есть.
FTP-серверы могут работать в двух режимах: активном и пассивном. Иногда из-за настроек сети или брандмауэра один из режимов может не работать. В настройках транспорта сообщений в 1С попробуйте переключить режим с пассивного на активный или наоборот. Это может решить проблему с установлением соединения для передачи данных.
Антивирусное ПО, как на клиентском компьютере, так и на сервере, может ошибочно принять файл обмена (особенно .xml или .zip) за потенциальную угрозу и заблокировать его запись или чтение. Временно отключите антивирус для диагностики или добавьте каталог обмена и процессы 1С в исключения.
Двойная проверка пути к каталогу обмена никогда не бывает лишней. Убедитесь, что нет опечаток, а также правильно указаны слэши. Например, путь /tr83/ и tr83 — это разные пути для FTP-сервера.
Если в настройках обмена включено сжатие файла в .zip архив, ошибка может возникать на этапе создания или чтения архива. В качестве теста временно отключите опцию «Сжимать файл исходящего сообщения». Если обмен без сжатия пройдет успешно, значит, проблема связана с работой архиватора, и стоит проверить наличие свободного места или права на временные папки.
Таким образом, планомерно проверив эти пункты, начиная с уникальности кодов узлов, вы гарантированно найдете и устраните причину ошибки «В каталоге обмена информацией не был обнаружен файл сообщения с данными».