Многие разработчики и пользователи сталкиваются с ситуацией, когда полнотекстовый поиск (ПП) в 1С ведет себя «нелогично»: поиск по буквенным строкам работает корректно, а при попытке найти контакт по части цифрового номера телефона система выдает результат только в том случае, если запрос совпадает с началом номера. Давайте разберем, почему так происходит и какие существуют пути решения этой задачи.
Чтобы понять, почему поиск работает именно так, нужно проанализировать, как ПП обрабатывает данные. Полнотекстовый поиск в платформе 1С реализован как система индексации «слов».
Когда вы вводите номер телефона, например, 8908123456, система для целей поиска разбивает эту строку на фрагменты. Разделителями слов в 1С выступают нецифровые и небуквенные символы: пробелы, точки, запятые, скобки и дефисы. Если номер записан как монолитная строка, платформа воспринимает его как единое «слово».
В алгоритме ПП заложено два жестких правила:
8908123456.Ситуация, когда поиск иногда «работает», а потом «ломается», объясняется регламентными заданиями Обновление индекса ППД и Слияние индекса ППД. До момента индексации динамический список может использовать другие механизмы выборки данных (например, обычный запрос к СУБД), которые поддерживают поиск по подстроке. Как только индекс актуализируется, поиск начинает идти через ПП, который строго следует правилам разбиения на слова.
Поскольку поведение ПП — это архитектурная особенность, изменить правила токенизации (разбиения на слова) внутри платформы невозможно. Рассмотрим варианты, которые позволят реализовать удобный поиск.
В 1С существует встроенный механизм поиска (вызываемый сочетанием клавиш Ctrl+F или Alt+F). Этот инструмент работает принципиально иначе: он обращается к СУБД напрямую.
Если для реквизита, по которому осуществляется поиск, в конфигураторе установлено свойство Индексировать в значение Индексировать, такой поиск будет работать эффективно. Он поддерживает поиск по части строки, так как под капотом используется SQL-оператор LIKE (в 1С это ПОДОБНО).
Рекомендация: Если ПП не является критически необходимым для всех справочников, его можно отключить для конкретных форм или объектов, где пользователи чаще всего ищут по частям номеров. Это вернет штатный быстрый поиск, который корректно обрабатывает частичное вхождение символов.
Если вы хотите сохранить работу ПП, можно попробовать изменить формат хранения номеров телефонов. Если записывать номер с разделителями, например: 8-908-123-45-67, платформа воспримет это не как одно целое слово, а как несколько последовательных слов: 8, 908, 123, 45, 67.
В этом случае при поиске по запросу «123» ПП обнаружит совпадение, так как «123» будет являться началом одного из проиндексированных «слов». Это самый «чистый» способ решения, который не требует отключения функций платформы и сохраняет производительность.
Для сложных форм (например, Контакты в УНФ) лучшим архитектурным решением является создание отдельного поля ввода для поиска. При вводе значения в это поле вы можете программно управлять тем, как именно 1С будет искать данные.
Проанализируем пример логики, которую можно применить в запросе к динамическому списку при поиске по части номера:
// Пример программного изменения текста запроса динамического списка
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ * ИЗ Справочник.КонтактныеЛица
ГДЕ Телефон ПОДОБНО &ПараметрПоиска";
Запрос.УстановитьПараметр("ПараметрПоиска", "%" + СтрокаПоиска + "%");
Использование оператора ПОДОБНО с добавлением символов % (процент) перед и после искомого значения позволяет находить номер в любом месте строки. Этот подход дает предсказуемый результат для пользователей и не зависит от регламентных заданий полнотекстового поиска.
Мы выяснили, что «некорректная работа» — это штатное поведение полнотекстового поиска в 1С. Чтобы обеспечить комфортную работу пользователей, проанализируйте ваши задачи:
Alt+F, убедившись, что реквизит проиндексирован в конфигураторе.Помните, что совместная работа стандартного поиска и настроенного индексирования реквизитов — это самый сбалансированный путь для высокой производительности в динамических списках.