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

Разработчики, начинающие изучать управляемые формы в 1С, часто сталкиваются с неочевидным поведением стандартных механизмов платформы. Типичная ситуация: в справочнике созданы реквизиты Артикул и Комментарий, настроено их индексирование, включен полнотекстовый поиск и даже задан «Ввод по строке». При этом в документе автоподбор по артикулу работает идеально, а вот в самом списке справочника стандартный поиск упорно игнорирует эти поля, предлагая искать только по коду и наименованию. В этой статье мы подробно разберем, почему так происходит, как устроены поисковые механизмы платформы 1С v8.3 и как обойти существующие ограничения интерфейса.

Выясняем причину: почему стандартный поиск «не видит» реквизиты?

Основная причина такого поведения кроется в базовом алгоритме работы динамического списка. По умолчанию стандартный поиск в управляемых формах (как через поисковую строку в шапке списка, так и через окно «Найти») анализирует исключительно те колонки, которые выведены на форму и видимы пользователю в данный момент.

Если колонка с реквизитом отсутствует на форме или для элемента формы установлено свойство Видимость = Ложь, платформа оптимизирует передачу данных: она перестает считывать эти значения с сервера и полностью исключает их из индекса клиентского поиска. Именно поэтому стандартное окно «Расширенный поиск» в поле «Где искать» отображает только те реквизиты, колонки которых физически видны на экране.

В чем разница между «Вводом по строке» и поиском в списке?

Часто возникает путаница из-за того, что в полях ввода документов поиск по артикулу работает без проблем. Давайте разберем по шагам, почему это разные механизмы:

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

Зачем нужен флаг «Использовать всегда»?

В процессе решения этой проблемы разработчики часто пробуют установить свойство Использовать всегда (UseAlways) для нужного реквизита в схеме компоновки данных или в списке полей динамического списка. Однако сам по себе этот флаг проблему с поиском не решает. Назначение этого свойства совершенно иное:

• Оно сообщает платформе, что значение данного поля необходимо обязательно получать из базы данных и передавать на клиент, даже если колонка физически не добавлена в таблицу формы.
• Это крайне необходимо для обращения к данным текущей строки в коде на клиенте (например, через конструкцию Элементы.Список.ТекущиеДанные.ИмяРеквизита) без вызова контекста сервера.
• Также этот флаг используется, когда поле нужно задействовать в условиях условного оформления, но саму колонку выводить пользователю не требуется.

Лайфхак: как искать по реквизиту, не показывая его на форме

Что делать, если вам критически важно обеспечить поиск, например, по реквизиту Артикул или Комментарий, но перегружать интерфейс лишними колонками нельзя? Существует элегантное решение, позволяющее обмануть платформу и заставить её индексировать невидимые визуально данные.

Разберем алгоритм настройки по шагам:

1. Откройте форму списка справочника в конфигураторе.
2. Перетащите нужный реквизит (например, Артикул) из списка полей динамического списка в элементы таблицы формы. Теперь он стал колонкой.
3. Убедитесь, что для этого поля в свойствах динамического списка (на уровне схемы компоновки или свойств поля списка) установлен флаг «Использовать всегда».
4. Перейдите в свойства динамического списка и откройте настройку Условного оформления (либо сделайте это программно при создании формы).
5. Создайте новый элемент условного оформления:
   • Вкладка «Оформление»: установите флажок Видимость в значение Ложь.
   • Вкладка «Оформляемые поля»: выберите наше поле (например, Артикул).
   • Вкладка «Условие»: оставьте пустой (оформление должно применяться всегда).

При таком подходе платформа считает колонку технически «активной» и участвующей в компоновке данных на клиенте, поэтому стандартный поиск будет без проблем находить по ней данные. При этом благодаря условному оформлению пользователь визуально колонку на форме не увидит.

Ниже рассмотрим пример того, как настроить такое скрытие программно в модуле формы, чтобы не загромождать настройки в конфигураторе:

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)

    // Программное добавление элемента условного оформления для скрытия колонки Артикул
    ЭлементОформления = Список.УсловноеОформление.Элементы.Добавить();
    ЭлементОформления.Оформление.УстановитьЗначениеПараметра("Видимость", Ложь);
    
    ПолеОформления = ЭлементОформления.Поля.Элементы.Добавить();
    ПолеОформления.Поле = Новый ПолеКомпоновкиДанных("Артикул");
    
    // Условие оставляем пустым, чтобы скрытие работало для всех строк
    ЭлементОформления.Использование = Истина;

КонецПроцедуры

Влияние полнотекстового поиска (ППС) на производительность списков

При настройке поиска по дополнительным реквизитам важно понимать, как именно платформа осуществляет поиск физически в базе данных. Здесь есть два принципиально разных сценария:

1. Поиск с использованием индексов ППС (быстрый поиск). Если для справочника в метаданных включен полнотекстовый поиск, а индексы ППС регулярно обновляются (например, настроено регламентное задание ОбновлениеИндексаППС), то при вводе запроса в строку поиска динамического списка платформа обращается к индексу полнотекстового поиска. Это происходит мгновенно даже в базах с миллионами записей.
2. Поиск без использования ППС (медленный поиск). Если ППС отключен или индексы не актуализированы, платформа вынуждена генерировать тяжелый SQL-запрос со множеством условий LIKE '%СтрокаПоиска%' ко всем доступным текстовым колонкам. На больших таблицах это гарантированно приводит к полной загрузке процессора сервера СУБД, блокировкам таблиц и зависанию интерфейса у пользователей.

Важная особенность ППС: полнотекстовый поиск по умолчанию настроен на поиск совпадений с начала слов. Если ваш артикул имеет вид "123456", а пользователь пытается найти его по подстроке "345", стандартная строка поиска через ППС может ничего не вернуть. В таких ситуациях пользователям следует рекомендовать использовать механизм «Расширенного поиска» (вызывается по кнопке Alt+F или Ctrl+F), который переводит поиск в режим точного сканирования подстроки.

Резюме для правильной настройки поиска

Для того чтобы предоставить пользователям удобный и быстрый поиск по любым реквизитам в динамических списках, придерживайтесь следующего чек-листа:

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