Правила создания общих модулей. Общие модули Что такое модуль в 1с

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

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

Каждый отдельный программный модуль воспринимается системой как единое целое, поэтому все его процедуры и функции принадлежат единому контексту.

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

Каждый программный модуль связан с остальной частью конфигурации задачи. Эта связь называется контекстом выполнения модуля. Контекст – это совокупность программных объектов и величин, доступных для использования (иначе говоря, «видимых») при исполнении модуля.

Принято различать два контекста:

Глобальный контекст задачи;

Локальный контекст выполнения конкретного модуля.

Объекты и величины, относящиеся к глобальному контексту задачи, доступны всем остальным модулям конфигурации. Иными словами, глобальный контекст определяет общую языковую среду исполнения программ учетной задачи.

Глобальный контекст составляют:

Значения системных атрибутов, общесистемные процедуры и функции;

Значения заданных в Конфигураторе констант, перечислений, регистров, видов расчета, групп видов расчета;

Переменные, процедуры и функции глобального программного модуля, объявленные с ключевым словом Экспорт .

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

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

Локальный контекст «виден» только определенному программному модулю и устанавливает для модуля набор непосредственно доступных ему значений агрегатных типов данных, а также их методов и атрибутов. Однако имеется возможность передачи контекста модуля как объекта в виде параметра при вызове процедур и функций. Контекст модуля определяет тот набор методов, которые являются доступными только в данном контексте. Например, на рис. 3.1 был дан краткий фрагмент модуля формы, в котором описывается процедура, выполняемая при открытии окна отдельно взятого документа. Другие модули работают с иными контекстами и выполняют иные функции.

Приведем таблицу, в которой перечислим все виды программных модулей, а кроме того, такие важнейшие их атрибуты, как расположение в дереве метаданных и момент выполнения (запуска), затем кратко проанализируем таблицу и охарактеризуем контекст каждого из них.

Таблица 3.1 – Виды программных модулей 1С: Предприятие

Продолжение таблицы 3.1

	Наименование модуля	Расположение	Запуск
	Модуль формы элемента справочника	Метаданные ® Справочник ® Форма	Запускается при открытии формы элемента справочника
	Модуль формы документа	Метаданные ® Документ ®Форма	Запускается при открытии формы документа
	Модуль документа	Метаданные ® Документ ® Модуль документа	Запускается при проведении документа, при удалении проведенного документа из журнала, при снятии проведения, при выполнении архивации записей журнала расчетов, порожденных этим документом
	Модуль формы журнала документов	Метаданные ® Журнал документов ® Форма	Запускается при открытии формы журнала документов
Модуль формы журнала расчетов	Метаданные ® Журнал расчетов ® Форма	Запускается при вызове формы журнала расчетов
Модуль формы списка счетов (плана счетов)	Метаданные ® План счетов	Запускается при вызове формы списка счетов
Модуль формы счета	Метаданные ® Планы счетов ® Форма счета	Запускается при открытии формы счета
Модуль формы журнала операций	Метаданные ® Журнал операций ® Форма
Модуль формы операции	Метаданные ® Операция	Запускается при вызове формы журнала операций
Модуль формы журнала проводок	Метаданные ® Журнал проводок ® Форма	Запускается, при вызове формы журнала проводок
Модуль формы отчета	Метаданные ® Отчет ® Форма	Запускается при открытии диалоговой формы подготовки отчета
Модуль формы обработки	Метаданные ® Обработка ® Форма	Запускается при открытии диалоговой формы обработки
Модуль вида расчета	Метаданные ® Вид расчета ® Модуль вида расчета	Запускается при расчете соответствующих записей журнала расчетов

Из таблицы следует, что фактически существуют два типа модулей: модуль формы объекта и модуль объекта. Глобальный модуль уже был рассмотрен.

Модуль формы объекта изначально служит для достижения двух основных целей: описания алгоритма взаимодействия объекта с пользователем и формирования того или иного печатного представления объекта. Некоторые из этих алгоритмов для какого-то объекта могут и отсутствовать. Но это только два общих, так сказать, глобальных предназначения таких модулей. Кроме этого, в модулях форм можно, конечно же, работать с информацией из справочников, констант, анализировать состояние бухгалтерских итогов и т.д. Модули формы существуют практически для всех типов объектов.

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

Любая программа состоит из программного кода, то есть собственно из написанных на каком-либо языке последовательности действий, которые должны быть выполнены.

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

Где пишется программа 1С?

Что такое Модуль 1С?

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

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

Каждый объект 1С, включая некоторые вложенные, имеет свой Модуль – некий текстовый файл, который содержит программный код.

Также есть независимые от объектов модули, в которых может быть написан программный код, независимый от конкретного объекта.

Таким образом в 1С нет «единой» программы. Есть набор модулей для написания программного кода для каждого объекта конфигурации 1С.

Как используются Модули 1С?

Всю программу можно грубо поделить на два вида:

Метод объекта
Реакция на события.

Методы . Как мы уже говорили ранее – объект 1С является цельной структурой, которая включает в себя как данные, так и способы их обработки. Эти способы – это набор действий (методов), которые можно вызывать для обработки данных. Пример такого действия СправочникОбъект.Записать() – записывает элемент справочника в базу данных.

Методы многих объектов 1С могут быть стандартными (т.е. запрограммированными в платформе 1С) и написанными программистом на языке 1С. С помощью вторых – можно расширять функционал объектов 1С по своему желанию.

События . События есть во множестве других средств разработки. Цель программы не только что-то вычислить при запуске, но и поддерживать работу пользователя.

Пользовательское события – пользователь нажал кнопку. В ответ какая-то часть кода выполнится, осуществив реакцию на действия пользователя.

Системные события – мы записали объект 1С в базу данных. Возникло системное событие «Запись объекта». Возможно настроить реакцию, которая возникнет на события, вызванные не пользователем (которые нажал на кнопку или что-то еще сделал), а самой системой. Яркий пример такого события – при запуске программы.

Порядок выполнения модулей 1С

Во многих языках есть такое понятие как «точка входа». Это та самая первая строчка или функция которая будет выполнена при запуске программы.

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

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

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

Работа с модулями 1С

Производится в конфигураторе. Открыть модуль можно с помощью окна Конфигурация.

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

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

В статье рассмотрим принципиальные различия между этими модулями как с теоретической стороны, так и на конкретном практическом примере.

Теория

Обратимся к основам объектно-ориентированного программирования (ООП) и проведем аналогию с нашим примером. В ООП методы для объектов можно разделить на статические (static) и простые . Простые методы могут быть вызваны только для конкретного объекта, доступ к которому мы имеем в текущем контексте программного кода. Статические методы не имеют непосредственного доступа к данным объектов. Для обращения к объекту первоначально нужно создать его экзмемпляр. То же самое относится к платформе 1С:Предприятие 8.x.

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

От теории перейдем к практике.

Практика

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

Процедура печати в модуле объекта

В модуле объекта справочника добавим следующую функцию:

// В функцию передаем ссылку на элемент справочника Функция ПечатьВыбранныхТоваров(Ссылка) Экспорт ТабДок = Новый ТабличныйДокумент; Макет = Справочники. Товары. ПолучитьМакет(" Макет " ) ; Запрос = Новый Запрос; Запрос. Текст = " ВЫБРАТЬ | Товары. Представление КАК Товар, | Товары. ПометкаУдаления, | Товары. Артикул |ИЗ | Справочник. Товары КАК Товары |ГДЕ | Товары. Ссылка В(& МассивТоваров) " ; Запрос. УстановитьПараметр(" МассивТоваров " , Ссылка) ; //Ставим отбор по ссылке

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

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

& НаКлиенте Процедура Печать(Команда) // Обращаемся к серверной процедуре для получения сформированного табличного документа ТабДок = ПечатьСервер() ; // Показываем сформированный табличный документ ТабДок. Показать() ; КонецПроцедуры & НаСервере Функция ПечатьСервер() // Конвертируем объект формы в объект справочника "Товары" для вызова функции из модуля объекта ОбъектТовар = РеквизитФормыВЗначение(" Объект " ) ; // Вызываем процедуру модуля объекта, передав туда ссылку на текущий элемент справочника. Результат // возвращаем на клиентскую часть Возврат ОбъектТовар. ПечатьВыбранныхТоваров(Объект. Ссылка) ; КонецФункции

Таким образом, мы распечатали текущий элемент справочника, работая с его объектом. Но в задаче было сказано распечатать список товаров, которые пользователь сам должен выбрать. При работе с объектом дать пользователю такую возможность простым путем не представляется возможным. Наиболее правильно было бы выполнять печать из списка элементов справочника "Товары".

Процедура печати в модуле менеджера

В модуль менеджера справочника добавим следующую экспортную процедуру:

// Передаем массив ссылок на товары Функция ПечатьВыбранныхТоваров(МассивТоваров) Экспорт ТабДок = Новый ТабличныйДокумент; Макет = Справочники. Товары. ПолучитьМакет(" Макет " ) ; Запрос = Новый Запрос; Запрос. Текст = " ВЫБРАТЬ | Товары. Представление КАК Товар, | Товары. ПометкаУдаления, | Товары. Артикул |ИЗ | Справочник. Товары КАК Товары |ГДЕ | Товары. Ссылка В(& МассивТоваров) " ; Запрос. УстановитьПараметр(" МассивТоваров " , МассивТоваров) ; // Устанавливаем отбор по массиву Результат = Запрос. Выполнить () ; ОбластьЗаголовок = Макет. ПолучитьОбласть(" Заголовок " ) ; ОбластьПодвал = Макет. ПолучитьОбласть(" Подвал " ) ; ОбластьШапкаТаблицы = Макет. ПолучитьОбласть(" ШапкаТаблицы " ) ; ОбластьПодвалТаблицы = Макет. ПолучитьОбласть(" ПодвалТаблицы " ) ; ОбластьДетальныхЗаписей = Макет. ПолучитьОбласть(" Детали " ) ; ТабДок. Очистить() ; ТабДок. Вывести(ОбластьЗаголовок) ; ТабДок. Вывести(ОбластьШапкаТаблицы) ; ТабДок. НачатьАвтогруппировкуСтрок() ; ВыборкаДетальныеЗаписи = Результат. Выбрать() ; Пока ВыборкаДетальныеЗаписи. Следующий() Цикл ОбластьДетальныхЗаписей. Параметры. Заполнить(ВыборкаДетальныеЗаписи) ; ТабДок. Вывести(ОбластьДетальныхЗаписей, ВыборкаДетальныеЗаписи. Уровень() ) ; КонецЦикла ; ТабДок. ЗакончитьАвтогруппировкуСтрок() ; ТабДок. Вывести(ОбластьПодвалТаблицы) ; ТабДок. Вывести(ОбластьПодвал) ; Возврат ТабДок; КонецФункции

Главное отличие от функции в модуле объекта - это параметр функции. Теперь в качестве параметра передается массив с ссылками на товары, которые необходимо распечатать.

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

& НаКлиенте Процедура Печать(Команда) ТабДок = ПечатьСервер() ; ТабДок. Показать() ; КонецПроцедуры & НаСервере Функция ПечатьСервер() // Передаем массив ссылок выделенных товаров в списке справочника // в функцию модуля менеджера "ПечатьВыбранныхТоваров" Возврат Справочники. Товары. ПечатьВыбранныхТоваров(Элементы. Список. ВыделенныеСтроки) ; КонецФункции

При этом результат выполнения команды в режиме 1С:Предприятия будет следующим:

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

Что же использовать?

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

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

Конфигурация с примерами из статьи.

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

Как использовать общий модуль

Хороший тон — поместить процедуру или функцию в общий модуль, если она вызывается в более чем одном месте. Во-первых, если процедура корректируется, её надо править только в одном месте. Во-вторых, этим достигается больший порядок в коде.

Типичный пример общего модуля — обработка проведения по какому-то регистру, получение количества разницы рабочих дней, пересчет курсов валют, пересчет количества/цены/суммы в табличной части и другие функции.

Свойства общих модулей

Одно из основных особенностей общих модулей от других модулей — нельзя объявлять общие переменные.

Получите 267 видеоуроков по 1С бесплатно:

Рассмотрим подробнее палитру свойств общего модуля:

Глобальный — если флаг установлен, функции и процедуры из этого модуля становятся доступны в глобальном контексте. Т.е. их можно вызвать в любом месте конфигурации, обращаясь без названия общего модуля. Однако добавляется условие — название процедур и функций в этом общем модуле должны быть уникальны в рамках глобального контекста.
Сервер — процедуры и функции данного общего модуля могут быть выполнены на сервере.
Внешнее соединение — программные коды данного общего модуля могут быть выполнены при подключении внешним источником (например, COM).
Клиент (управляемое приложение) — процедуры и функции данного общего модуля могут быть использованы в толстом клиенте в режиме управляемого приложения.
Клиент (обычное приложение) — программные коды данного общего модуля могут быть использованы в толстом клиенте в режиме обычного приложения.
Вызов сервера — флаг, разрешающий на клиенте использовать процедуры и функции из этого общего модуля.
— если установлена Истина, в этом общем модуле будет отключена проверка прав доступа.
Повторное использование — определяет настройки возвращаемых значений, если опция включена, то после первого выполнения система запомнит значение для данных входных параметров и будет возвращать уже готовое значение. Может принимать следующие значения: не используется — отключение, на время вызова — на время выполнения определенной процедуры, на время сеанса — пока пользователь не закрыл сеанс (программу).

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте

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

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

	Тип общего модуля	Пример наименования	Вызов сервера	Сервер	Внешнее соединение	Клиент (обычное приложение)	Клиент (управляемое приложение)
1.	Серверный	ОбщегоНазначения (или ОбщегоНазначенияСервер)
2.	Серверный для вызова с клиента	ОбщегоНазначенияВызовСервера
3.	Клиентский	ОбщегоНазначенияКлиент (или ОбщегоНазначенияГлобальный)
4.	Клиент-серверный	ОбщегоНазначенияКлиентСервер

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

Сервер (флажок Вызов сервера сброшен),
Клиент (обычное приложение) ,
Внешнее соединение .

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

обработчики подписок на события документов, справочников и т.п., которые принимают в качестве параметра мутабельное значение (объект).
серверные процедуры и функции, в которые в качестве параметра передается объект из модулей справочников, документов и пр., а также из модулей с подписками на события.

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

В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс «Сервер» .
Например: РегламентныеЗаданияСервер , ОбменДаннымиСервер .

2.2. Серверные общие модули для вызова с клиента содержат серверные процедуры и функции, доступные для использования из клиентского кода. Они составляют клиентский программный интерфейс сервера приложения.
Такие процедуры и функции размещаются в общих модулях с признаком:

Сервер (флажок Вызов сервера установлен)

Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом «ВызовСервера» .
Например: РаботаСФайламиВызовСервера

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

См. также: Ограничение на установку признака «Вызов сервера» у общих модулей

2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность , определенную только для клиента) и имеют признаки:

Клиент (управляемое приложение )
Клиент (обычное приложение)

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

Клиентские общие модули именуются с постфиксом «Клиент» .
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиент

См. также: минимизация кода, выполняемого на клиенте

2.4. В отдельных случаях, допустимо создание клиент-серверных общих модулей с процедурами и функциями, содержание которых одинаково и на сервере, и на клиенте. Такие процедуры и функции размещаются в общих модулях с признаками:

Клиент (управляемое приложение)
Сервер (флажок Вызов сервера сброшен)
Клиент (обычное приложение)
Внешнее соединение

Общие модули этого вида именуются с постфиксом «КлиентСервер» .
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиентСервер

В общем случае, не рекомендуется определять общие модули одновременно для сервера и для клиента (управляемое приложение). Функциональность, определенную для клиента и для сервера, рекомендуется реализовывать в разных общих модулях - см. пп. 2.1 и 2.3. Такое явное разделение клиентской и серверной бизнес-логики продиктовано соображениями повышения модульности прикладного решения, упрощения контроля со стороны разработчика над клиент-серверным взаимодействием и снижением риска ошибок из-за принципиальных отличий требований к разработке клиентского и серверного кода (необходимость минимизации кода, выполняемого на клиенте, разной доступностью объектов и типов платформы и др.). При этом нужно иметь в виду неизбежное увеличение числа общих модулей в конфигурации .

Особым случаем смешанных клиент-серверных модулей являются модули форм и команд, которые специально предназначены для реализации серверной и клиентской бизнес-логики в одном модуле.

3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как "Процедуры", "Функции", "Обработчики", "Модуль", "Функциональность" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.

Для того чтобы различать общие модули одной подсистемы, которые созданы для реализации процедур и функций, выполняемых в разных контекстах, рекомендуется задавать им постфиксы, описанные ранее в пп. 2.1-2.4.