Как исправить ошибку «Получатель из сообщения обмена не соответствует ожидаемому» в 1С?

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

В этой статье мы подробно разберем причины возникновения этой ошибки, выясним, почему в кодах узлов планов обмена внезапно появляются длинные GUID-идентификаторы вместо привычных текстовых префиксов, а также рассмотрим пошаговые методы устранения проблемы — как с помощью встроенных инструментов администрирования, так и программным путем. В решении поможет настройка типовой двусторонней синхронизации через EnterpriseData.

Почему возникает ошибка: логика работы платформы 1С

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

• <Отправитель> — уникальный код узла базы, из которой выгружаются данные.
• <Получатель> — уникальный код узла базы, в которую эти данные должны поступить.

Когда база-приемник начинает считывать файл обмена, встроенные механизмы Библиотеки стандартных подсистем (БСП) выполняют строгую проверку:

1. Значение в теге <Получатель> из файла должно абсолютно точно совпадать с кодом предопределенного элемента ЭтотУзел в плане обмена базы-приемника.
2. Значение в теге <Отправитель> должно совпадать с кодом узла корреспондента (второй базы), зарегистрированного в этом же плане обмена.

Если обнаруживается малейшее несовпадение — например, база ожидает получателя с кодом Л3, а в файле записан код БП, или вместо текстового префикса в одном из мест прописан длинный уникальный идентификатор (GUID) — платформа немедленно блокирует чтение данных в целях безопасности, чтобы не допустить загрузку информации в «чужую» информационную базу.

Причины искажения кодов узлов в базах 1С

Выясним, почему настройки префиксов и кодов «разъезжаются» на практике:

1. Автоматическая генерация GUID в современных версиях БСП. При создании синхронизации напрямую (например, через COM-соединение или веб-сервисы) система 1С пытается автоматически исключить коллизии. Чтобы коды узлов не пересекались, если к одной базе БП подключено несколько баз УТ, программа генерирует уникальный идентификатор (например, 57462bf0-7577-446c-b6b9-94eabf9813b9) вместо простых понятных префиксов. Если на этапе создания настройки произошел сетевой сбой, в одной базе узел может создаться с GUID, а в другой — остаться с дефолтным текстовым кодом.
2. «Ловушка» предопределенного узла «Этот узел». Если вы ранее уже настраивали синхронизацию в базах, а затем решили удалить настройку и создать её с нуля с новыми префиксами (например, сменили префикс с БП на Л3), предопределенный элемент ЭтотУзел в плане обмена СинхронизацияДанныхЧерезУниверсальныйФормат автоматически не перезаписывается и не удаляется. Он сохраняет старый префикс, из-за чего новые файлы выгрузки будут генерироваться с новыми именами, но внутри файлов в теге получателя все равно останется старый код.

Рассмотрим подробные варианты исправления этой ошибки.

Способ 1. Программная корректировка кодов узлов планов обмена

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

Рассмотрим пример кода, который решает эту задачу. Запустим его в базе-приемнике:

// Создадим обработку для принудительного изменения кодов узлов синхронизации
УзелОбъекта = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("57462bf0-7577-446c-b6b9-94eabf9813b9").ПолучитьОбъект();
Если УзелОбъекта <> Неопределено Тогда
    УзелОбъекта.Код = "УТ"; // Меняем непонятный GUID на наш префикс базы УТ
    УзелОбъекта.Записать();
    Сообщить("Код узла корреспондента успешно изменен на УТ");
КонецЕсли;

// Теперь откорректируем собственный узел (ЭтотУзел)
ЭтотУзелОбъект = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.ЭтотУзел().ПолучитьОбъект();
Если ЭтотУзелОбъект.Код <> "БП" Тогда
    ЭтотУзелОбъект.Код = "БП"; // Устанавливаем ожидаемый префикс
    ЭтотУзелОбъект.Записать();
    Сообщить("Код собственного узла успешно изменен на БП");
КонецЕсли;

После выполнения данного кода в обеих базах (с соблюдением зеркальности: код отправителя в одной базе должен быть кодом получателя в другой) необходимо обязательно сбросить номера сообщений обмена на «0» или «1», чтобы синхронизация началась заново без конфликтов нумерации — для этого есть обработка управления регистрацией и сброса номеров сообщений обмена.

Способ 2. Использование стандартной обработки «Групповое изменение реквизитов»

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

1. Перейдем в раздел НСИ и администрирование (или Администрирование в БП) — далее выберем пункт Обслуживание — раскроем группу Корректировка данных и откроем ссылку Групповое изменение реквизитов.
2. В поле «Выбирать элементы» найдем и выберем объект: Синхронизация данных через универсальный формат (Планы обмена) (удобно через настройка и модификация синхронизации EnterpriseData между УТ и БП).
3. В открывшемся окне нажмем кнопку Дополнительные параметры (в некоторых версиях конфигураций это кнопка «Настройки»).
4. В параметрах обязательно установим флажки Показывать служебные реквизиты и Режим разработчика. Без включения этих опций платформа 1С заблокирует изменение поля Код, так как оно является ключевым системным идентификатором.
5. Нажмем ссылку «Добавить условие отбора» и настроим отбор по конкретному узлу, который мы хотим отредактировать (например, отбор по ссылке на нужную настройку или на предопределенный элемент Этот узел).
6. В появившемся списке доступных для изменения реквизитов найдем строку Код.
7. В колонке «Новое значение» введем правильный текстовый префикс (например, УТ для узла Управления торговлей или БП для Бухгалтерии), который соответствует реальным настройкам в сопредельной базе.
8. Нажмем кнопку Изменить реквизиты в правом нижнем углу экрана.

Выполнив эту операцию в обеих базах, мы добьемся идеальной синхронности кодов, и ошибка «Получатель из сообщения обмена не соответствует ожидаемому» будет полностью устранена — для контроля качества подойдёт автоматизированная сверка данных после синхронизации УТ и БП.

Способ 3. Экстренный разовый обход ошибки через редактирование файла выгрузки

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

Выполним следующие шаги:

1. Перейдем в каталог обмена, найдем сформированный базой-отправителем XML-файл сообщения обмена (или распакуем ZIP-архив, если выгрузка идет в архивированном виде).
2. Откроем полученный файл Message_...xml с помощью любого продвинутого текстового редактора (например, Notepad++).
3. В самом начале структуры файла (обычно во 2-й или 3-й строке) найдем служебный блок метаданных заголовка. Он выглядит примерно так:
   Скопировать код

   
   <Header>
       <FormatVersion>1.10</FormatVersion>
       <Sender>УТ</Sender>
       <Recipient>БП_старый_код</Recipient>
   </Header>
   

4. Вручную заменим значение в теге <Recipient> (Получатель) на тот код, который сейчас реально прописан в базе-приемнике в качестве кода собственного узла (например, заменим устаревший префикс или GUID на фактическое значение, на которое ругается программа).
5. Сохраним изменения в файле и, если требуется, запакуем его обратно в архив с прежним именем.
6. Запустим операцию загрузки в базе-приемнике. Программа успешно распознает файл и загрузит все необходимые документы.

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