При обновлении современных конфигураций 1С, таких как Управление торговлей 11, Бухгалтерия предприятия 3.0 или Управление нашей фирмой, многие технические специалисты сталкиваются с неожиданным поведением системы. В настройках синхронизации данных, а именно в поле Код узла плана обмена, вместо привычных коротких префиксов (например, "УТ" или "БП") появляется длинная строка символов — уникальный идентификатор (GUID). Рассмотрим подробно, почему это происходит, является ли это ошибкой и как обеспечить стабильную работу обмена в таких условиях.
Проанализируем техническую подоплеку изменений. Данное новшество связано с развитием Библиотеки стандартных подсистем (БСП), начиная с версий 3.0 и выше. Фирма 1С планомерно переводит механизмы обмена данными на использование глобальных уникальных идентификаторов вместо коротких префиксов. Выясним, зачем это потребовалось:
1C:Fresh или крупных распределенных системах тысячи информационных баз могут участвовать в обменах. Короткие двух- или трехзначные префиксы неизбежно начинают дублироваться, что приводит к коллизиям и невозможности однозначно идентифицировать отправителя или получателя сообщения.GUID гарантирует, что каждый узел обмена уникален во всей экосистеме 1С. Это предотвращает ситуации, когда база ошибочно принимает сообщение, предназначенное для другого узла с таким же префиксом.Важно понимать, что это изменение часто инициируется автоматически при выполнении обработчиков обновления конфигурации. Если вы обновили одну из баз, подсистема обмена может «мигрировать» старый код на новый формат, что и вызывает недоумение при сравнении с архивными копиями.
Посмотрим на ситуацию со стороны протокола обмена. Синхронизация через Универсальный формат (EnterpriseData) изначально проектировалась как независимая от структуры метаданных конкретных конфигураций. Идентификатор узла передается в заголовке XML-файла сообщения обмена.
Проблема возникает тогда, когда одна база (уже обновленная) отправляет сообщение с длинным кодом в заголовке, а вторая база (со старым релизом) ожидает увидеть там короткий префикс. В этом случае мы можем столкнуться с ошибкой: Ошибка проверки данных XDTO: Структура объекта не соответствует типу. Это происходит из-за того, что в старых версиях планов обмена длина поля Код могла быть жестко ограничена (например, 9 символами), и 36-символьный GUID просто не проходит валидацию по схеме XDTO.
Рассмотрим самый правильный путь решения проблемы — синхронное обновление. Поскольку переход на идентификаторы является целевой архитектурой 1С, рекомендуется:
В актуальных релизах механизмы обмена уже "научены" работать с длинными кодами, и визуальное наличие GUID в поле кода не будет мешать передаче данных. Система сама сопоставит узлы по внутренним идентификаторам.
Если оперативно обновить одну из баз невозможно (например, из-за большого количества доработок), проанализируем вариант ручного возврата к префиксам. Посмотрим, как это реализовать с помощью стандартных инструментов:
Для восстановления работоспособности можно воспользоваться обработкой «Групповое изменение реквизитов». Выполним следующие шаги:
Групповое изменение реквизитов (обычно доступна в разделе Администрирование — Обслуживание — Корректировка данных).СинхронизацияДанныхЧерезУниверсальныйФормат).Код.Изменить реквизиты.Внимание: Эту процедуру необходимо провести в обеих базах так, чтобы коды узлов "смотрели" друг на друга корректно. То есть в Базе А код "этого узла" должен совпадать с кодом получателя в Базе Б, и наоборот.
Если вы хотите убедиться, какие именно коды установлены в системе, можно воспользоваться простым фрагментом кода в обработке Консоль кода или создать внешнюю обработку:
// Проанализируем коды узлов плана обмена
План = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат;
Выборка = План.Выбрать();
Пока Выборка.Следующий() Цикл
Сообщить("Наименование: " + Выборка.Наименование);
Сообщить("Код узла: " + Выборка.Код);
Если Выборка.Ссылка = План.ЭтотУзел() Тогда
Сообщить("--- Это текущая база ---");
КонецЕсли;
КонецЦикла;
Этот код позволит быстро выяснить, где именно произошла подмена префикса на идентификатор. Если вы видите строку вида {a1b2c3d4-e5f6-...}, значит, ваша база уже перешла на новые стандарты идентификации БСП.
Почему иногда синхронизация продолжает работать с GUID, а иногда "падает" с ошибкой? Проанализируем ситуацию: всё зависит от версии схемы EnterpriseData и того, как описан тип заголовка сообщения в конкретной конфигурации. В некоторых случаях 1С использует пакет ExchangeMessage, где поле Recipient (Получатель) имеет тип string без ограничения длины. В других случаях накладывается ограничение.
Если вы столкнулись с ошибкой валидации, попробуйте следующее:
Общей настройке узлов информационных баз, так как система может пытаться комбинировать их с кодами узлов.Мы выяснили, что появление уникальных идентификаторов вместо префиксов — это не баг, а фича последних версий платформы и БСП. Это необходимо для обеспечения глобальной уникальности узлов в сложных распределенных системах. Если ваш обмен работает стабильно, не стоит пытаться вернуть префиксы обратно — 1С будет все чаще использовать именно GUID.
Если же обмен прервался, наиболее надежным решением будет обновление конфигураций. В качестве временной меры используйте групповое изменение реквизитов для возврата кодов к прежнему виду. Помните, что при следующем обновлении система может снова попытаться заменить их на идентификаторы, поэтому планируйте переход на актуальные релизы заранее.