В модуле менеджера справочника "Номенклатура" пишем:
В обработчике - ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбраблтка) для нас важны все три параметра. В первый "ДанныеВыбора" мы загружаем наш список номенклатуры, полученный по нашему алгоритму. Из параметра "Параметры" мы получим значение введенное пользователем, а третьему параметру "СтандартнаяОбработка" мы должны поставить значение "Ложь"(отключаем стандартный алгоритм системы).
В результате одной небольшой процедурой мы полностью решили поставленную задачу.
СправочникМенеджер.<Имя справочника>.ПолучитьИмяПредопределенного (CatalogManager.<Имя справочника>.GetPredefinedItemName)
СправочникМенеджер.<Имя справочника> (CatalogManager.<Имя справочника>) ПолучитьИмяПредопределенного (GetPredefinedItemName)
Синтаксис:
Параметры: <Ссылка> (обязательный)
Тип: СправочникСсылка. Ссылка на элемент, имя которого требуется получить.Возвращаемое значение:
Тип: Строка.
Описание: Получает имя предопределенного элемента. Если данный элемент не является предопределенным, то возвращается пустая строка.
Доступность: Сервер, толстый клиент, внешнее соединение.
Пожалуй, начнем сразу с практического примера.
В справочник Контрагенты нам необходимо заносить информацию о поставщиках, покупателях, банках, налоговых органах, различных фондах и пр. Для каждого вида контрагента нас интересует разная информация.
Создадим функцию, возвращающую список «важных» реквизитов в зависимости от вида контрагента:
Где же ее правильнее разместить?
Напрашивается вариант - в процедуре Модуля объекта «ПередЗаписью()». Тем самым мы на этапе записи будем контролировать правильность заполнения нужных нам реквизитов. С точки зрения создания, изменения элемента справочника, нас все устраивает. Но если нам необходимо, чтобы некоторые менеджеры заносились контрагентов в ИБ без контроля, а спустя какое-то время мы будем выполнять проверку на корректность заполнения данных в справочнике. Тогда нужно будет написать обработку. И в этой обработке, перебирая элементы, проверять заполнение реквизитов. Т.о. эту функцию придется разместить в коде обработки. А это получается дублирование кода, со всеми вытекающими проблемами. Можно получать объект каждого элемента, обращаться к функции, расположенной в его Модуле объекта. Но это будет дополнительные обращения к БД, тогда как в обработке нам достаточно только ссылок.
Можно выйти из этой ситуации создав Общий модуль «РаботаСКонтрагентами» и разместить в нем функцию возвращающую список реквизитов для проверки. В этом случае будем обращаться так «РаботаСКонтрагентами.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Но! На платформе 8.2 как раз для решения подобной задачи и был создан Модуль менежера. Там и разместим нашу функцию. А обращаться мы будем: «Справочники.Контрагенты.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Т.о. на ряду с предопределенными методами, мы можем самостоятельно разработать свои процедуры и обращаться к ним как методам Менеджера объекта, через точку. У нас отпадает необходимость создавать «тематические» внешние модули такие как «Работа с Контрагентами», «Процедуры Номенклатуры»...
Обратимся теперь к теории, чтобы «разложить все по полочкам».
Руководство разработчика дает нам следующее описание: «Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность менеджеров за счет введения процедур и функций на встроенном языке. Фактически это позволяет описать методы для объекта конфигурации, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации». Именно это мы и разобрали в нашем практическом примере.
Отобразим иерархию классов прикладных объектов на примере Справочников:
Т.е. мы видим, что появление «Модуля менеджера объекта» логично расширяет свойства класса СправочникМенеджер, так же как экспортные процедуры «Модуля объекта» расширяют методы класса СправочникОбъект. Нужно ли было создавать «Модуль прикладного объекта Справочники (Документы, Перечисления)». Наверное нет. Достаточно трудно придумать какие-либо задачи для единой обработки всех видов справочников.
Кроме возможности расширения методов класса, в модуле менеджера существует предопределенная процедура События . Она возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода «ПолучитьДанныеВыбора()».
Так же хочу обратить внимание. При использовании конструктора печати прикладного объекта, платформа расположит процедуру формирования табличного документа непосредственно в Модуле менеджера. И это логично. Теперь, чтобы получить табличный документ элемента справочника нет необходимости получать объект. Достаточно кода: .
В данном примере запускается и инициализируется конфигурация 1С:Предприятие 8.0 с базой данных в каталоге D:\1CBasa.
Далее в программе 1С:Предприятие 8.0 создается объект типа "СправочникМенеджер.Товары" и создается новая группа элементов с названием "***** Экспорт из Excel ******".
Во вновь созданную группу каталога записываются данные из таблицы MS Excel.
Ввод по строке - поиск по первым символам или в любом месте наименования 
.gif)
Менеджеры пищат как дети на новогодней елке!