В ряде случаев документы можно проводить только один раз, так их повторное проведение (иначе называемое перепроведением) приводит к некорректным финансовым результатам.
Существует несколько способов избежать перепроведения. Некоторые из них:
- Запрет любого изменения документов за определённый период времени;
- Выполнение перепроведения при помощи специальных обработок, которые не затрагивают документы, для которых перепроведение не допустимо.
В этой статье мы обсудим ещё один способ защиты от нежелательного перепроведения документов. Это блокировка повторного проведения в программном коде.
Зачем это нужно
Правды ради стоит отметить, что блокировка перепроведения на уровне программного кода большинством разработчиков не применяется по причине того, что гораздо проще ввести запрет по периоду времени или дать пользователю обработку, которая перепроводит только необходимые документы. Однако все эти способы не обеспечивают достаточной защиты от некорректных действий пользователя. Особенно, если речь идёт о доработанной типовой конфигурации в отсутствие должного документирования со стороны разработчика и должного уровня инструктажа в организации.
Запрет по периоду времени можно перенастроить или вообще отключить. А, о самописной обработке неподготовленный сотрудник компании может просто не знать до тех пор, пока не станет уже слишком поздно.
Но, если нежелательное перепроведение заблокировано на уровне кода бухгалтерия и руководство могут спать гораздо спокойнее.
Данный способ имеет два варианта реализации.
Вариант 1. Запрос в обработке проведения («плохой» вариант)
Принцип работы этого варианта построен на том, что любой регистр (в частности регистр накопления) при проведении всегда сохраняет информацию о так называемом регистраторе. Документе, при проведении которого была сформирована та или иная запись. Следовательно, если документ ранее уже проводился ссылка на него уже есть в регистре.
Для того чтобы проверить был ли проведён документ, в обработке проведения в начале выполняется запрос, который проверяет количество записей в регистре имеющих данный документ в качестве регистратора. Если оно равно нулю (документ не проводился) проведение выполняется.
Ниже приведён пример реализации данного варианта:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
Процедура ОбработкаПроведения(Отказ, Режим) Перем Авторы; Перем Элемент; Перем Количество; // Получаем сведения о том, проводился ли данный документ Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ | КОЛИЧЕСТВО(ТестовыйРегистрНакопления.Регистратор) КАК Регистратор |ИЗ | РегистрНакопления.ТестовыйРегистрНакопления КАК ТестовыйРегистрНакопления |ГДЕ | ТестовыйРегистрНакопления.Регистратор = &Регистратор;"; Запрос.УстановитьПараметр("Регистратор", ЭтотОбъект.Ссылка); РезультатЗапроса = Запрос.Выполнить(); ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать(); Пока ВыборкаДетальныеЗаписи.Следующий() Цикл Количество= ВыборкаДетальныеЗаписи.Регистратор; КонецЦикла; // Если данный документ ранее уже проводился завершаем обработку проведения до записи движения Отказ=(Количество>0); // Движение регистра Движения.ТестовыйРегистрНакопления.Записывать = Истина; Движение = Движения.ТестовыйРегистрНакопления.Добавить(); Движение.ВидДвижения = ВидДвиженияНакопления.Приход; Движение.Период = Дата; Движение.Сумма = Сумма; Авторы = Справочники.Авторы; Элемент =Авторы.СоздатьЭлемент(); Элемент.Наименование = Автор; Элемент.Записать(); КонецПроцедуры |
Почему этот вариант назван «плохим»?
Дело в том, что, во-первых, он сам по себе очень громоздкий. В главных, количество записей в регистре информационной базы, работающей в организации может быть очень большим. Как следствие возможно падение производительности.
Поэтому использовать данный вариант настоятельно не рекомендуется.
По существу, это решение задачи «в лоб» и гораздо эффективнее вариант 2.
Вариант 2. Обработка события «Перед записью» («хороший» вариант)
Момент проведения документа на самом деле можно поймать не только в соответствующей обработке, но и в процедуре обработки события «ПередСохранением». В этом случае отличительным признаком проведения является значение параметра «РежимЗаписи».
Если значение свойства «Проведён» документа равно «Истина» и режим записи соответствует проведению, то мы имеем дело с перепроведением.
Ниже приведён пример реализации подобной блокировки перепроведения:
|
1 2 3 4 5 |
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения) Если ЭтотОбъект.Проведен И РежимЗаписи=РежимЗаписиДокумента.Проведение Тогда Отказ=Истина КонецЕсли; КонецПроцедуры |
Это на порядок проще в реализации чем подход, предложенный ранее и не создаёт проблем с производительностью.
К моменту вызова стандартной процедуры обработки проведения свойство «Проведён» уже будет иметь значение «Истина» независимо того был ли документ проведён ранее или проводится впервые.
В 1С Предприятие процесс проведения документа представляет собой единую транзакцию. Поэтому в случае возникновения нештатной ситуации данные останутся корректными вследствие отката всех изменений. Однако из-за того, что свойство «Проведён» изменяет своё значение прежде чем отработает программная логика, связанная с движением документа, определить в обработке проведения с его помощью перепроведение невозможно.
По этим причинам использование данного варианта программной блокировки перепроведения является предпочтительным.
Добавить комментарий