Как правильно установить условие на элемент справочника в запросе 1С, если он не является предопределенным?

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

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

Способ 1. Использование параметров запроса

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


ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка,
    Номенклатура.Код КАК Код
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.Ссылка = &ЦелевойОбъект

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

Способ 2. Превращение элемента в предопределенный

Если логика конфигурации жестко завязана на конкретный элемент (например, «Основной склад» или «Розничный покупатель»), наиболее правильным решением будет зайти в Конфигуратор и создать для этого справочника предопределенный элемент. В этом случае в запросе мы сможем обращаться к нему через конструкцию ЗНАЧЕНИЕ(Справочник.ИмяСправочника.ИмяПредопределенного). Это гарантирует, что элемент не будет случайно удален пользователем, а ссылка на него всегда будет доступна в коде.

Способ 3. Использование констант или специальных справочников настроек

Если мы не хотим менять структуру конфигурации, добавляя предопределенные элементы, проанализируем вариант с использованием констант. Создадим константу (например, ОсновнойСкладОтчета), тип которой совпадает с нужным справочником. В пользовательском режиме один раз выберем нужный элемент. В запросе СКД мы сможем получить значение этой константы в качестве параметра. Рассмотрим пример программной установки параметра в модуле отчета:


Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
    Параметр = КомпоновкаДанныхНастройки.ПараметрыДанных.Элементы.Найти("Склад");
    Если Параметр <> Неопределено Тогда
        Параметр.Значение = Константы.ОсновнойСкладОтчета.Получить();
        Параметр.Использование = Истина;
    КонецЕсли;
КонецПроцедуры

Также можно завести отдельный справочник ОбщиеПараметры или НастройкиСистемы, где будут храниться ссылки на нужные объекты. Это особенно удобно, если таких «особенных» элементов много.

Способ 4. Использование регистра сведений для хранения настроек

Для более сложных случаев, когда настройки зависят от пользователя или конкретного отчета, создадим регистр сведений (например, НастройкиПользователей). Проанализируем структуру такого регистра:

  1. Измерение: Пользователь (СправочникСсылка.Пользователи)
  2. Измерение: Настройка (ПланВидовХарактеристикСсылка.НастройкиПользователей)
  3. Ресурс: Значение (Произвольный тип)

В запросе СКД мы сможем сделать левое соединение с этим регистром, чтобы автоматически подтягивать нужный элемент для текущего пользователя. Это самый гибкий подход для крупных систем.

Способ 5. Техническое решение через уникальный идентификатор (GUID)

Иногда необходимо гарантировать обращение к конкретному объекту без возможности его изменения пользователем, но при этом нельзя создавать предопределенный элемент. В таком случае разберем использование GUID. Каждый объект в 1С имеет уникальный идентификатор, который не меняется. Мы можем получить ссылку по этому идентификатору:


Идентификатор = Новый УникальныйИдентификатор("550e8400-e29b-41d4-a716-446655440000");
СсылкаНаОбъект = Справочники.Склады.ПолучитьСсылку(Идентификатор);

Этот метод надежнее поиска по коду, так как код (строку) пользователь может отредактировать, а GUID остается неизменным на протяжении всей «жизни» объекта.

Способ 6. Использование механизмов БСП (Дополнительные реквизиты и сведения)

В современных типовых конфигурациях (ERP, УТ 11, БП 3.0) реализован механизм дополнительных реквизитов. Посмотрим, как это помогает решить нашу задачу. Мы можем создать дополнительное сведение для справочника, назвать его «СлужебныйОбъект» и установить значение Истина для нужного элемента. В запросе условие будет выглядеть так:


ВЫБРАТЬ
    Номенклатура.Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.Ссылка В (
        ВЫБРАТЬ Объекты.Объект 
        ИЗ РегистрСведений.ДополнительныеСведения КАК Объекты 
        ГДЕ Объекты.Свойство = &СвойствоСлужебныйОбъект И Объекты.Значение = ИСТИНА
    )

Способ 7. Сегментация (для ERP и УТ)

Для справочников Номенклатура или Партнеры в крупных системах предусмотрен механизм сегментов. Вместо фильтрации по конкретной ссылке, мы можем создать сегмент (например, «Товары для спец. отчета») и добавить в него нужные позиции. В запросе СКД соединение с таблицей НоменклатураВСегменте позволит динамически менять список объектов без изменения самого запроса.

Резюме и рекомендации

Подведем итог нашему анализу. Выбор метода зависит от архитектуры вашей задачи:

Использование предложенных методов позволит вам создавать гибкие и надежные решения, соответствующие стандартам разработки 1С.

← На главную