Почему при синхронизации УТ 11 и БП 3.0 префиксы баз заменяются на длинные ID и как это исправить?

При настройке или очередном сеансе синхронизации между конфигурациями «Управление торговлей, ред. 11» и «Бухгалтерия предприятия, ред. 3.0» пользователи часто сталкиваются с неожиданным поведением системы. Вместо привычных коротких префиксов (например, БП или УТ) в именах файлов обмена и в кодах узлов планов обмена появляются длинные наборы символов — GUID (например, 72d6d52d-de26-42cd-aca1-5fdfa4842d06). Это приводит к тому, что привычные файлы Message_УТ_БП.zip перестают загружаться, а система выдает ошибку на этапе анализа данных.

Рассмотрим подробнее, почему это происходит, и разберем по шагам, как восстановить работоспособность обмена.

Выясним причину изменения поведения системы

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

Основные причины перехода на GUID:

1. Уникальность: Короткие префиксы из двух-трех символов часто дублируются в сложных инфраструктурах, что вызывает конфликты. GUID гарантированно уникален для каждой информационной базы.
2. Автоматизация: При использовании универсального формата EnterpriseData система стремится минимизировать влияние «человеческого фактора» при именовании узлов.
3. Обновление метаданных: Во время фонового обновления конфигурации запускаются процедуры миграции, которые перезаписывают старые префиксы техническими идентификаторами.

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

Способ 1: Адаптация под новые идентификаторы (Рекомендуемый)

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

Внутри XML-файла сообщения префиксы также меняются. Рассмотрим пример структуры заголовка сообщения:

<msg:Confirmation>
    <msg:ExchangePlan>СинхронизацияДанныхЧерезУниверсальныйФормат</msg:ExchangePlan>
    <msg:To>5fb682e5-ef64-4867-9fa2-27313b2e4448</msg:To>
    <msg:From>75ac2458-7f4f-4243-8436-99a86a165ac7</msg:From>
    <msg:MessageNo>6</msg:MessageNo>
    <msg:ReceivedNo>5</msg:ReceivedNo>
</msg:Confirmation>

Чтобы обмен прошел успешно, выполним следующие действия:

1. Зайдем в настройки синхронизации в обеих базах и определим полные GUID, которые система присвоила узлам (их можно увидеть в журнале регистрации или через консоль запросов).
2. Переименуем файлы в каталоге обмена. Например, если раньше файл назывался Message_УТ_БП.zip, то теперь он должен называться Message_[GUID_ОТПРАВИТЕЛЯ]_[GUID_ПОЛУЧАТЕЛЯ].zip.
3. Запустим синхронизацию повторно. После того как один цикл обмена пройдет успешно с новыми именами, система запомнит их и будет работать стабильно.

Способ 2: Принудительный возврат к коротким префиксам

Если ваша инфраструктура завязана на жесткие имена файлов (например, используются скрипты для FTP или облачных хранилищ), вам может потребоваться вернуть старые префиксы УТ и БП. Поскольку вручную в карточке настройки это сделать невозможно, воспользуемся инструментами разработчика.

Алгоритм действий:

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

Важно: Эту процедуру необходимо выполнить в обеих информационных базах синхронно, чтобы коды «своего» узла и узла «корреспондента» совпадали в обеих системах.

Способ 3: Переинициализация через прямое подключение

Существует еще один практический способ «сбросить» некорректные идентификаторы, не прибегая к программированию. Разберем его по шагам:

1. В настройках синхронизации выберем пункт «Изменить параметры подключения».
2. Временно переключим способ обмена с «Файловый вариант (через каталог)» на «Прямое подключение к информационной базе» (через COM-соединение).
3. Укажем параметры доступа к базе-корреспонденту (адрес сервера, имя базы, логин и пароль).
4. Выполним один сеанс синхронизации. При прямом подключении системы обмениваются метаданными напрямую, и идентификаторы узлов часто синхронизируются автоматически.
5. После успешного завершения вернем настройки подключения обратно на «Синхронизация через файл».

Этот метод помогает «протолкнуть» зависшие настройки и заставить базы заново распознать друг друга.

Проанализируем последствия для ИТ-инфраструктуры

Принимая решение о том, оставлять GUID или возвращать префиксы, следует учитывать несколько технических нюансов. Рассмотрим их подробнее:

Длина пути (Path Limit): Использование GUID значительно удлиняет имя файла. Если папка обмена находится в глубокой иерархии подкаталогов (например, C:\Exchange\Sync\Production\FromUTtoBP\Messages\Message_...), вы можете столкнуться с ограничением Windows в 260 символов. В этом случае система выдаст ошибку «Файл не найден» или «Доступ запрещен».

Версия формата EnterpriseData: Часто переход на GUID провоцируется автоматическим повышением версии формата обмена (например, с 1.7 на 1.10). Если ваша конфигурация позволяет, можно попробовать в настройках синхронизации (раздел «Состав отправляемых данных») принудительно установить более старую версию формата, но это является временным решением и не рекомендуется при полноценной работе.

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

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