При разработке или адаптации внешних обработок (например, от операторов ЭДО, таких как СБИС) программисты часто сталкиваются с ситуацией, когда в тексте запроса фигурирует таблица ЗначенияСвойствОбъектов, но при попытке найти такой объект в дереве метаданных конфигурации (например, в «Управлении нашей фирмой» или «ERP») поиски не дают результата. Рассмотрим детально, почему так происходит, как устроена логика подобных запросов и как правильно адаптировать их под свои нужды.
Первое, что нам необходимо проанализировать — это синтаксис самого запроса. В языке запросов 1С существует возможность назначать таблицам и полям временные имена, называемые псевдонимами (алиасами). Это делается с помощью ключевого слова КАК. Выясним причину путаницы: в современных конфигурациях, построенных на базе БСП (Библиотеки стандартных подсистем), данные о дополнительных реквизитах и сведениях хранятся в регистре сведений ДополнительныеСведения.
Однако в более старых редакциях программ (например, в «Управлении торговлей 10.3» или «УПП») аналогичный регистр назывался именно ЗначенияСвойствОбъектов. Разработчики интеграционных решений часто используют старое название в качестве псевдонима, чтобы сохранить преемственность кода или сделать его более привычным для себя. Разберем фрагмент кода, который вызывает вопросы:
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДополнительныеСведения КАК ЗначенияСвойствОбъектов
ПО РасходнаяНакладная.Контрагент = ЗначенияСвойствОбъектов.Объект
В данном случае реальным объектом метаданных в вашей базе является РегистрСведений.ДополнительныеСведения, а ЗначенияСвойствОбъектов — это всего лишь «прозвище», которое используется далее в тексте запроса. Если вы копируете такой запрос в консоль запросов, и она выдает ошибку, убедитесь, что в вашей конфигурации действительно существует регистр ДополнительныеСведения.
Проанализируем структуру типового запроса, который используется для получения данных о документах и их статусах в системе СБИС. Этот запрос решает сразу несколько задач: сбор данных о накладных, проверку способов доставки и получение текущего статуса электронного документооборота.
Рассмотрим пошагово, как строится выборка данных:
Документ.РасходнаяНакладная. Результат помещается во временную таблицу ВТ_Реализация для последующей обработки.ДополнительныеСведения, но уже ищет запись, где в поле Объект указана ссылка на сам документ, а в поле Свойство — значение «ДокументСБИС_Статус».Посмотрим на пример реализации такого соединения в коде:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
РасходнаяНакладная.Ссылка КАК Документ,
ЗначенияСвойствОбъектов.Значение КАК СпособДоставки
ПОМЕСТИТЬ ВТ_Реализация
ИЗ
Документ.РасходнаяНакладная КАК РасходнаяНакладная
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДополнительныеСведения КАК ЗначенияСвойствОбъектов
ПО РасходнаяНакладная.Контрагент = ЗначенияСвойствОбъектов.Объект
И ЗначенияСвойствОбъектов.Свойство.Наименование = "СБИС_СпособДоставки"
ГДЕ
РасходнаяНакладная.Дата МЕЖДУ &ДатаНач И &ДатаКон
В механизме дополнительных сведений ключевую роль играет План видов характеристик (ПВХ), который обычно называется ДополнительныеРеквизитыИСведения. Именно в нем хранятся настройки: какие свойства могут быть у конкретного типа объектов (документов или справочников).
Обратим внимание на критическую деталь в условии соединения: ЗначенияСвойствОбъектов.Свойство.Наименование = "СБИС_СпособДоставки". С точки зрения производительности 1С — это «антипаттерн» (плохая практика). Поиск по строковому наименованию через точку от поля Свойство заставляет систему выполнять дополнительные соединения с таблицей ПВХ и замедляет выполнение запроса на больших объемах данных.
Рекомендация: Если вы адаптируете запрос для своей конфигурации, лучше заранее найти ссылку на нужное свойство программным способом и передать её в запрос как параметр:
// Пример на языке 1С для подготовки параметра
СвойствоСсылка = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("СБИС_СпособДоставки");
Запрос.УстановитьПараметр("СвойствоСпособДоставки", СвойствоСсылка);
И затем в запросе использовать условие:
И ЗначенияСвойствОбъектов.Свойство = &СвойствоСпособДоставки
Если вы работаете в конфигурации, где нет БСП (например, самописная база или специфическое отраслевое решение типа «Аренда»), то регистра ДополнительныеСведения там может не оказаться вовсе. В этом случае запрос из внешних обработок работать не будет.
Проанализируем возможные пути решения этой проблемы:
Объект (тип ЛюбаяСсылка) и Свойство (тип ПланВидовХарактеристик или Справочник), а также ресурс Значение.ЛЕВОЕ СОЕДИНЕНИЕ так, чтобы оно обращалось к вашим реальным таблицам.Интересная ситуация возникает, когда конструктор запросов открывается и корректно отображает таблицу, которой якобы нет. Выясним причину: это происходит потому, что обработка была открыта в контексте базы, где этот регистр существует в метаданных, но, возможно, скрыт от глаз пользователя в интерфейсе или находится в другой ветке дерева объектов.
Если вы видите таблицу в правой части конструктора запросов (в списке доступных таблиц), значит, объект РегистрСведений.ДополнительныеСведения в системе есть. Если же вы копируете текст запроса в пустую консоль в другой базе, где этот регистр отсутствует, конструктор выдаст ошибку «Таблица не найдена». Всегда проверяйте физическое наличие объекта ДополнительныеСведения в ветке «Регистры сведений» вашей конфигурации перед началом работы с запросом.
Резюмируем: При работе с запросами СБИС и аналогичными системами, всегда помните, что ЗначенияСвойствОбъектов — это лишь алиас для ДополнительныеСведения. Используйте правильные ссылки на свойства вместо поиска по наименованию и всегда проверяйте наличие БСП-объектов в вашей текущей базе данных.