1с как обратиться к общему макету

Обновлено: 07.07.2024

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

Создадим функцию, возвращающую список «важных» реквизитов в зависимости от вида контрагента:
Код 1C v 8.2 УП
Где же ее правильнее разместить?

Напрашивается вариант - в процедуре Модуля объекта «ПередЗаписью()». Тем самым мы на этапе записи будем контролировать правильность заполнения нужных нам реквизитов. С точки зрения создания, изменения элемента справочника, нас все устраивает. Но если нам необходимо, чтобы некоторые менеджеры заносились контрагентов в ИБ без контроля, а спустя какое-то время мы будем выполнять проверку на корректность заполнения данных в справочнике. Тогда нужно будет написать обработку. И в этой обработке, перебирая элементы, проверять заполнение реквизитов. Т.о. эту функцию придется разместить в коде обработки. А это получается дублирование кода, со всеми вытекающими проблемами. Можно получать объект каждого элемента, обращаться к функции, расположенной в его Модуле объекта. Но это будет дополнительные обращения к БД, тогда как в обработке нам достаточно только ссылок.

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

Но! На платформе 8.2 как раз для решения подобной задачи и был создан Модуль менежера. Там и разместим нашу функцию. А обращаться мы будем: «Справочники.Контрагенты.ПолучитьСписокВажныхРеквизитов(ВидКонтрагента)».

Т.о. на ряду с предопределенными методами, мы можем самостоятельно разработать свои процедуры и обращаться к ним как методам Менеджера объекта, через точку. У нас отпадает необходимость создавать «тематические» внешние модули такие как «Работа с Контрагентами», «Процедуры Номенклатуры».

Обратимся теперь к теории, чтобы «разложить все по полочкам».

Руководство разработчика дает нам следующее описание: «Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность менеджеров за счет введения процедур и функций на встроенном языке. Фактически это позволяет описать методы для объекта конфигурации, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации». Именно это мы и разобрали в нашем практическом примере.

Отобразим иерархию классов прикладных объектов на примере Справочников:

Т.е. мы видим, что появление «Модуля менеджера объекта» логично расширяет свойства класса СправочникМенеджер, так же как экспортные процедуры «Модуля объекта» расширяют методы класса СправочникОбъект. Нужно ли было создавать «Модуль прикладного объекта Справочники (Документы, Перечисления)». Наверное нет. Достаточно трудно придумать какие-либо задачи для единой обработки всех видов справочников.

Кроме возможности расширения методов класса, в модуле менеджера существует предопределенная процедура События Код 1C v 8.2 УП . Она возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода «ПолучитьДанныеВыбора()».

Так же хочу обратить внимание. При использовании конструктора печати прикладного объекта, платформа расположит процедуру формирования табличного документа непосредственно в Модуле менеджера. И это логично. Теперь, чтобы получить табличный документ элемента справочника нет необходимости получать объект. Достаточно кода: Код 1C v 8.2 УП .

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

Создание общего модуля в 1С

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

Справа откроются свойства добавленного общего модуля, и нам предстоит разобраться, что обозначает каждое из них. Они могут быть различной направленности, поэтому, перед тем как настраивать новый объект, желательно определиться, что мы там будем хранить. Если что, в будущем можно будет изменить свойства в соответствии с задачами:

«Глобальный». Данный флаг ставится, если модуль предназначен для хранения процедур и функций, которые должны вызываться без указания имени модуля. Естественно, они должны быть экспортными, а их имена уникальными в разрезе всего глобального контекста. По использованию они не будут отличаться от стандартных функций платформы;
«Клиент». Зависит от настроек системы и регламентирует, могут ли процедуры модуля выполняться на стороне клиента;
«Сервер». Помечаются общие модули, в составе которых планируется помещать алгоритмы для выполнения на сервере;
«Внешнее соединение». Процедуры модуля с активацией этого свойства смогут выполняться через подключение внешнего источника;
«Вызов сервера». Отвечает за разрешения процедурам из модуля вызывать сервер, выполняясь на клиенте;
«Привилегированный». Активация этой настройки позволит при работе кода процедур модуля не проверять права доступа. Вызвать общий модуль с такой настройкой можно только на сервере. Настройки «Клиент» и «Внешнее соединение» будут сброшены;
«Повторное использование». Может принимать значения: «Не использовать», «На время сеанса», «На время вызова». При многократном вызове одной процедуры система может использовать рассчитанные ранее данные в рамках процедуры (вызов) или жизни всего сеанса (запуска 1С). Стоит быть очень осторожным с этой настройкой, так как из-за неправильного использования таких модулей могут возникать ошибки.

Бывают ситуации, когда требуется создать общий модуль с вызовами процедуры на сервере и клиенте с отличиями в алгоритме. Для разграничения кода используются директивы препроцессора с проверкой. В результате для серверного вызова это будет один код, а для клиентского – другой.

Пример переноса кода в общий модуль 1С

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

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

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

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

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

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

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

Общий макет 1С - объект конфигурации 1С, предназначенный для формирования печатных форм электронных документов, и доступный из любого места конфигурации (разных программных модулей).

Общие макеты печатных форм располагаются в ветви "Общие" дерева конфигурации, в отличие от печатных форм объектов конфигурации (справочников, документов, журналов документов, планов счетов, планов видов характеристик, планов видов расчетов, регистров, отчетов и обработок и др.), которые располагаются в подчиненных объектах "Макеты", а также во внешних файлах (в этом случае должно быть установлено свойство табличного документа Макет ).

Макет объекта конфигурации "Справочники":

Таким образом, "Общие макеты" (шаблоны печатных форм) не принадлежат конкретному объекту конфигурации, и могут используются из разных программных модулей.

Типы макетов 1С:

Табличный документ – использование стандартной технологии создания и использования макетов: подготовка макета производится с помощью табличного редактора.
Текстовый документ – использование текстового документа в качестве макета: подготовка текстового макета производится с помощью редактора текстовых макетов.
Двоичные данные – используются двоичные данные.
ActiveDocument – использование технологии OLE Active document (документы Microsoft Office OpenXML не могут быть использованы в качестве макета ActiveDocument).
HTML-документ – использование редактора HTML-документа.
Географическая схема – использование в качестве макета географической схемы, подготовленной в редакторе географических схем.
Графическая схема – использование подготовленной в редакторе графической схемы.
Схема компоновки данных – использование схемы компоновки данных, подготовленной в конструкторе.
Макет оформления компоновки данных – предполагает использование макета оформления системы компоновки данных.
Внешняя компонента – хранение внешних компонент, используемых в мобильном или обычном прикладном решении.

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

Внешняя компонента поставляется в виде dll-библиотеки, и расширяет встроенный язык новыми методами.

При работе с внешней компонентой после программной загрузки объекты внешней компоненты подключаются к "1С:Предприятию 8".

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Читайте также: