Пожалуй, начнем сразу с практического примера.
В справочник Контрагенты нам необходимо заносить информацию о поставщиках, покупателях, банках, налоговых органах, различных фондах и пр. Для каждого вида контрагента нас интересует разная информация.
Создадим функцию, возвращающую список «важных» реквизитов в зависимости от вида контрагента:
Где же ее правильнее разместить?
Напрашивается вариант - в процедуре Модуля объекта «ПередЗаписью()». Тем самым мы на этапе записи будем контролировать правильность заполнения нужных нам реквизитов. С точки зрения создания, изменения элемента справочника, нас все устраивает. Но если нам необходимо, чтобы некоторые менеджеры заносились контрагентов в ИБ без контроля, а спустя какое-то время мы будем выполнять проверку на корректность заполнения данных в справочнике. Тогда нужно будет написать обработку. И в этой обработке, перебирая элементы, проверять заполнение реквизитов. Т.о. эту функцию придется разместить в коде обработки. А это получается дублирование кода, со всеми вытекающими проблемами. Можно получать объект каждого элемента, обращаться к функции, расположенной в его Модуле объекта. Но это будет дополнительные обращения к БД, тогда как в обработке нам достаточно только ссылок.
Можно выйти из этой ситуации создав Общий модуль «РаботаСКонтрагентами» и разместить в нем функцию возвращающую список реквизитов для проверки. В этом случае будем обращаться так «РаботаСКонтрагентами.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Но! На платформе 8.2 как раз для решения подобной задачи и был создан Модуль менежера. Там и разместим нашу функцию. А обращаться мы будем: «Справочники.Контрагенты.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».
Т.о. на ряду с предопределенными методами, мы можем самостоятельно разработать свои процедуры и обращаться к ним как методам Менеджера объекта, через точку. У нас отпадает необходимость создавать «тематические» внешние модули такие как «Работа с Контрагентами», «Процедуры Номенклатуры»...
Обратимся теперь к теории, чтобы «разложить все по полочкам».
Руководство разработчика дает нам следующее описание: «Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность менеджеров за счет введения процедур и функций на встроенном языке. Фактически это позволяет описать методы для объекта конфигурации, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации». Именно это мы и разобрали в нашем практическом примере.
Отобразим иерархию классов прикладных объектов на примере Справочников:
Т.е. мы видим, что появление «Модуля менеджера объекта» логично расширяет свойства класса СправочникМенеджер, так же как экспортные процедуры «Модуля объекта» расширяют методы класса СправочникОбъект. Нужно ли было создавать «Модуль прикладного объекта Справочники (Документы, Перечисления)». Наверное нет. Достаточно трудно придумать какие-либо задачи для единой обработки всех видов справочников.
Кроме возможности расширения методов класса, в модуле менеджера существует предопределенная процедура События . Она возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода «ПолучитьДанныеВыбора()».
Так же хочу обратить внимание. При использовании конструктора печати прикладного объекта, платформа расположит процедуру формирования табличного документа непосредственно в Модуле менеджера. И это логично. Теперь, чтобы получить табличный документ элемента справочника нет необходимости получать объект. Достаточно кода: .
Если регистр сведений подчинен регистратору, то для добавления записей в него необходимо создать набор записей этого регистра с установленным отбором по нужному регистратору, заполнить этот набор записей и записать его:
По умолчанию запись выполняется с замещением, т. е. существующие записи этого регистратора в регистре сведений будут удалены.
Для того чтобы добавить записи к существующим записям регистратора, необходимо указывать значение Ложь параметра метода Записать() набора записей. При этом необходимо позаботиться о том, чтобы значения измерений добавляемых записей были уникальны для записей данного регистратора в регистре сведений, иначе запись выполнена не будет:
В документе есть табличная часть вида
№ Инвентарная группа Январь Февраль Март Апрель ... и т.д.
1 Бумага 150 175 130 140 ...
1 Кантовары 50 15 30 27 ...
1 Хозтовары 10 29 37 60 ...
Нужно выгрузить табличную часть документа в Таблицу значений и загрузить в регистр сведений
Период Дата Подразделение Инвентарная группа Количество
01.01.2010 01.01.2010 Хоз. Отдел Бумага 150
01.01.2010 02.01.2010 Хоз. Отдел Бумага 175
01.01.2010 03.01.2010 Хоз. Отдел Бумага 130
...........................
01.01.2010 01.01.2010 Хоз. Отдел Кантовары 50
01.01.2010 02.01.2010 Хоз. Отдел Кантовары 15
01.01.2010 03.01.2010 Хоз. Отдел Кантовары 30
.....
и т.д
Для возведения числа в степень в 1С 8.х есть встроенная функция pow(основание, степень);
Возвращает результат возведения основания в указанную степень.
* основание: число
* степень: число
Модуль менеджера объекта 