Какие виды программных модулей существуют в 1С:Предприятие

Любая доработка конфигурации в 1С:Предприятие начинается с вопроса: куда поместить код. Платформа не даёт «одного большого файла» — вместо этого код распределяется по программным модулям, каждый из которых привязан к определённому контексту исполнения: клиенту, серверу, объекту данных или форме. От правильного выбора модуля зависят производительность, безопасность и удобство сопровождения решения.

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

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

Общие модули: основное место для бизнес-логики

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

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

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

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

Модули объектов и модули менеджеров

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

Типичное содержимое модуля объекта — обработчики событий жизненного цикла: ПередЗаписью, ПриЗаписи, ОбработкаПроведения, ОбработкаЗаполнения, ОбработкаПроверкиЗаполнения. Например, контроль остатков при проведении документа или автоматическое заполнение реквизита при создании элемента справочника размещаются именно здесь. Модуль объекта исполняется на сервере; экспортные процедуры в нём доступны только при наличии ссылки на объект.

Модуль менеджера — отдельный модуль того же объекта конфигурации, но он существует в единственном экземпляре и не привязан к конкретным данным. Его назначение — операции над коллекцией объектов: получение печатной формы, формирование представления ссылки, поиск, создание элементов. Стандартный пример — функция ПолучитьДанныеПечати() или обработчик ОбработкаПолученияФормы, который подменяет открываемую форму.

Модуль объекта или модуль менеджера

Модуль объекта

Логика конкретного экземпляра: проведение, проверка заполнения, реакция на запись. Есть доступ к реквизитам текущего объекта.

Модуль менеджера

Операции над типом в целом: печать, создание, поиск, представление. Доступа к данным конкретного объекта нет.

Общий модуль

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

Модули форм: интерфейсная логика

Модуль формы содержит код, связанный с поведением конкретной формы: обработчики событий элементов, команд, событий самой формы (ПриСозданииНаСервере, ПриОткрытии, ПередЗаписью). В управляемых формах модуль компилируется дважды — на клиенте и на сервере, поэтому каждая процедура помечается директивой компиляции.

Директивы &НаКлиенте, &НаСервере, &НаСервереБезКонтекста и &НаКлиентеНаСервереБезКонтекста определяют, где выполняется код. Различие между «НаСервере» и «НаСервереБезКонтекста» принципиально: в первом случае доступны данные формы как объект (их можно читать и менять напрямую), во втором — нет, зато вызов дешевле, так как не требует передачи состояния формы на сервер.

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

Модули приложения, внешнего соединения и сеанса

Модуль приложения (в управляемом режиме — модуль управляемого приложения) выполняется при старте и завершении сеанса работы пользователя. В нём размещаются обработчики ПередНачаломРаботыСистемы, ПриНачалеРаботыСистемы, ПередЗавершениемРаботыСистемы, а также глобальные переменные и обработчики глобальных событий, например ожидания или нажатий горячих клавиш. Модуль компилируется на клиенте, поэтому серверная логика здесь недоступна напрямую.

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

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

1. 1
   Сделайте выгрузку информационной базы или хотя бы выгрузку конфигурации в файл.
2. 2
   Внесите изменение, ограничив его минимальным объёмом кода.
3. 3
   Проверьте синтаксис модуля через конфигуратор (проверка конфигурации).
4. 4
   Обновите конфигурацию базы данных в тестовой копии и войдите под разными ролями.
5. 5
   Только после успешной проверки переносите изменение в рабочую базу, предупредив пользователей о перезапуске сеансов.

Модули команд и служебные модули

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

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

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

Как выбрать модуль под конкретную задачу

Алгоритм выбора сводится к трём вопросам. Первый: привязан ли код к конкретному экземпляру данных? Если да — это модуль объекта (проведение, проверка заполнения). Второй: нужен ли код нескольким объектам или подсистемам? Если да — общий модуль с правильными флагами контекста. Третий: связан ли код с поведением интерфейса? Тогда — модуль формы или команды, с выносом всей работы с данными на сервер.

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

Маршрут решения

Как выбрать место для кода

Код реагирует на запись или проведение конкретного объектаМодуль объекта: обработчики ПередЗаписью, ОбработкаПроведения

Нужна печатная форма, представление или создание объекта извнеМодуль менеджера объекта

Логика используется в нескольких местах конфигурацииОбщий модуль с флагами по контексту исполнения

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

Нужно инициализировать параметры при входе пользователяМодуль сеанса, обработчик УстановкаПараметровСеанса

Частые вопросы о модулях 1С

Чем общий модуль отличается от модуля объекта?

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

Почему процедура общего модуля «не видна» из формы?

Проверьте три условия: процедура должна быть объявлена с ключевым словом «Экспорт», у модуля должен быть установлен флаг «Сервер», а для вызова с клиента — дополнительно флаг «Вызов сервера». Также убедитесь, что в клиентской процедуре нет попытки обратиться к модулю, скомпилированному только для обычного приложения.

Что означает директива «НаСервереБезКонтекста»?

Процедура с этой директивой выполняется на сервере, но не имеет доступа к данным формы как к объекту — реквизиты формы нужно передавать параметрами. Такой вызов дешевле по ресурсам, потому что платформа не сериализует состояние формы. Именно «БезКонтекста» рекомендуется для большинства серверных операций из формы.

Где размещать код регламентного задания?

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

Опасно ли включать привилегированный режим у общего модуля?

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

Можно ли добавить свой модуль в типовую конфигурацию, не снимая её с поддержки?

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