← На главную

При настройке стандартного обмена данными между конфигурациями 1С:Бухгалтерия предприятия и 1С:ERP Управление предприятием многие специалисты сталкиваются с неожиданным поведением: привычные короткие буквенные коды узлов (например, БП и ЦБ) после первого сеанса синхронизации автоматически заменяются длинными строками идентификаторов (GUID). Вслед за этим в каталоге обмена создаются файлы сообщений с длинными шестнадцатеричными именами вида Message_{GUID}_{GUID}.zip. Выясним причину такого поведения платформы, проанализируем риски ручного вмешательства и рассмотрим правильные варианты работы с планами обмена.

Почему коды узлов меняются на GUID: архитектура EnterpriseData и БСП

Для понимания происходящего разберем внутреннюю логику работы подсистемы обмена данными «1С:Библиотеки стандартных подсистем» (БСП) и универсального формата EnterpriseData:

1. Назначение длины кода плана обмена. В современных конфигурациях обмен строится на базе единого плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Стандартный реквизит Код этого плана обмена имеет длину 36 символов, что в точности соответствует длине строкового представления уникального идентификатора (UUID/GUID).
2. Путаница между префиксом базы и кодом узла. В мастере первоначальной настройки синхронизации программа запрашивает префикс информационной базы. Этот префикс (например, БП или ЦБ) необходим исключительно для разделения нумерации документов и справочников, создаваемых в разных узлах, чтобы исключить дублирование номеров. Пользователи часто ошибочно полагают, что задают код самого узла обмена.
3. Фаза инициализации («рукопожатие»). При первом успешном сеансе связи (будь то обмен через общий каталог, прямое подключение к базе или веб-сервис) конфигурации обмениваются служебными метаданными. БСП автоматически считывает глобальный уникальный идентификатор базы-корреспондента и записывает его в качестве кода узла. Это штатный механизм, призванный предотвратить коллизии при подключении нескольких одинаковых баз (например, трех баз БП к одной ERP) и исключить циклические передачи данных при сложной топологии обмена.

Ручное изменение кодов через редактор объектов: анализ решения и риски

На практике часто применяется быстрое решение: принудительно вернуть буквенные коды с помощью внешней обработки (например, редактора объектов из состава инструментов разработчика). Однако такое вмешательство сопряжено с серьезными рисками для работоспособности обмена. Проанализируем, к чему это может привести:

1. Служебная блокировка реквизита. Поле Код узла в интерфейсе синхронизации намеренно заблокировано разработчиками от интерактивного редактирования, поскольку адресность сообщений строго привязана к этому значению.
2. Нарушение адресации пакетов. В заголовке XML-сообщения обмена формируются служебные теги отправителя и получателя: <From> и <To>. При загрузке сообщения база-приемник ищет узел строго по значению из этих тегов. Если изменить код только в одной из баз, синхронизация завершится аварийно с ошибкой: «Получатель из сообщения обмена не соответствует ожидаемому» или «Не удалось загрузить данные (этап анализа данных)».
3. Сброс настроек при повторной синхронизации. Если в дальнейшем администратор выполнит проверку подключения, перенастроит транспорт или обновит параметры подключения из внешнего файла настроек, БСП выполнит повторное сопоставление и снова перезапишет буквенные коды на GUID.

Вариант 1. Штатный подход: сохранение кодов в формате GUID (рекомендуется)

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

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

Вариант 2. Корректный возврат буквенных кодов (если имена файлов критичны)

Бывают ситуации, когда буквенные коды узлов и короткие имена файлов сообщений строго необходимы — например, если сторонние скрипты резервного копирования, системы мониторинга каталогов или интеграционные шины настроены на маски файлов вида Message_БП_ЦБ.zip. В этом случае разберем по шагам, как корректно выполнить переименование без нарушения логики обмена:

1. Корректировка узлов в базе ERP. Открываем конфигурацию ERP, запускаем обработку редактирования реквизитов объектов и находим план обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Элементу «Этот узел» (предопределенный элемент плана обмена) присваиваем код ЦБ. Для узла базы-корреспондента (базы бухгалтерии) устанавливаем код БП.
2. Корректировка узлов в базе БП. Открываем конфигурацию «Бухгалтерия предприятия» и переходим в тот же план обмена. Элементу «Этот узел» присваиваем код БП, а узлу-корреспонденту (базе ERP) задаем код ЦБ. Коды должны зеркально соответствовать друг другу.
3. Очистка каталога обмена. Удаляем из каталога обмена старые файлы с GUID в именах, так как система больше не сможет их сопоставить.
4. Повторная выгрузка. Выполняем полный сеанс выгрузки и загрузки данных сначала из одной базы, затем из другой. Формируются новые файлы с именами требуемого формата, и адресация сообщений восстанавливается.

Особый случай: создание узла в скопированной информационной базе

С проблемой кодов узлов тесно связана распространенная ошибка при развертывании тестовых стендов. Если рабочая база была скопирована, элемент «Этот узел» в копии сохраняет исходный GUID рабочей базы. При попытке настроить синхронизацию между рабочей ERP и тестовой БП система выдаст ошибку зацикливания или откажет в подключении из-за совпадения идентификаторов.

Разберем, как штатно решить эту проблему без сторонних утилит:

1. Открываем список настроек синхронизации данных (раздел Администрирование — Синхронизация данных — Настройки синхронизации данных).
2. В командной панели формы нажимаем кнопку Еще.
3. Выбираем служебную команду «Новый код предопределенного узла».
4. Платформа автоматически перегенерирует внутренний идентификатор узла текущей информационной базы, после чего синхронизация настроится без конфликтов адресации.