Что такое событие в 1С:Предприятие и как с ним работать

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

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

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

Что платформа понимает под событием

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

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

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

Основные виды событий и где они описываются

События группируются по месту возникновения. Знание этой классификации помогает быстро понять, в каком модуле искать или размещать обработчик.

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

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

Порядок вызова событий при записи и проведении документа

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

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

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

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

Подписки на события: перехват без изменения модулей

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

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

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

Порядок вызова подписок относительно обработчика в модуле объекта: сначала выполняются подписки на событие, затем обработчик в модуле объекта. Это важно учитывать, если логика подписки должна опираться на данные, которые объект заполняет в собственном обработчике, — в таком случае подписка увидит ещё незаполненные значения.

Когда подписка не подходит

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

События в управляемых формах

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

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

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

Отладка и диагностика событий

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

Дополнительные инструменты: журнал регистрации (фиксация ошибок в обработчиках и собственных сообщений через ЗаписьЖурналаРегистрации), замеры производительности (выявление «тяжёлых» подписок) и технологический журнал для анализа длительных транзакций записи.

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

Как проверить корректность доработки

Срабатывание обработчика

Норма

Точка останова в обработчике достигается при нужном действии, параметры заполнены

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

Обработчик не вызывается — неверный модуль, директива или имя процедуры

Программная запись

Норма

Логика срабатывает и при записи из кода, и при обмене данными

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

Проверка работает только из формы — логика размещена не в модуле объекта

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

Норма

Время записи объекта после доработки выросло незначительно

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

Запись замедлилась в разы — лишние запросы в подписках или циклах

Отказ операции

Норма

При Отказ = Истина выводится понятное сообщение, транзакция откатывается полностью

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

Объект частично записан или пользователь не понимает причину отказа

Ограничения и риски при работе с событиями

Главный риск событийной доработки — скрытое влияние на всю систему. Подписка на событие «ПриЗаписи» всех документов затрагивает каждую запись, включая обмены, загрузки и регламентные операции. Ошибка в таком обработчике способна заблокировать проведение документов во всей базе.

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

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

Частые вопросы о событиях в 1С

Чем событие отличается от подписки на событие?

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

Почему обработчик «ПередЗаписью» в форме не срабатывает при обмене данными?

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

В каком порядке выполняются несколько подписок на одно событие?

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

Как отменить запись документа из обработчика события?

В обработчиках «ПередЗаписью», «ПриЗаписи» или «ОбработкаПроведения» установите параметр Отказ в значение Истина и выведите сообщение пользователю через метод Сообщить. Транзакция записи будет отменена, и объект останется в исходном состоянии.

Можно ли добавить событие, которого нет в платформе?

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

Как найти все подписки, срабатывающие при записи конкретного документа?

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