В практике разработчиков 1С периодически возникает ситуация, которую можно назвать "мистической": в отладчике мы видим два абсолютно одинаковых значения перечисления, но при их сравнении платформа возвращает Ложь. Рассмотрим подробнее, почему возникает эта проблема, проанализируем возможные причины и разберем по шагам действенные способы ее решения.
Самая частая причина описанного поведения кроется в механизмах кэширования платформы и последствиях динамического обновления. Выясним причину: когда конфигурация обновляется динамически, в памяти сервера и в клиентском сеансе могут остаться "старые" закэшированные типы метаданных.
В переменной вашего кода может храниться ссылка на старую версию метаданных (например, полученная из формы), а из базы данных извлекается уже новая версия. Визуально в табло отладчика это одно и то же значение с идентичным синонимом, но для внутреннего механизма 1С это совершенно разные объекты. Посмотрим, как это исправить:
Истина.Проанализируем ситуацию, если в вашей базе активно используются расширения (например, для интеграций, как Synchrozon). Если перечисление было заимствовано в расширение или его значения добавлялись там, может произойти рассинхронизация внутренних Уникальных Идентификаторов (GUID). Также важно вовремя проводить поиск заимствованных форм при обновлении основной конфигурации.
Платформа может создать условие, при котором значения идентичны по имени и синониму, но их GUID отличаются. Строгое сравнение в этом случае не сработает. Чтобы проверить корректность ссылок в базе, выполним простой запрос:
ВЫБРАТЬ
Перечисление.Ссылка КАК Ссылка
ИЗ
Перечисление.Ozon_ИдентификаторыРегламентныхЗаданий КАК Перечисление
Если запрос вернет дублирующиеся строки или значения, которые не соответствуют ожидаемым, вам необходимо перепроверить, как именно перечисление заимствовано в расширение, и при необходимости удалить дублирующие элементы.
Разберем еще один сценарий. При программной загрузке конфигурации, слиянии веток разработки или некорректной работе с расширениями в конфигураторе могут образоваться дубли. Два разных значения перечисления получают абсолютно идентичный Синоним (строковое представление, которое видит пользователь).
В отладчике они выглядят одинаково, но технически являются разными элементами коллекции. Для проверки истинного имени значения используйте функцию XMLСтрока. В табло отладчика введите:
XMLСтрока(ИдентификаторЗадания)
Эта функция вернет истинное системное имя значения (например, ОбновлениеОстатков). Если у двух визуально одинаковых значений возвращаются разные строки, значит, вы имеете дело с разными элементами метаданных с одинаковым синонимом.
Рассмотрим специфическую ситуацию при интеграциях. Если вы получаете значение перечисления из другой базы данных через COM-соединение или HTTP/веб-сервисы, прямое сравнение всегда даст Ложь.
Значение из другой базы является COM-объектом, и его внутренний идентификатор принадлежит другой информационной базе. Для корректного сопоставления значений из разных баз сравнивайте их по строковому представлению (имени) или используйте синхронизацию через XML-сериализацию. Пример правильного сравнения:
Если Строка(ЗначениеИзCOM) = Строка(ПредопределенноеЗначение("Перечисление.ИдентификаторыЗаданий.ОбновлениеОстатков")) Тогда
// Выполняем логику
КонецЕсли;
Обратим внимание на пустые значения. В табло отладчика пустая ссылка перечисления, Неопределено или NULL (из левого соединения в запросе) могут отображаться визуально пусто и не привлекать внимания. Однако сравнение пустой ссылки и значения Неопределено вернет Ложь. Всегда проверяйте тип значения с помощью функции ТипЗнч и явно обрабатывайте пустые ссылки с помощью функции ЗначениеЗаполнено.
Подведем итог: если в вашем коде одинаковые перечисления отказываются быть равными, в первую очередь очистите кэш и перезапустите сеанс без использования динамического обновления. Если проблема сохраняется, используйте XMLСтрока для поиска скрытых дублей и проверьте структуру заимствованных объектов в ваших расширениях.