К статье
Практический материал

Разработка и Конфигурация · 12 мин

Что такое модуль в 1С:Предприятие

Что такое модуль в 1С:Предприятие, какие виды модулей существуют, где хранится код, как работают общие модули и модули объектов. Практическое руководство.

Модуль в 1С:Предприятие — это именованный контейнер программного кода на встроенном языке, привязанный к конкретному объекту конфигурации или к конфигурации в целом. Весь прикладной код платформы хранится именно в модулях: процедуры и функции, обработчики событий, алгоритмы проведения документов, расчёты и проверки. Без модулей конфигурация представляет собой только структуру метаданных без логики поведения.

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

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

Как устроен модуль: структура и контекст выполнения

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

Ключевая характеристика модуля — контекст выполнения. В клиент-серверной архитектуре 1С код делится на клиентский (интерфейс, диалоги, работа с файлами пользователя) и серверный (запросы к базе данных, проведение, расчёты). Директивы компиляции &НаКлиенте, &НаСервере, &НаСервереБезКонтекста явно указывают, где исполняется конкретная процедура. Серверный код не имеет доступа к элементам формы и файловой системе пользователя, а клиентский — к прямым запросам к базе.

Основные виды модулей в конфигурации

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

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

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

Общие модули: где размещать переиспользуемый код

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

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

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

Модуль объекта и модуль менеджера: в чём разница

Модуль объекта выполняется в контексте конкретного экземпляра: конкретного документа «Реализация товаров № 125» или элемента справочника. Здесь размещают обработчики ОбработкаПроведения, ПередЗаписью, ОбработкаПроверкиЗаполнения. Внутри модуля доступны реквизиты объекта напрямую, по имени, а также через ЭтотОбъект.

Модуль менеджера относится ко всему типу объектов целиком. Его код вызывается через обращение вида Документы.РеализацияТоваровУслуг.ИмяПроцедуры() и не имеет доступа к реквизитам конкретного экземпляра — их нужно передавать параметрами. В модуле менеджера размещают функции печати, получения данных для подбора, алгоритмы, которые опрашивают множество объектов.

Сравнение вариантов

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

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

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

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

Общий модуль

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

Модуль формы и директивы компиляции

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

Типовой шаблон работы выглядит так: клиентская процедура-обработчик собирает данные с формы и вызывает серверную процедуру, та выполняет запрос к базе и возвращает результат, клиентская часть отображает его пользователю. Процедуры с директивой &НаСервере внутри формы имеют доступ к данным формы, а &НаСервереБезКонтекста — нет, зато выполняются быстрее, поскольку не требуют сериализации состояния формы.

Порядок действий при размещении нового кода
  1. 1
    Определите, нужен ли коду доступ к базе данных. Если да — это серверный контекст.
  2. 2
    Решите, привязана ли логика к конкретному объекту. Если да — модуль объекта или формы, если нет — общий модуль.
  3. 3
    Для общего модуля установите флаги контекста: «Сервер» для работы с данными, «Клиент» для интерфейса.
  4. 4
    Экспортируйте только те процедуры, которые вызываются извне, остальные оставьте приватными.
  5. 5
    Проверьте вызов: из клиентского кода обратитесь к серверному модулю и убедитесь, что флаг «Вызов сервера» установлен только там, где это необходимо.

Как найти и отредактировать модуль в конфигураторе

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

Редактор модулей поддерживает синтаксическую подсветку, контекстную подсказку по Ctrl+Пробел, переход к определению процедуры по Ctrl+F12 (список процедур модуля) и проверку синтаксиса через меню «Конфигурация → Проверка конфигурации». Перед сохранением доработки полезно выполнить проверку с включённым режимом «Расширенная проверка» — она выявляет обращения к несуществующим процедурам и ошибки контекста.

Типичные ошибки при работе с модулями

Большинство проблем начинающих разработчиков связано не с синтаксисом, а с неправильным выбором места размещения кода и контекста выполнения.

Типичные ошибки
01
Размещение запросов к базе в клиентских процедурах формы — код не скомпилируется или вызовет многократные обращения к серверу.
02
Экспорт всех процедур общего модуля — нарушается инкапсуляция, появляется риск вызова внутренних функций извне.
03
Использование модуля объекта там, где нужен модуль менеджера — приходится создавать объект в памяти ради одной функции, что замедляет работу.
04
Привилегированный режим без необходимости — пользователи получают доступ к данным, которые должны быть закрыты ролями.
05
Дублирование одинакового кода в модулях форм вместо выноса в общий модуль — при изменении логики приходится править десятки мест.

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

Как проверить, что код размещён правильно

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

Контрольные точки

Как проверить результат

Компиляция модуля
Норма

Проверка конфигурации завершается без ошибок и предупреждений по изменённым модулям

Тревожный признак

Ошибки «Процедура или функция не обнаружена», «Переменная не определена»

Контекст вызова
Норма

Клиентская процедура успешно вызывает серверную, данные возвращаются на форму

Тревожный признак

Ошибка «Вызов сервера запрещён» или пустой результат

Права доступа
Норма

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

Тревожный признак

Нарушение прав доступа либо, наоборот, доступ к закрытым данным

Производительность
Норма

Операция выполняется без заметных пауз, нет многократных серверных вызовов в цикле

Тревожный признак

Форма «подвисает», в замере производительности видны сотни вызовов сервера

Итог

Что важно запомнить

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

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

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

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

Почему возникает ошибка «Процедура или функция не обнаружена»?

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

Когда ставить флаг «Привилегированный режим» у общего модуля?

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

Можно ли вызвать серверную процедуру из клиентской?

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

Что лучше для доработки типовой конфигурации: изменить модуль или создать расширение?

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

Где хранится текст модуля физически?

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