Общие модули 1С: для чего они нужны и как с ними работать

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

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

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

Какие задачи решают общие модули

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

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

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

Типы общих модулей: серверные, клиентские и привилегированные

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

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

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

Как создать общий модуль и вызвать его функцию

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

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

// В общем модуле РасчетСкидок (Сервер, Вызов сервера)
Функция ПолучитьСкидку(Контрагент) Экспорт
// запрос к базе, расчёт
Возврат РазмерСкидки;
КонецФункции

// В модуле формы документа
Скидка = РасчетСкидок.ПолучитьСкидку(Объект.Контрагент);

1. 1
   Откройте конфигуратор, ветка «Общие» → «Общие модули», нажмите «Добавить»
2. 2
   Задайте имя без пробелов и спецсимволов, отражающее назначение модуля
3. 3
   Установите флаги контекста: «Сервер» и «Вызов сервера» для серверной логики
4. 4
   Напишите процедуры и функции с ключевым словом «Экспорт»
5. 5
   Обновите конфигурацию базы данных (F7) и проверьте вызов из тестового кода

Разделение клиентской и серверной логики на практике

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

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

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

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

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

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

Ещё одна группа ошибок связана с длинными именами и монструозными модулями. Когда в один общий модуль сваливают тысячи строк разнородного кода, им становится трудно пользоваться, а компиляция модуля при старте замедляет запуск. Лучше дробить код по предметным модулям: один модуль — одна ответственность.

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

Как проверить, что модуль работает правильно

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

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

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

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

Компиляция модуля

Норма

Проверка конфигурации без ошибок, функция вызывается из нужного контекста

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

Ошибки «метод не обнаружен» или «недопустимый вызов» при проверке

Контекст исполнения

Норма

В отладчике серверный код исполняется на сервере, клиентский — на клиенте

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

Серверная функция недоступна с клиента или наоборот

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

Норма

Пользователь с ограниченными правами не получает лишних данных через модуль

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

Через привилегированный модуль доступны закрытые данные

Часто задаваемые вопросы

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

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

Можно ли хранить переменные в общем модуле?

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

Что такое флаг «Повторное использование возвращаемых значений»?

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

Сколько общих модулей должно быть в конфигурации?

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

Почему функция из общего модуля не видна в другом месте кода?

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

Нужны ли общие модули при работе с расширениями конфигурации?

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