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