Как исправить ошибку «Значение не является значением объектного типа (УникальныйИдентификатор)» при синхронизации данных в 1С?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Синхронизация данных между различными конфигурациями 1С — это сложный процесс, базирующийся на «Библиотеке стандартных подсистем» (БСП). Одной из наиболее неприятных ошибок, с которой сталкиваются разработчики при добавлении новых объектов в обмен, является сообщение: «Значение не является значением объектного типа (УникальныйИдентификатор)». Рассмотрим подробно, почему возникает эта проблема и как её решить различными способами.

Разбор причины возникновения ошибки

Проанализируем ситуацию: ошибка чаще всего возникает в момент загрузки данных в базу-приемник. Если мы заглянем в стек вызовов, то увидим, что проблема локализована в модуле набора записей регистра сведений СоответствияОбъектовИнформационныхБаз. В процедуре ПередЗаписью этого регистра система пытается выполнить следующий код:


ЭтотОбъект[0]["УникальныйИдентификаторИсточникаСтрокой"] = Строка(ЭтотОбъект[0]["УникальныйИдентификаторИсточника"].УникальныйИдентификатор);

Суть проблемы заключается в том, что поле УникальныйИдентификаторИсточника оказывается пустым (имеет значение Неопределено) или содержит значение, у которого нет метода УникальныйИдентификатор. Поскольку система ожидает объектный тип, а получает что-то иное, выполнение прерывается критической ошибкой.

Выясним основные сценарии, при которых это происходит:

  1. Объект не включен в состав плана обмена. Это самая распространенная причина. Даже если вы создали правила конвертации в «Конвертации данных» (КД 2.1), объект (справочник или документ) должен быть физически добавлен в состав используемого ПланаОбмена в метаданных конфигурации.
  2. Использование расширений. Если справочник добавлен через расширение, механизмы БСП не всегда могут корректно сопоставить типы данных, если расширение не интегрировано в логику обмена.
  3. Проблемы прямого подключения (COM). При синхронизации через прямое соединение передача ссылочных типов может давать сбои, если версии платформ или конфигураций различаются, что приводит к потере типизации идентификатора.
  4. Некорректная настройка «Поиска по ГУИД». В правилах конвертации объектов (ПКО) может быть включена опция поиска по уникальному идентификатору, но сам идентификатор не передается в XML-пакете или передается некорректно.

Решение 1: Проверка состава плана обмена

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

Выполним следующие действия:

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

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

Решение 2: Исправление правил конвертации (КД 2.1)

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

Попробуем изменить логику поиска:

  1. В ПКО соответствующего объекта снимем флаг поиска по ГУИД и оставим только поиск по полям (например, по Наименованию или Коду).
  2. Если синхронизация прошла успешно, значит, проблема была именно в передаче или интерпретации GUID источника.
  3. Проверим, передается ли свойство {УникальныйИдентификатор} в файле выгрузки. Для этого выгрузим данные в файл и откроем его текстовым редактором.

Решение 3: Работа с идентификаторами объектов метаданных

Иногда причина кроется в рассинхронизации справочника ИдентификаторыОбъектовМетаданных. БСП активно использует его для определения типов объектов при записи в регистр соответствий.

Посмотрим, как обновить эти данные:

  1. Запустим обработку ОбновлениеИнформационнойБазы.epf (входит в состав БСП) или выполним команду в консоли запросов/кода:
    
    Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Истина);
    
  2. Это актуализирует все типы объектов, включая добавленные в расширениях, и позволит регистру соответствий правильно определять тип УникальныйИдентификаторИсточника.

Решение 4: Программный обход регистрации соответствий

В некоторых случаях, особенно при работе со справочниками из расширений, которые не планируется постоянно синхронизировать по GUID, можно использовать программный способ. Рассмотрим совет из практики: использование специальных параметров в обработчиках КД.

В правилах конвертации объектов (ПКО), в обработчике ПриЗагрузке, мы можем указать системе, что не нужно записывать данные в регистр СоответствияОбъектовИнформационныхБаз. Это предотвратит вызов проблемного кода БСП.

Пример кода в обработчике ПриЗагрузке:


// Если объект не должен регистрироваться в таблице соответствий
// Это исключит попытку обращения к методу .УникальныйИдентификатор
Если Объект.ЭтоНовый() Тогда
    // Устанавливаем признак, чтобы БСП не пыталась создать запись в РС
    ДополнительныеСвойства.Вставить("МимоРегистраСоответствий", Истина);
КонецЕсли;

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

Решение 5: Отладка в режиме прямого соединения

Если вы используете COM-соединение, проанализируем ситуацию через отладку. Когда база-приемник подключается к базе-источнику, объект УникальныйИдентификатор передается как COM-объект. Если в базе-приемнике в этот момент происходит попытка записи в регистр, метод ТипЗнч() может вернуть некорректный результат из-за разницы контекстов.

Рекомендуется временно переключиться на обмен через XML-файл. Это позволит:

Итоги и рекомендации

Разберем краткий чек-лист для быстрой проверки при возникновении данной ошибки:

  1. Проверьте, что все участвующие в обмене справочники добавлены в План обмена.
  2. Убедитесь, что в ПКО (Правилах конвертации объектов) корректно настроены поля поиска.
  3. Запустите процедуру обновления идентификаторов метаданных.
  4. Если объект добавлен в расширении, убедитесь, что расширение имеет ту же версию и структуру в обеих базах.
  5. В крайнем случае используйте свойство МимоРегистраСоответствий в обработчиках загрузки, чтобы обойти проблемный участок кода БСП.

Соблюдение этих шагов позволит вам успешно завершить настройку синхронизации и избежать критических остановок процесса загрузки данных.

← На главную