Разработка и Конфигурация · 12 мин
Модули 1С: какие разделы существуют и для чего нужны
Разбираем виды модулей в 1С: модуль сеанса, приложения, общие модули, модули объектов, форм и команд. Назначение, область видимости, правила размещения кода.
Модуль в 1С — это контейнер программного кода на встроенном языке, привязанный к определённому объекту конфигурации или к системе в целом. Каждый тип модуля имеет собственную область видимости, место исполнения (клиент или сервер) и набор доступных контекстов. Понимание этой структуры необходимо, чтобы код работал предсказуемо, а конфигурацию было удобно поддерживать.
Ошибки с выбором модуля — одна из самых частых причин проблем у начинающих разработчиков: процедура не видна из другого места, код выполняется не на той стороне, обращение к данным вызывает ошибку «переменная не определена». Всё это следствия непонимания, какие разделы модулей существуют и чем они отличаются.
Ниже рассмотрены все основные виды модулей платформы 1С:Предприятие, их назначение, ограничения и правила выбора. Материал ориентирован на тех, кто начинает разрабатывать или дорабатывать конфигурации, а также на администраторов, которым нужно ориентироваться в структуре кода.
Модуль сеанса: точка входа при запуске системы
Модуль сеанса — единственный в конфигурации, он создаётся автоматически и не может быть удалён. Его главное событие — УстановкаПараметровСеанса, которое платформа вызывает при старте сеанса, когда требуется инициализировать параметры текущего пользователя: роли, настройки, отборы по организации и т. п.
Код модуля сеанса всегда выполняется на сервере в привилегированном режиме. Это означает, что проверки прав доступа внутри него не действуют — поэтому здесь нельзя напрямую выполнять действия, которые должны контролироваться правами. Попытка вызвать интерактивные операции (например, открыть форму) приведёт к ошибке.
Типичное содержимое модуля сеанса — заполнение параметров сеанса по данным текущего пользователя. Если параметров много, рекомендуется инициализировать их «лениво»: платформа вызывает обработчик со списком требуемых параметров, и заполнять нужно только запрошенные, иначе запуск приложения будет замедляться.
Модули приложения: обычное и управляемое
Модуль управляемого приложения обрабатывает события старта и завершения работы системы в режиме управляемых форм: ПередНачаломРаботыСистемы, ПриНачалеРаботыСистемы, ПередЗавершениемРаботыСистемы. Здесь размещают код, который должен выполниться один раз при запуске: проверку версии платформы, подключение внешних компонент, открытие стартовой формы.
Модуль обычного приложения выполняет аналогичную роль, но только когда конфигурация запускается в режиме обычного приложения (толстый клиент с обычными формами). В современных конфигурациях, работающих через управляемые формы и веб-клиент, он фактически не используется.
Оба модуля приложения работают на клиенте и не имеют серверного контекста. Обращение к базе данных напрямую из них невозможно — нужно вызывать серверные процедуры из общих модулей. Также существуют модули внешнего соединения и модули, связанные с подсистемами, но в типовой разработке они встречаются редко.
Общие модули: основное хранилище программной логики
Общие модули — это библиотеки процедур и функций, доступные из любой точки конфигурации. Именно здесь сосредоточена большая часть бизнес-логики типовых решений. Количество общих модулей не ограничено, и правильная их организация — залог поддерживаемой конфигурации.
Ключевые свойства общего модуля задаются в палитре свойств и определяют, где он компилируется и исполняется:
- Сервер — модуль исполняется на сервере, имеет доступ к базе данных, но недоступен с клиента напрямую, если не включён вызов сервера;
- Клиент (управляемое приложение) — исполняется на клиенте, может работать с формами и интерфейсом, но не имеет доступа к данным напрямую;
- Вызов сервера — разрешает обращение к серверному модулю с клиента; без этого флага клиентский код серверный модуль не увидит;
- Привилегированный — код выполняется без проверки прав доступа; применяют для системных операций, где права проверяются отдельно;
- Клиент (обычное приложение) — для режима обычных форм, в новых разработках почти не используется.
Принятое в типовых конфигурациях соглашение — суффиксы в именах модулей: ОбщегоНазначения (серверный), ОбщегоНазначенияКлиент (клиентский), ОбщегоНазначенияВызовСервера, ОбщегоНазначенияПереопределяемый. Такое именование сразу показывает контекст исполнения и упрощает поиск нужной процедуры.
Модули объектов: справочники, документы, регистры
У каждого прикладного объекта — справочника, документа, плана счетов, бизнес-процесса — есть модуль объекта. Его код выполняется на сервере при работе с конкретным экземпляром: записи, проведении, удалении. Здесь живут обработчики событий ПередЗаписью, ПриЗаписи, ОбработкаПроведения, ОбработкаЗаполнения, ПриКопировании и другие.
Модуль объекта имеет доступ к реквизитам текущего экземпляра напрямую, по имени. Например, в модуле документа «РеализацияТоваровУслуг» можно писать Если Не ЗначениеЗаполнено(Контрагент) Тогда ... — без обращения через ЭтотОбъект. Это удобно, но требует дисциплины: легко случайно перекрыть имя реквизита локальной переменной.
У регистров (сведений, накопления, бухгалтерии, расчёта) вместо модуля объекта используется модуль набора записей. Он срабатывает при записи набора и позволяет контролировать или дополнять движения. Для документов-регистраторов движения обычно формируются в ОбработкаПроведения модуля объекта документа, а не в модуле набора записей регистра.
Модуль менеджера объекта
Помимо модуля объекта, у справочников, документов и ряда других типов есть модуль менеджера. Он выполняется в контексте менеджера типа (например, Справочники.Номенклатура) и не привязан к конкретному экземпляру. Его задачи — операции над типом в целом.
Типичное содержимое модуля менеджера:
- обработчики получения представления объекта и полей представления;
- обработчики формирования печатных форм (команда печати типовых конфигураций обращается именно сюда);
- обработка получения данных выбора — кастомизация подбора в полях ввода;
- создание объектов по шаблону, поиск дублей и прочие «типовые» операции.
Частая ошибка — размещать в модуле менеджера логику, которая должна работать с конкретным документом. Менеджер не имеет доступа к реквизитам экземпляра: попытка обратиться к ним приведёт к ошибке компиляции или исполнения.
Модули форм и команд
Модуль формы исполняется там, где форма открыта: на клиенте, а для серверных процедур формы — на сервере с последующим возвратом результата. В управляемых формах директивы компиляции явно указывают контекст: &НаКлиенте, &НаСервере, &НаСервереБезКонтекста, &НаКлиентеНаСервереБезКонтекста.
Главное правило: в модуле формы размещают только логику интерфейса — реакцию на действия пользователя, управление видимостью элементов, подготовку данных для отображения. Проверку заполнения, проведение, обращения к другим объектам нужно выносить в модуль объекта или общие модули. Иначе при программной записи объекта (без формы) эта логика просто не выполнится.
Модули команд — это точки входа для команд интерфейса: глобальных общих команд и команд объектов. Команда обычно делает одно действие: открывает форму с параметрами или вызывает серверную процедуру обработки. Размещать в модуле команды сложную логику не принято — она делегируется общим модулям.
Как выбрать правильный модуль для своего кода
Выбор места для процедуры определяется тремя вопросами: где код должен исполняться, к каким данным он обращается и откуда будет вызываться. Практическая схема принятия решения выглядит так.
Как выбрать действие
После размещения кода обязательно проверьте результат: откройте конфигуратор, выполните синтаксическую проверку модулей (Конфигурация → Проверка конфигурации) и протестируйте сценарий в пользовательском режиме — в том числе программную запись объекта без открытия формы, если логика должна работать в обменах и фоновых заданиях.
Как проверить результат
Процедура видна, код выполняется без ошибок компиляции
Ошибка «Процедура или функция не обнаружена» — неверный контекст или не выставлен Экспорт
Вся бизнес-логика отрабатывает, движения корректны
Часть проверок пропускается — логика ошибочно живёт в модуле формы
Форма реагирует без заметных пауз
Подвисания — вероятно, серверные вызовы идут из цикла на клиенте
Часто задаваемые вопросы
Чем общий модуль отличается от модуля объекта?
Общий модуль — это библиотека процедур, не привязанная к конкретным данным и доступная отовсюду. Модуль объекта привязан к экземпляру справочника или документа: он выполняется при работе с этим экземпляром и имеет прямой доступ к его реквизитам. Логику «про объект» пишут в модуле объекта, переиспользуемые алгоритмы — в общих модулях.
Почему клиентская процедура не видит серверный общий модуль?
У серверного общего модуля должен быть установлен флаг «Вызов сервера», а вызываемая процедура должна быть объявлена с ключевым словом Экспорт. Если оба условия выполнены, а ошибка остаётся, проверьте, нет ли в имени модуля опечатки и не помечен ли модуль только как серверный без права вызова.
Где размещать код формирования печатной формы документа?
В типовых конфигурациях обработчики печати размещаются в модуле менеджера объекта: процедуры ДобавитьКомандыПечати и Печать. Так печать доступна и из формы документа, и из списка, и из внешних вызовов. В модуле формы печать размещать не следует.
Можно ли вызвать процедуру модуля формы из другой формы?
Технически возможно через получение формы, но это плохая практика: формы становятся жёстко связанными, и код перестаёт работать, когда форма закрыта. Общую логику следует выносить в общие модули, а между формами передавать только параметры и оповещения.
Что такое привилегированный режим общего модуля и когда он оправдан?
Привилегированный модуль исполняется без проверки прав доступа к объектам базы. Это оправдано для системных операций: запись служебных регистров, обмен данными, действия от имени системы. Для обычной бизнес-логики привилегированный режим использовать не следует — он обходит настроенные права пользователей.
Нужны ли модули обычного приложения в новой разработке?
Нет. Если конфигурация работает только в режиме управляемого приложения (включая веб-клиент и мобильный клиент), модуль обычного приложения остаётся пустым и не исполняется. Вся логика старта размещается в модуле управляемого приложения и модуле сеанса.
Что важно запомнить
Тип модуля определяет место исполнения и область видимости кода: модуль сеанса — старт системы, модули приложения — события запуска, общие модули — переиспользуемая логика, модули объектов и менеджеров — поведение данных, модули форм — только интерфейс. Правильное размещение кода гарантирует, что логика сработает при любом способе работы с объектом, а не только при открытой форме.