Это новый при записи 1с
Довольно часто встречаются задачи, когда нужно организовать программное заполнение формы какого-то объекта. Скажем, у нас есть форма документа, на форме есть реквизиты, и нам нужно сделать команду, которая заполнит эти реквизиты. Данные для заполнения предполагается получать запросом.
Если конфигурация типовая, то, наверное, самый простой способ решения такой задачи – создать внешнюю обработку вида "Заполнение объекта".
Заполнение формы объекта с помощью внешней обработки
Строка с соответствующим параметром в модуле обработки:
Подключив обработку и указав, для какого документа она назначена, мы получим в форме документа команду. Тип команды задаётся при создании внешней обработки, и от него зависит, где и как будет выполняться обработчик команды. Для наших целей может подойти один из следующих типов команд:
- ВызовСерверногоМетода – обработчик команды располагается в модуле обработки;
- ВызовКлиентскогоМетода – обработчик команды располагается в модуле формы обработки;
- ЗаполнениеФормы – обработчик команды располагается в модуле обработки и позволяет работать с данными формы. Также позволяет вызвать серверную процедуру из модуля формы объекта. При этом можно заполнить форму не записывая объект.
Возможность заполнить форму не записывая объект – это то, что нужно. Ведь пользователь скорее всего ожидает, что по нажатию кнопки форма заполнится, а записываться будет позднее, после проверки результата заполнения. Поэтому выбираем тип команды – ЗаполнениеФормы.
В конечном итоге код в модуле обработки будет выглядеть примерно так:
В общем счёте задача решена. Однако, у такого способа есть небольшой недостаток – команда на форме размещается в определённом месте, а не там, где мы хотим её разместить. К примеру, на форме уже есть группа команд, включающая в себя команды заполнения, и мы хотели бы видеть новую команду в этой группе, но при подключении обработки команда на форме будет расположена отдельно от группы.
В связи с этим можно реализовать другой способ: добавить команду непосредственно в форму объекта – либо в основной конфигурации, либо в расширении – а обработчик команды организовать в модуле формы.
Заполнение формы объекта посредством обработчика команды в модуле формы
Итак, размещаем команду на форме объекта в том месте, которое нам нравится. В модуле формы добавляем клиентскую процедуру обработчика команды, из которой будем вызывать серверную процедуру. Серверную процедуру тоже создадим, она нам понадобится потому, что по условию задачи данные для заполнения получаются запросом.
Над серверной процедурой нужно подумать. В ней у нас будет объект формы с типом "ДанныеФормыСтуктура". Что-либо менять или заполнять в этом объекте не получится, возникнет ошибка "Объект недоступен для изменения".
Можно получить объект документа Объект . Ссылка . ПолучитьОбъект () , и заполнить его данными. Но тогда, чтобы увидеть данные в открытой форме, объект придётся записать, а это не очень хорошо.
Будет лучше, если данные добавятся без записи, и мы можем это сделать с помощью метода РеквизитФормыВЗначение . Этот метод преобразует реквизит формы в объект прикладного типа, и вот этот объект прикладного типа мы можем заполнить, а затем, уже заполненный, преобразовать обратно с помощью метода ЗначениеВРеквизитФормы . Выглядеть это будет примерно так:
Казалось бы, всё это есть в литературе. Зачем словами переписывать? В этой статье собрана и структурирована информация из разных источников. Однако не всегда и не у всех есть эта литература под рукой. А тут информация в открытом источнике и достаточно структурированная, изложенная простым языком. Тем самым делаем эти знания более понятными и доступными.
Будем рассматривать запись документа, чтобы не загромождать статью и не описывать все типы объектов (у них всё также, за небольшим исключением).
Итак, для чего нам вообще нужны эти обработчики?
Очень часто программисту требуется переопределить стандартное поведение системы во время записи документа, а именно: отменить запись, в случае каких-то условий; запросить дополнительную информацию у пользователя; дозаполнить реквизиты; что-то ещё записать в базу данных на основании этой записи; что-то изменить на форме после записи и т.д. и т.п. Каждый программист рано или поздно сталкивается с подобными задачами, потому знать назначение и последовательность запуска этих событий необходимо.
Последовательность запуска событий (в том порядке, в каком они перечислены) и небольшие подробности:
Во многих обработчиках есть параметр «Отказ». Там, где этот параметр присутствует означает, что в этом обработчике ещё можно отказаться от записи, присвоив параметру «Отказ» значение Истина, и тогда запись произведена не будет. И ещё, отдельно отмечу, что п ри программной записи события модуля формы не запускаются!
1) Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)
Выполняется на клиенте!
Этот обработчик следует использовать, если необходимо организовать диалог с пользователем перед тем, как записать объект. Запросить дополнительную информацию, предупредить о чём-либо, дать возможность отказаться и т.п.
Второй параметр этого обработчика «ПараметрыЗаписи» имеет тип «Структура». У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои!
Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно благополучно использовать. Например, можно спросить что-то у пользователя и ответ записать в этот параметр. И уже, например, в ПриЗаписиНаСервере использовать этот параметр для анализа и дальнейших действий.
2) Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
3) Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)
Сначала вызывается событие формы ОбработкаПроверкиЗаполненияНаСервере На данном этапе есть доступ к данным формы.
После этого в памяти сервера создается прикладной объект, соответствующий типу основного реквизита формы, и его данные заполняются из данных формы.
Затем вызывается событие прикладного объекта ОбработкаПроверкиЗаполнения .
Эти два обработчика проверки заполнения реализуются через параметр «ПроверяемыеРеквизиты» типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения «Выдавать ошибку»). И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.
Эти два обработчика событий предназначены :
- Для включения в проверку заполнения тех реквизитов, у которых в свойствах «ПроверкаЗаполнения» указано «Не проверять». Для этого надо добавить этот реквизит в массив параметр «ПроверяемыеРеквизиты»
- Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения «Выдавать ошибку» в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра «ПроверяемыеРеквизиты»
Имеется несколько особенностей, которые необходимо учитывать:
- Если у формы из которой записывается объект в свойствах не установлено «ПроверятьЗаполнениеАвтоматически», то тогда эти обработчики проверки заполнения не вызываются и проверки не происходят!
- Вызываются только при интерактивной записи! При программной записи не вызываются. Для проверки нужно использовать метод объекта ПроверитьЗаполнение(), который инициирует запуск этих событий.
- Для документов, имеющих возможность проведения, эти события проверки заполнения вызываются только при проведении!
Если данные формы не нужны, то используйте обработчик модуля объекта ОбработкаПроверкиЗаполнения
4) Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
В этом обработчике можно дозаполнять реквизиты объекта (через параметр ТекущийОбъект) или провести дополнительные проверки. Есть доступ к данным формы.
Важно понимать, что в предыдущем обработчике (в процессе проверки заполнения) произошло «разделение» формы на форму и прикладной объект (пока только в памяти сервера), данные которого будут записаны в базу данных.
В обработчике модуля формы ПередЗаписьюНаСервере появляется возможность доступа как к данным основного реквизита формы Объект, а также и к самому объекту, который будет записан через параметр обработчика ТекущийОбъект.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (в случае записи документа ДокументОбъект). Т.е. экземпляр класса объект создан, и можно обратиться к его свойствам и методам, но в базу данных ещё не записан.
И тут внимание. ТекущийОбъект - объект, который реально будет записан в информационную базу и дозаполнять реквизиты нужно именно через параметр ТекущийОбъект.
Внесение изменений через реквизит формы объекта Объект не даст никакого результата, его можно только анализировать. В информационную базу эти данные записаны не будут. После завершения транзакции записи, данные из ТекущегоОбъекта запишутся в Объект. Таким образом, все изменения, внесенные в Объект, пропадут.
Также нужно понимать, что при программной записи объекта это событие вызываться не будет.
Поэтому если какие-либо алгоритмы должны выполняться при любом способе записи данных объекта, а не только при записи из формы, их следует размещать в обработчике события объекта (ПередЗаписью), а не в обработчике события формы.
Начало транзакции
5) Модуль объекта ПередЗаписью(Отказ)
В этом обработчике можно провести дополнительные проверки и отказаться от записи.
Для документов в параметры данного обработчика добавляются ещё два параметра: РежимЗаписи, РежимПроведения.
Запись
6) Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.
Или ПриУстановкеНовогоКода(СтандартнаяОбработка,Префикс)
Возникает в момент, когда выполняется установка нового кода элемента справочника, узла плана обмена или кода плана видов характеристик.
Эти событии вызываются для объектов у которых указано свойство «Автонумерация» и только для тех объектов, у которых пустой код на момент записи.
Если установить параметру СтандартнаяОбработка значение Ложь, то новый номер генерироваться не будет и можно программно задать код объекта в данном обработчике.
7) Модуль объекта ОбработкаУдаленияПроведения (Отказ)
Этот обработчик запускается только при отмене проведения документов с целью удаления движений из регистров. При этом неважно как отменяется проведение документа - программно или интерактивно.
8) Модуль объекта ПриЗаписи(Отказ)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи.
Назначение этого обработчика - записать в базу данных дополнительную информацию, связанную с данными записываемого объекта.
Ссылка уже есть и можно записать в базу данных дополнительные данные на основании текущего объекта, используя эту ссылку.
Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый.
Поскольку это событие обрабатывается в транзакции записи основных данных, гарантируется синхронность изменения основных и дополнительных данных. Либо и те и другие будут записаны, либо и те и другие изменения будут отменены при отмене транзакции.
Можно ещё отказаться от записи.
9) Модуль объекта ОбработкаПроведения (Отказ, РежимПроведения)
Этот обработчик запускается только при проведении документов. При этом неважно как проводится документ - программно или интерактивно.
Основное назначение процедуры-обработчика данного события - генерация движений по документу. Именно в данном обработчике прописываются алгоритмы записей в регистры, т.е. программно формируются движения документа.
Параметр РежимПроведения определяет как будет проводиться документ: оперативно или неоперативно.
Если для данного вида документа в конфигурации установлено автоматическое удаление движений, то перед возникновением события все движения по документу будут удалены.
10) Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи.. Есть последний шанс отказаться от записи.
Назначение этого обработчика – записать в базу данных дополнительную информацию, связанную с данными записываемого объекта.
Если данные для записи дополнительной информации находятся в самом объекте, то мы использовали обработчик модуля объекта ПриЗаписи(). А вот если данные находятся в форме, то как раз для таких случаев и предназначено это событие, потому как есть доступ к данным формы.
Этот обработчик ещё используется, если нужны данные параметра обработчика ПараметрыЗаписи, которые «приехали» в этом параметре из других обработчиков.
Через параметр ТекущийОбъект доступны данные, которые уже были записаны в информационную базу и имеет тип класса Объект (ДокументОбъект). Можно обратиться к его свойствам и методам, а также использовать для вызова экспортных методов объекта.
Работать следует именно через этот параметр, то есть не путать с основным реквизитом формы Объект, так как там данные, которые были до записи и его изменения бесполезны потому, что после этого обработчика данные из ТекущегоОбъекта запишутся в Объект.
Если это запись нового объекта, то ТекущийОбъект.Ссылка будет содержать уже конкретное значение ссылки на этот элемент в информационной базе. А вот Объект.Ссылка имеет пустое значение на этом этапе.
Итак, по поводу этого обработчика можно сделать следующие выводы:
- Если нужно выполнять какие-то действия, связанные с записанным объектом, и при этом, например, нужна ссылка на этот объект, необходимо использовать ТекущийОбъект.Ссылка.
- Основной реквизит формы Объект можно использовать только для сравнения того, что «было», с тем, что «записалось».
- Если нужно изменить записанные дополнительные данные на основании данных формы и данных объекта, то необходимо использовать в данном обработчике при обращении к данным объекта ТекущийОбъект
Завершение транзакции
11) Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
После завершения транзакции записи выполняется преобразование данных записанного объекта в данные формы. После этого вызывается данный обработчик. Это последний обработчик, в котором по отдельности доступны данные формы и объект, который был записан.
Этот обработчик используют, когда предполагаются действия над формой. Это те действия, которые должны быть выполнены только в том случае, когда объект 100 % записан (т.е. после транзакции). Например, вывод в форме некоторой дополнительной информации, связанной с данными объекта. Или выполнение каких-либо действий, которые должны быть выполнены только в том случае, когда объект гарантированно записан.
Однако здесь назначение ТекущийОбъект – прямо противоположное тому, что было до этого. В этом обработчике данные записанного объекта уже помещены в форму, т.е. уже загружены в основной реквизит формы Объект и потому ТекущийОбъект изменять бессмысленно: он будет уничтожен при выходе из обработчика.
Но ТекущийОбъект можно использовать, чтобы выполнить какие-то вспомогательные действия, обратившись к его свойствам и методам, а также через вызов экспортных методов объекта. Например, е сли на данном этапе нужны какие-то данные или методы объекта, нужно использовать ТекущийОбъект, а не пытаться получать их через основной реквизит формы Объект.
Доступны ПараметрыЗаписи, данные которых «приехали» в этом параметре из других обработчиков.
12) Модуль формы ПослеЗаписи(ПараметрыЗаписи)
Выполняется на клиенте!
Можно использовать для того, чтобы визуально что-то отобразить на форме или организовать диалог с пользователем, например выдать предупреждение.
Доступны ПараметрыЗаписи, данные которых «приехали» в этом параметре из других обработчиков.
Часто бывает так, что использовать подписку на событие эффективнее, потому что не затрагивает модули, находящиеся на поддержке и очередное обновление конфигурации проходит с куда меньшими затратами труда и времени.
Обработчики событий объекта на которые можно сделать подписку на события:
- ПриУстановкеНовогоНомера / ПриУстановкеНовогоКода
- ПриКопировании
- ОбработкаЗаполнения
- ПередЗаписью
- ПриЗаписи
- ПередУдалением
- ОбработкаПроведения
- ОбработкаУдаленияПроведения
- ОбработкаПроверкиЗаполнения
Дополнение 2: подписки на события для одинаковых источников и действий выполняются в порядке размещения подписок в конфигураторе сверху вниз (т.е. в таком же порядке, как и в дереве метаданных).
Т.е., если для какого-то документа в конфигурации есть две подписки на событие ПриЗаписи, то в начале выполнится та, которая расположена выше.
Дополнение 3 : подписки с источником общего типа (ДокументОбъект, СправочникОбъект) выполняются позже, чем с источником конкретного типа, даже если он составной.
Как вариант указывать в своей подписке источник ДокументОбъект и ставить ее ниже по списку, а в самом обработчике проверять тип документа:
Если ТипЗнч(Источник) <> Тип("ДокументОбъект.МойДокумент") Тогда
Возврат;
КонецЕсли;
Если статья оказалась вам интересной и полезной, то сохраняйте, чтоб не потерять и иметь под рукой- просто нажимайте + и получите от меня + в свою карму :))
Большинство клиентов 1С используют типовые конфигурации, в которые, тем не менее, вносят изменения для комфортной работы и соответствия имеющимся бизнес-процессам. Администраторы знают – чем больше таких изменений внесено, тем сложнее и дольше производить обновления, которые выпускаются к тому же довольно часто. Поэтому разработчики в свою очередь стремятся к минимизации изменений типовой конфигурации. Для разрешения этой дилеммы был разработан механизм подписок на события в 1С 8.3. Подписки позволяют проделать нужные операции, не затрагивая стандартные процедуры и функции конфигурации 1С.
Создаем подписку в 1С
Тип источников напрямую влияет на предлагаемые системой события. Выбирая одно из них, помните, что сначала отрабатывают стандартные процедуры, а потом настает очередь подписок в конфигурации. После события приходит очередь определиться с тем, в каком общем модуле будет записана наша процедура. В свойстве «Обработчик» необходимо указать один из присутствующих в конфигурации модулей с установленным свойством «Серверный».
После выбора модуля и перехода в него, остается лишь описать действия процедуры, и на этом создание подписки в конфигурации будет закончено. Далее можно обновлять конфигурацию 1C и проверять результат работы описанной на встроенном языке процедуры. Разработчики с помощью подписок делают проверки перед записью или проведением документа для контроля заполнения нужных полей. Также удобно заполнять дополнительные регистры – документ или элемент справочника уже записан, и вы можете использовать достоверные данные.
Механизм расширений, который активно используют разработчики 1С версии 8.3.6 и выше, позволяет более тонко прописывать подписки, не затрагивая типовую конфигурацию. При обновлении добавленные разработчиком проверки могут мешать реструктуризации документов, поэтому необходимо отключить подписки. Легче отключить одно расширение, чем предусматривать возможность отключения всех подписок в конфигурации, которых может быть более сотни.
Подписки в расширениях
Расширение – это конфигурация 1С, которая «накладывается» на основную конфигурацию. Само по себе расширение не является функционирующей системой, но благодаря ему разработчики получают свободу действий. Основное преимущество заключается в том, что при обновлении расширение отключается, и обновляется типовая конфигурация. Именно поэтому разработчики стараются переносить свои подписки в расширение.
В расширении есть возможность дополнять модули документов и других объектов и их форм. Достаточно добавить их из основной конфигурации в расширение. Также разработчики могут выбирать, когда исполнять код из расширения относительно процедур из основной конфигурации:
- Запускайте конфигуратор;
- Открывайте меню «Конфигурация» – «Расширения конфигурации»;
- Добавляйте новое расширение конфигурации и называйте его в соответствии с его предназначением;
Чтобы добавить в расширение подписки на события, нужно добавить в расширение документ. Находим его в основной конфигурации, жмем по правой кнопке и в контекстном меню выбираем команду «Добавить в расширение». После это находим нужный документ в расширении и через контекстное меню открываем его модуль объекта.
Дорабатывайте конфигурации с минимальными изменениями и обновления не будут отнимать у вас много времени.
В программах «1С» реализованы механизмы, позволяющие отслеживать изменения в базах различными способами:
- С помощью журнала регистрации. Платформенный механизм, позволяющий узнать кто и когда менял объект, без возможности детально отследить изменившиеся значения объектов;
- Через платформенный механизм ИсторияДанных. Отметим, что данный механизм появился в платформе 8.3.11 и позволяет работать с версионированием через встроенные механизмы платформы, что является несомненным плюсом.
- Через версионирование объектов (активируется самостоятельно). Данный механизм обеспечивается наличием в конфигурации подсистемы БСП «Версионирование объектов». Соответственно присутствует во всех современных типовых конфигурациях, разработанных на основе БСП (Библиотека стандартных подсистем).
Версионирование – это хранение истории изменений объектов. В отличие от журнала регистрации, в котором может храниться история изменения объектов, механизм версионирования позволяет пользователю:
- Увидеть изменения, внесенные пользователями;
- Просматривать любые версии объектов;
- Сравнивать версии объектов между собой;
- Восстановить предыдущую версию объекта.
Рассмотрим настройку подсистемы БСП «Версионирования объектов» в 1С 8.3 Бухгалтерия.
Как включить или отключить версионирование объектов
Настройку можно включать не только для всего объекта целиком, но и выборочно – для его отдельных составных частей, включая реквизиты табличных частей, и тем самым экономить место.
Чтобы механизм компактно хранил историю изменения данных пользователя, и не вышло так, что история изменения объектов занимает больше места, чем сами объекты, и в результате функционал приводит к замедлению работы программы, необходимо правильно выполнить настройку этого механизма.
Включить механизм может разработчик в конфигураторе (его лучше использовать в случаях, когда история данных потребуется во всех режимах работы программы), а также и сам пользователь: в пользовательском интерфейсе в режиме «1С:Предприятие» включить версионирование объектов можно в пункте меню «Администрирование-Общие настройки-История изменений».
«Включение» версионирования заключается в настройке объектов конфигурации, для которых будет вестись учет изменений. При этом ведение истории можно включать не только для всего объекта, но и для его отдельных составных частей. Установив галочку «Хранить историю изменений», переходим по гиперссылке «Настройки хранения».
С помощью кнопки «Установить когда сохранять версии» мы можем установить когда сохранять версию – «Никогда», «При записи», «При проведении» или «По умолчанию». Настройка «По умолчанию» предполагает рекомендуемые настройки: для справочников – «Никогда» не создавать версии, для документов – «Создавать версии при проведении», для бизнес-процессов – «Создавать версии при старте». Настройка выполняется для всех объектов, но целесообразнее выполнить настройку отдельно для каждого объекта в списке.
Следующий параметр – «Установить срок хранения версий».
После активации данной настройки у объекта появляется дополнительный пункт в меню – «История изменений» (кнопка «Еще» в журнале документов), а также кнопка на панели инструментов «Перейти к отчету по версиям объектов».
Эти же пункты будут доступны и из самого документа.
История изменений выглядит следующим образом: в открывшейся форме выводится список всех изменений объекта. Версию можно открыть или сравнить с любой из списка. Выбрать несколько строк можно с помощью кнопок «Shift» и «Ctrl».
И в случае необходимости через кнопку «Перейти на версию» мы попадаем на выделенную (нужную) версию документа. Изменения, внесенные после этой версии, будут отменены.
Рассмотренный нами механизм может быть очень полезен. С его помощью можно следить за историей изменения документов и справочников. Он хранит не только данные о пользователе, изменившем объект, но и позволяет увидеть, какие были произведены изменения, сравнить версии и при необходимости восстановить один из вариантов.
Проверка изменения данных при записи объектов
В некоторых случаях при записи объектов возникает необходимость проверки, какие данные объекта были изменены и какие были значения до изменения.
Допустим, при записи документа, может возникнуть потребность проверить, не изменилась ли дата документа, и если дата изменилась, то откорректировать движения документа, которые не обновляются при его проведении (например, вводятся вручную).
На первый взгляд видится возможность запомнить старое состояние реквизита в переменной модуля объекта, анализировать его при записи документа, и соответственно при записи запоминать новое значение для анализа в процессе следующей записи. Однако этот метод является неправильным. Дело в том, что запись объекта происходит в транзакции. Соответственно, тот факт, что данные записаны, еще не означает, что они действительно будут изменены в базе данных. Разработчик прикладного решения не имеет возможности обработать успешное или неуспешное завершение транзакции. Соответственно нет возможности и обеспечить хранение в модуле значения реквизита адекватно соответствующего тому значению, которое хранится в базе данных.
Правильным способом реализации такой проверки является считывание значений тех реквизитов, изменения которых нужно анализировать, непосредственно из базы данных.
Например, считывание может быть выполнено обращением через ссылку:
Однако следует учитывать, что при обращении к ссылке считывается весь объект целиком. То, что он ранее считывался и находится в кеше, здесь не поможет, так как при работе транзакции используется отдельный кеш. Соответственно, затраты на получение одного или двух реквизитов могут оказаться неоправданно большими. Поэтому можно рекомендовать для считывания отдельных реквизитов использовать запросы. Например:
В этом случае из базы данных будет считан ровно один реквизит, который требуется анализировать.
Заметим, что таким способом можно, например, определить, что объект помечается на удаление. Для этого достаточно проверить, изменение поля ПометкаУдаления .
Однако если нам нужно обработать изменение реквизита после записи документа, например, в обработчике ПриЗаписи , то, разумеется, считывание данных из базы данных не подходит, так как информация в базе данных уже изменена. В этом случае нужно само считывание выполнять в обработчике ПередЗаписью и запоминать считанные значения в переменных модуля. А уже анализ выполнять в обработчике ПриЗаписи .
Читайте также: