1с как работает отказ

Обновлено: 04.07.2024

Начиная с версии 8.3.8 фирма 1С изменила подход к завершению работы и закрытию приложения. Новомодные веяния – ли, ошибки при работе с WEB интерфейсом – ли, но теперь со всех обработчиков событий, используемых нами при закрытии – «ПередЗавершениемРаботыСистемы» и «ПриЗавершенииРаботыСистемы», сервер не доступен. Рассмотрим, как теперь работают данные обработчики.

Обработчик: ПередЗавершениемРаботыСистемы(Отказ, ТекстПредупреждения)

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

Диалог завершения программы

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

Если же пользователь нажмет на «Продолжить работу», то возможны два варианта событий:

Ответ на первый глобальный русский вопрос «кто виноват?» понятен. Я постараюсь ответить на второй «что делать?». Если нам надо что то зафиксировать в базе, например информацию о работе пользователей в системе. Кто когда заходил, кто когда вышел.

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

Для опроса системы у нас есть функция ПолучитьСеансыИнформационнойБазы(), которая возвращает массив сеансов. А для фиксации, что пользователя в сеансах уже нет нужно создавать новый регистр. Я предлагаю периодический (в пределах секунды) РС с двумя измерениями «Пользователь» и «НомерСеанса», в ресурсах же должно быть как минимум поле «ЗавершениеСеанса» по которому мы будем понимать что пользователь нами не обработан или обработан но активен.

Структура регистра

Обработчик: ПриЗавершенииРаботыСистемы()

Привожу полный текст справки:

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

В данной процедуре не допускаются:

открытие форм и других окон,
использование серверных вызовов,
использование асинхронных вызовов.

Вот честно, не понимаю вообще какие действия можно осуществить в данной процедуре? Да мы можем написать кучу кода, что-то сделать с файлами, но ничего сообщить пользователю, что то сделать с базой – мы уже не можем.

Резюме

Резюмируя данную статью хочу поблагодарить фирму 1С, что не дает нам соскучиться и всегда на страже нашего свободного времени.

Будьте внимательны, при программной записи события модуля формы не запускаются!

- Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)

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

Второй параметр этого обработчика "ПараметрыЗаписи" имеет тип "Структура". У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои!

Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно использовать. Например, можно спросить что-то у пользователя и ответ записать в этот параметр. И уже, например, в ПриЗаписиНаСервере использовать этот параметр для анализа и дальнейших действий.

- Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)

- Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)

Сначала вызывается событие формы ОбработкаПроверкиЗаполненияНаСервере На данном этапе есть доступ к данным формы.

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

Затем вызывается событие прикладного объекта ОбработкаПроверкиЗаполнения.

Эти два обработчика проверки заполнения реализуются через параметр "ПроверяемыеРеквизиты" типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения "Выдавать ошибку"). И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.

Эти два обработчика событий предназначены:

Для включения в проверку заполнения тех реквизитов, у которых в свойствах "ПроверкаЗаполнения" указано "Не проверять". Для этого надо добавить этот реквизит в массив параметр "ПроверяемыеРеквизиты"
Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения "Выдавать ошибку" в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра "ПроверяемыеРеквизиты"

Имеется несколько особенностей, которые необходимо учитывать:

Если у формы из которой записывается объект в свойствах не установлено "ПроверятьЗаполнениеАвтоматически", то тогда эти обработчики проверки заполнения не вызываются и проверки не происходят!
Вызываются только при интерактивной записи! При программной записи не вызываются. Для проверки нужно использовать метод объекта ПроверитьЗаполнение(), который инициирует запуск этих событий.
Для документов, имеющих возможность проведения, эти события проверки заполнения вызываются только при проведении!
Если данные формы не нужны, то используйте обработчик модуля объекта ОбработкаПроверкиЗаполнения

- Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)

В этом обработчике можно дозаполнять реквизиты объекта (через параметр ТекущийОбъект) или провести дополнительные проверки. Есть доступ к данным формы.

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

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

Параметр ТекущийОбъект имеет тип класса "объект" в зависимости от типа записываемого объекта (в случае записи документа ДокументОбъект). Т.е. экземпляр класса объект создан, и можно обратиться к его свойствам и методам, но в базу данных ещё не записан.

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

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

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

Начало транзакции (начало работы с базой данных)

- Модуль объекта ПередЗаписью(Отказ)

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

Для документов в параметры данного обработчика добавляются ещё два параметра: РежимЗаписи, РежимПроведения.

- Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)

Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.

Возникает в момент, когда выполняется установка нового кода элемента справочника, узла плана обмена или кода плана видов характеристик.

Эти событии вызываются для объектов у которых указано свойство "Автонумерация" и только для тех объектов, у которых пустой код на момент записи.

Если установить параметру СтандартнаяОбработка значение Ложь, то новый номер генерироваться не будет и можно программно задать код объекта в данном обработчике.

- Модуль объекта ОбработкаУдаленияПроведения (Отказ)

Этот обработчик запускается только при отмене проведения документов с целью удаления движений из регистров. При этом неважно как отменяется проведение документа - программно или интерактивно.

- Модуль объекта ПриЗаписи(Отказ)

Вызывается после записи объекта в базу данных, но до окончания транзакции записи.

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

Ссылка уже есть и можно записать в базу данных дополнительные данные на основании текущего объекта, используя эту ссылку.

Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый.

Поскольку это событие обрабатывается в транзакции записи основных данных, гарантируется синхронность изменения основных и дополнительных данных. Либо и те и другие будут записаны, либо и те и другие изменения будут отменены при отмене транзакции.

Можно ещё отказаться от записи.

- Модуль объекта ОбработкаПроведения (Отказ, РежимПроведения)

Этот обработчик запускается только при проведении документов. При этом неважно как проводится документ - программно или интерактивно.

Основное назначение процедуры-обработчика данного события - генерация движений по документу. Именно в данном обработчике прописываются алгоритмы записей в регистры, т.е. программно формируются движения документа.

Параметр РежимПроведения определяет как будет проводиться документ: оперативно или неоперативно.

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

- Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)

Вызывается после записи объекта в базу данных, но до окончания транзакции записи. Есть последний шанс отказаться от записи.

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

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

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

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

Работать следует именно через этот параметр, то есть не путать с основным реквизитом формы Объект, так как там данные, которые были до записи и его изменения бесполезны потому, что после этого обработчика данные из ТекущегоОбъекта запишутся в Объект.

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

Итак, по поводу этого обработчика можно сделать следующие выводы:

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

Завершение транзакции (данные окончательно записываются в таблицы БД)

- Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)

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

Этот обработчик используют, когда предполагаются действия над формой. Это те действия, которые должны быть выполнены только в том случае, когда объект 100 % записан (т.е. после транзакции). Например, вывод в форме некоторой дополнительной информации, связанной с данными объекта. Или выполнение каких-либо действий, которые должны быть выполнены только в том случае, когда объект гарантированно записан.

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

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

Доступны ПараметрыЗаписи, данные которых были переданы в этом параметре из других обработчиков.

- Модуль формы ПослеЗаписи(ПараметрыЗаписи)

Выполняется на клиенте. Можно использовать для того, чтобы визуально что-то отобразить на форме или организовать диалог с пользователем, например выдать предупреждение.

Доступны ПараметрыЗаписи, данные которых были переданы в этом параметре из других обработчиков.

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

выясняется, что проведение невозможно, т.е. получен отказ, запретить выполнение дальнейших операций в процедуре
" ВыполнитьВсякуюЕрунду "

(3) Если при записи происходит исключение, то выполнение кода дальше и так не пойдет. Видимо, у автора топика исключение при отказе проведения не происходит. (4) Да ладно? Именно для этого Попытка и придумана, чтобы даже в случае исключения код продолжал работать. Как можно добится, чтобы если при создании этого документа выясняется, что проведение невозможно , т.е. получен отказ, запретить выполнение дальнейших операций в процедуре
"ВыполнитьВсякуюЕрунду" (7) В (3) решение для исключения.
И да, спасибо за "разные вещи", тоже запишу. (8) И что? Вы же утверждаете, что "Если при записи происходит исключение, то выполнение кода дальше и так не пойдет." Вот я и хочу у вас узнать - вы правда утверждаете, что в случае исключения исполнение кода дальше не пойдет, и оператор Сообщить не подлежит исполнению?
(9) Я утверждаю, что Попытка сама по себе лишняя, т.к. и без нее при исключении выполнение кода дальше не пойдет. Что и требуется автору темы, судя из (1). А если, этого не происходит, то решение предложенное в (3) в корне неверно и результата не даст, в отличие от решения в (2). (11) Что вы подразумеваете под исключением все же? Давайте разберемся в терминах, раз уж так.
Исключение - это ошибка, генерируемая платформой при выполнении той или иной операции.
Отказ - переменная, с помощью которой разработчик может программно управлять течением транзакции.
Так? (19) По поводу исключения возражений нет. Разве что, можно добавить, что исключение можно вызвать программно.
Отказ - это переменная, которая может использоваться по разному, в зависимости от контекста (в том числе и для указанного вами). Я бы охарактеризовал так.
И что дальше? Какая разница, что представляет из себя Отказ?
Речь шла только об исключении, т.к. первоначально мое замечание в (4) касалось именно Попытки, которая используется для обработки исключений и, соответственно, возможности продолжить дальнейшее исполнение кода. В то время, как автору темы нужно было как раз обратное, т.е. исключить дальнейшее выполнение кода. По этому, я и предположил, что исключение у автора в упомянутом коде не происходит. Об этом я написал в (4) в ответ на (3), что его предложение решения без установки флага возникновения ошибки в обработке исключения и дальнейшей проверке этого флага абсолютно бессмысленно и приведет к обратному или нулевому эффекту.
Что еще тут можно обсуждать? Разжевал подробно, как только смог. (10) Да нет. Автор пишет про "получен отказ (не хватает остатков и прочее)", А исключение может быть еще и по причине отстутствия данных для записи регистров (платформа не дает записать движения), например. (12) то есть отказа нет, не документ почему-то не записан, а признак Проведен остался от старой версии = Истина. Так что ли?) (16) Отказ есть. Автор прямо про это пишет. Не понимаю, почему вы докопались до исключения.

как вы проверите признак Проведен, если документ не сохранен?

как вы проверите признак Проведен, если документ не сохранен?
Я вас удивлю, но я даже не буду пытаться его проверять. Как и все разумные люди.

Правда пришлось переделать процедуру "СоздатьДокументПеремещениеТМЦ()" в функцию

Правда пришлось переделать процедуру "СоздатьДокументПеремещениеТМЦ()" в функцию (14) Потому, что запись происходит в СоздатьДокументПеремещениеТМЦ(), а проверка нужна в ВыполнитьВсякуюЕрунду().

(15)Что мешало у процедуры сделать один из параметров выходным?

(20) (22) Как по мне, это плохой подход, т.к. такое объявление абсолютно не интуитивно. Имеется ввиду, что объявляемый параметр не дает понять, что в нем возвращается результат выполнения. В то время как использование функции с именем СоздатьДокументПеремещениеТМЦ() будет более-менее явно указывать, что возвращаемый результат является результатом успешного ее выполнения.

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

(24)ну епт. Назовите вы его ВыходнойПараметр и работайте с ним только как с выходным параметром и никак иначе.
Или еще тупее: сделайте несколько параметров, один из которых будет сигнализировать об ошибке при проведении документа. (25) Мне не понятна тяга к усложнению. Функции не просто так придумали, "чтобы были". На низком уровне выполнения функций как таковых не сущестувет.
Зачем использовать возвращаемый параметр, если это исключит возможность записи:

Как усложнился бы в записи любой код, если бы вместо функций предоставляемых платформой были только процедуры с выходными параметрами?

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

(26)Т.е. городить функцию, которая записывает и проводит документ, при этом не понятно, что должна вернуть по результату своего выполнения - это тяга к упрощению? Хорошо, пусть будет так.

В чем сложности с кодом через процедуры с входными параметрами?

(28) Это что уход от ответа?
Я просил заменить все функции используемые в предложенной строке кода на процедуры с возвращаемыми параметрами.
И переписать код строки без использования функций, а не оборачивание предложенной строки в процедуру.
Т.е., для непонятливых, нужно в вышеуказанной строке заменить все функции: Дата(), КонецГода(), ТекущаяДата(), на аналогичные процедуры. (30)Т.е. вы решили конкурс идиотии устроить? Извините, участвовать не буду. (31) Это вы такое предлагаете: использовать процедуры, там где очевидно использовать функции, просто потому, что это можно сделать. А я доказываю обратное.

(33) Это в вашей "религии" вы поклоняетесь процедурам, в обход функциям. Доказательство этому как раз в этой теме: было конкретное решение с функцией, но вам захотелось "вывернуться" и предложить процедуру, хотя профита от этого показано не было. Поэтому, не вижу смысла продолжать дискуссию. Хотите молиться на процедуры, молитесь.

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

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

(36) Если вы меня называете ТС, то это ошибка. И не надо мне приписывать собственные утверждения.

Казалось бы, всё это есть в литературе. Зачем словами переписывать? В этой статье собрана и структурирована информация из разных источников. Однако не всегда и не у всех есть эта литература под рукой. А тут информация в открытом источнике и достаточно структурированная, изложенная простым языком. Тем самым делаем эти знания более понятными и доступными.

Будем рассматривать запись документа, чтобы не загромождать статью и не описывать все типы объектов (у них всё также, за небольшим исключением).

Итак, для чего нам вообще нужны эти обработчики?

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

Последовательность запуска событий (в том порядке, в каком они перечислены) и небольшие подробности:

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

1) Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)

Выполняется на клиенте!

Этот обработчик следует использовать, если необходимо организовать диалог с пользователем перед тем, как записать объект. Запросить дополнительную информацию, предупредить о чём-либо, дать возможность отказаться и т.п.

Второй параметр этого обработчика «ПараметрыЗаписи» имеет тип «Структура». У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои!

Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно благополучно использовать. Например, можно спросить что-то у пользователя и ответ записать в этот параметр. И уже, например, в ПриЗаписиНаСервере использовать этот параметр для анализа и дальнейших действий.

2) Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)

3) Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)

Затем вызывается событие прикладного объекта ОбработкаПроверкиЗаполнения .

Эти два обработчика проверки заполнения реализуются через параметр «ПроверяемыеРеквизиты» типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения «Выдавать ошибку»). И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.

Эти два обработчика событий предназначены :

Для включения в проверку заполнения тех реквизитов, у которых в свойствах «ПроверкаЗаполнения» указано «Не проверять». Для этого надо добавить этот реквизит в массив параметр «ПроверяемыеРеквизиты»
Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения «Выдавать ошибку» в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра «ПроверяемыеРеквизиты»

Имеется несколько особенностей, которые необходимо учитывать:

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

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

4) Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)

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

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

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

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

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

Начало транзакции

5) Модуль объекта ПередЗаписью(Отказ)

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

Для документов в параметры данного обработчика добавляются ещё два параметра: РежимЗаписи, РежимПроведения.

Запись

6) Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)

Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.

Или ПриУстановкеНовогоКода(СтандартнаяОбработка,Префикс)

Эти событии вызываются для объектов у которых указано свойство «Автонумерация» и только для тех объектов, у которых пустой код на момент записи.

7) Модуль объекта ОбработкаУдаленияПроведения (Отказ)

8) Модуль объекта ПриЗаписи(Отказ)

Вызывается после записи объекта в базу данных, но до окончания транзакции записи.

Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый.

Можно ещё отказаться от записи.

9) Модуль объекта ОбработкаПроведения (Отказ, РежимПроведения)

Параметр РежимПроведения определяет как будет проводиться документ: оперативно или неоперативно.

10) Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)

Вызывается после записи объекта в базу данных, но до окончания транзакции записи.. Есть последний шанс отказаться от записи.

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

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

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

Итак, по поводу этого обработчика можно сделать следующие выводы:

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

Завершение транзакции

11) Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)

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

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

Доступны ПараметрыЗаписи, данные которых «приехали» в этом параметре из других обработчиков.

12) Модуль формы ПослеЗаписи(ПараметрыЗаписи)

Выполняется на клиенте!

Можно использовать для того, чтобы визуально что-то отобразить на форме или организовать диалог с пользователем, например выдать предупреждение.

Доступны ПараметрыЗаписи, данные которых «приехали» в этом параметре из других обработчиков.

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

Обработчики событий объекта на которые можно сделать подписку на события:
- ПриУстановкеНовогоНомера / ПриУстановкеНовогоКода
- ПриКопировании
- ОбработкаЗаполнения
- ПередЗаписью
- ПриЗаписи
- ПередУдалением
- ОбработкаПроведения
- ОбработкаУдаленияПроведения
- ОбработкаПроверкиЗаполнения

Дополнение 2: подписки на события для одинаковых источников и действий выполняются в порядке размещения подписок в конфигураторе сверху вниз (т.е. в таком же порядке, как и в дереве метаданных).

Т.е., если для какого-то документа в конфигурации есть две подписки на событие ПриЗаписи, то в начале выполнится та, которая расположена выше.

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

Как вариант указывать в своей подписке источник ДокументОбъект и ставить ее ниже по списку, а в самом обработчике проверять тип документа:
Если ТипЗнч(Источник) <> Тип("ДокументОбъект.МойДокумент") Тогда
Возврат;
КонецЕсли;

Если статья оказалась вам интересной и полезной, то сохраняйте, чтоб не потерять и иметь под рукой- просто нажимайте + и получите от меня + в свою карму :))

Читайте также: