Виды программных модулей в 1С: назначение и особенности

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

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

Модули приложения и сеанса: точки входа конфигурации

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

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

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

Общие модули: библиотека прикладного кода

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

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

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

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

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

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

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

Модули форм и команд

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

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

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

&НаКлиенте
Процедура КомандаПечать(Команда)
    ПечатьНаСервере(Объект.Ссылка);
КонецПроцедуры

&НаСервереБезКонтекста
Процедура ПечатьНаСервере(Ссылка)
    Документы.РеализацияТоваров.Печать(Ссылка);
КонецПроцедуры

Как выбрать модуль для размещения кода

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

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

Типичные ошибки и ограничения

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

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

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

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

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

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