Почему не работает поиск в добавленном через расширение реквизите «Соглашение с клиентом» и как это исправить

← На главную

При доработке типовых конфигураций (таких как УТ 11, ERP или КА) через механизм расширений программисты часто сталкиваются с ситуацией, когда новый реквизит, добавленный в форму документа, ведет себя не совсем «стандартно». Одной из самых распространенных проблем является неработающий поиск по наименованию при вводе текста в поле (так называемый ввод по строке). Рассмотрим ситуацию: вы добавили реквизит СоглашениеСКлиентом в документ КоммерческоеПредложение, но при попытке набрать название соглашения система ничего не находит, хотя при нажатии «Показать все» нужный элемент прекрасно виден в списке.

В этой статье мы разберем, почему так происходит, проанализируем механизмы платформы 1С и предложим правильное программное решение для восстановления функциональности поиска.

Выясняем причину проблемы

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

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

Рассмотрим по шагам, как решить эту задачу с помощью переопределения обработчика в модуле менеджера.

Решение через обработчик ОбработкаПолученияДанныхВыбора

Основным инструментом для управления списком, который появляется под полем ввода при наборе текста, является процедура ОбработкаПолученияДанныхВыбора. Она располагается в модуле менеджера того объекта, который мы выбираем (в нашем случае — справочник СоглашенияСКлиентами).

Давайте проанализируем программный код, который позволит нам принудительно искать соглашения по введенной строке и возвращать их в форму документа.

Важное замечание: При написании кода в расширении необходимо использовать аннотацию &Перед, чтобы дополнить существующую логику, или &Вместо, если вы хотите полностью заменить типовой механизм.

Посмотрим на пример реализации в модуле менеджера справочника СоглашенияСКлиентами:


&Перед("ОбработкаПолученияДанныхВыбора")
Процедура Расш1_ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
    
    // Если поиск уже выполнен или строка поиска пустая, ничего не делаем
    СтрокаПоиска = "";
    Если Не Параметры.Свойство("СтрокаПоиска", СтрокаПоиска) Или ПустаяСтрока(СтрокаПоиска) Тогда
        Возврат;
    КонецЕсли;

    // Отключаем стандартный поиск платформы, так как будем формировать список сами
    СтандартнаяОбработка = Ложь;
    
    // Инициализируем список значений для результатов
    ДанныеВыбора = Новый СписокЗначений;

    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 30
        |	Соглашения.Ссылка КАК Ссылка,
        |	Соглашения.Наименование КАК Наименование
        |ИЗ
        |	Справочник.СоглашенияСКлиентами КАК Соглашения
        |ГДЕ
        |	Соглашения.Наименование ПОДОБНО &СтрокаПоиска
        |	И НЕ Соглашения.ПометкаУдаления";

    Запрос.УстановитьПараметр("СтрокаПоиска", "%" + СтрокаПоиска + "%");

    РезультатЗапроса = Запрос.Выполнить();
    Выборка = РезультатЗапроса.Выбрать();

    Пока Выборка.Следующий() Цикл
        // Добавляем найденные элементы в список выбора
        ДанныеВыбора.Добавить(Выборка.Ссылка, Выборка.Наименование);
    КонецЦикла;

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

Разбор критических ошибок в коде

Проанализируем типичные ошибки, которые допускают разработчики при реализации этого метода. В некоторых примерах на форумах можно встретить создание объекта Новый СписокЗначений внутри цикла Пока. Это грубейшая ошибка, так как на каждой итерации список будет очищаться, и в итоге пользователь увидит в поиске только один — самый последний — элемент из выборки.

Также важно всегда устанавливать параметр СтандартнаяОбработка = Ложь. Если этого не сделать, система после выполнения вашего кода запустит стандартный механизм поиска, который может либо перезаписать ваши ДанныеВыбора, либо выдать ошибку из-за конфликта параметров.

Использование связей параметров выбора

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

Если вы добавили реквизит в расширение, обязательно проверьте следующие параметры в свойствах этого реквизита на форме:

Найдите свойство Связи параметров выбора.
Убедитесь, что настроена связь по владельцу (обычно это Отбор.Партнер(Партнер)).
Если в документе есть организация, добавьте связь Отбор.Организация(Организация).

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

Проверка свойств метаданных

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

Ввод по строке: Убедитесь, что в списке полей для ввода по строке выбрано Наименование или Код.
Полнотекстовый поиск: Если в системе используется полнотекстовый поиск, проверьте, обновлен ли индекс. Иногда 1С использует индекс ПП для подбора данных в полях ввода, и если он не актуален, новые элементы не будут находиться до момента регламентного обновления индекса.

Продвинутый подход: Использование типовых процедур БСП

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

Это гарантирует, что все бизнес-правила (например, проверка даты окончания соглашения или его статуса «Действует») будут автоматически применены к вашему новому реквизиту. Рассмотрим, как это выглядит концептуально:


&Вместо("ОбработкаПолученияДанныхВыбора")
Процедура Расш1_ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
    // Вызываем типовой механизм, который уже умеет правильно фильтровать соглашения
    // с учетом всех контекстных настроек программы (УТ/ERP)
    ПродажиВызовСервера.ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка);
КонецПроцедуры

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