/object-events

name: object-events
description: "Обработчики событий объекта 1С. Используй когда нужно выбрать обработчик под логику, написать или отревьюить ПередЗаписью, ПриЗаписи, ОбработкаПроверкиЗаполнения, ОбработкаЗаполнения, ПриКопировании, ПередУдалением, разобраться с параметром Отказ, признаком ОбменДанными.Загрузка или подписками на события."

Object Event Handlers

MCP routing

• Preferred path: use MCP `unica` tools `unica.view {}`, `unica.view` on the object node, `unica.search`, `unica.apply`, `unica.check`, and `unica.run`.
• Runtime идёт через `unica.run`: вызов без `op` отдаёт словарь операций и

контракт каждой — `argsSchema`, `execution`, `previewRequired`, `dryRunRequired`. Контракт вызова бери оттуда, а не из этого текста; при `implemented: true` используй опубликованную `argsSchema`; при `support.state: limited` разрешено только подмножество `support.supportedArgs`. При `support.state: unavailable` остановись; не выдумывай аргументов при `argsSchema: null`. Для плановой операции сначала проверь результат `dryRun: true`, затем исполняй запрос с `dryRun: false`. Preview не фиксирует входы между вызовами. Не обходи контракт прямым runner-ом.

• Use `unica.docs` with `source: "development-standard"` for the standards about handlers: 396, 455, 463, 464, 465, 466, 686, 752, 773, and diagnostics АПК:75, АПК:144, АПК:1340, BSLLS:DataExchangeLoading, BSLLS:UsingCancelParameter, BSLLS:MissingEventSubscriptionHandler. These are standards, not evidence of runtime behavior; confirm the wording before citing one.
• Do not call internal analyzer, runtime, standards, or package adapters directly. They are hidden behind MCP `unica`.

References

• Read `../../references/platform/object-events.md` for the handler map, the conditional fill-check shape, the exchange guard, and the cancel-parameter rule.
• Read `../../references/platform/document-posting.md` when the handler in question is `ОбработкаПроведения` or `ОбработкаУдаленияПроведения`.
• Read `../../references/platform/platform-mechanics.md` for transaction boundaries and logging inside write handlers.

Core model

Pick the handler by what the logic needs to see, not by what is convenient:

• Needs the fill source → `ОбработкаЗаполнения`. Refusing "create based on" belongs here too, raised as an exception, not moved into a separate command handler (std396).
• Needs to reject bad data before writing → `ОбработкаПроверкиЗаполнения` (std463).
• Needs the old stored values, or must fill or check before the write → `ПередЗаписью` (std464).
• Needs the object to already exist in the database → `ПриЗаписи`. Do not modify the object there; it is already written (std465).
• Needs to run before the object disappears → `ПередУдалением` (std752).
• Needs to strip values that must not survive a copy → `ПриКопировании` (std466).

Two rules cut across all of them: `ОбменДанными.Загрузка` is checked first in `ПередЗаписью`, `ПриЗаписи`, and `ПередУдалением` (std773), and `Отказ` is only ever assigned `Истина` (std686).

Workflow

1. Name what the logic needs to observe — fill source, old values, written state, or nothing yet — and let that pick the handler. 2. Locate what already runs: read the object module with `unica.view` on the module node (its `Method` branch lists the methods), and find subscriptions on the same events with `unica.search` and `unica.view` on the object node. A subscription is invisible from the object module it affects. 3. Read the shared procedures the handler calls with `unica.view` at `<handler>.Callee`, and their callers at `<method>.Caller`, to see what else the change reaches. 4. Write the guard before the logic: `Если ОбменДанными.Загрузка Тогда Возврат; КонецЕсли;` — in the subscription handler too, not only in the object module. 5. Express conditional requiredness by collecting `НепроверяемыеРеквизиты` and removing them from `ПроверяемыеРеквизиты` at the end, never by adding to `ПроверяемыеРеквизиты`. 6. Apply the change with `unica.apply`, one verifiable step at a time. 7. Verify statically with `unica.check` on the module node (test runs are outside the v0.13 surface), and require separate runtime evidence for the exchange path when the object participates in one.

Design rules

• The object must load as it is during exchange: no repeated business logic, no extra checks, no changes that could distort data or block the load (std773). Code that sets `ОбменДанными.Загрузка = Истина` takes responsibility for the object's integrity itself.
• Never assign `Ложь` to `Отказ`, and never assign a boolean function result to it — either can clear a `Истина` set earlier in the same handler or by another subscriber (std686, АПК:144). The rule covers `СтандартнаяОбработка` and `Выполнение` too.
• Setting `Отказ = Истина` without a message leaves the user the platform's own text, which names the object and nothing else. Report the reason, or raise an exception instead.
• Adding names to `ПроверяемыеРеквизиты` hides the conditional check from analysis of the `Проверка заполнения` property (std463).
• Event handlers belong in the standard event-handler region; procedures that are not handlers do not (std455, АПК:1340).

Review checklist

• `ПередЗаписью`, `ПриЗаписи`, and `ПередУдалением` check `ОбменДанными.Загрузка` before anything else — in subscription handlers as well as object modules (АПК:75).
• Any exception to that guard carries a comment stating the reason.
• `ПриЗаписи` does not modify the object being written.
• Conditional fill checks remove from `ПроверяемыеРеквизиты`, never add to it.
• `Отказ` is only ever assigned `Истина`, and every refusal tells the user why.
• Every declared subscription has its handler procedure.
• Subscriptions on the same events were reviewed together with the object module change.

Stop rules

• Do not move a "create based on" refusal out of `ОбработкаЗаполнения` into command handlers.
• Do not add logic to a write or delete handler without the exchange guard.
• Do not c