Использование T-SQL для решения проблемы жесткого закрытия периода в бухгалтерской базе данных   

   

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

Проблема как всегда кроется в людях. Даже если программно в 1С закрыть доступ всем пользователям к данным прошлого периода, то и это не всегда гарантирует неизменность данных. Особенно если на фирме несколько программистов и в конфигурации сложная логика и при перепроведении задним числом производится перерасчет. Типичная ситуация это перепроведение документов задним числом. Если она раньше не выполнялась и были изменены данные задним числом то даже при закрытом периоде при простом перепроведении документов может измениться баланс (например, данные по себестоимости или по прибыли).

Сейчас мы рассмотрим относительно простой и в то же время эффективный вариант закрытия периода с помощью триггеров MSSQL.

Как известно, данные по проводкам и агрегационным записям корреспонденций и итогов хранятся в строго определенных таблицах MSSQL. Все изменения производятся, как правило, в транзакциях - это гарантирует целостность данных. Если мы повесим триггер на журнал проводок с проверкой даты изменения, то мы получим надежный механизм защиты.

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

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

 


 

Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта www.softpoint.ru возможны только с письменного разрешения компании "СофтПоинт". Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации "Об авторском праве и смежных правах").

 

Статья: Использование T-SQL для решения проблемы жесткого закрытия периода в бухгалтерской базе данных

Перейти на главную страницу компании "Софтпоинт"