В процессе работы торгового предприятия часто возникает ситуация, когда недобросовестные сотрудники пытаются изменить данные в уже проведенных документах (например, уменьшить количество товара в поступлении или реализации) спустя день или более. В типовой конфигурации 1С:Управление торговлей 10.3 штатный механизм даты запрета редактирования требует ручного обновления. Рассмотрим, как автоматизировать этот процесс, чтобы система самостоятельно блокировала доступ к документам прошлого дня.
Для решения этой задачи мы проанализируем несколько подходов: от использования регламентных заданий до изменения прав доступа и внедрения программных проверок. Разберем по шагам каждый из них.
Самый правильный и «чистый» метод с точки зрения архитектуры 1С — это использование встроенного механизма Даты запрета изменения данных. Этот механизм хранит настройки в регистре сведений ГраницыЗапретаИзмененияДанных. Чтобы не менять дату вручную каждое утро, мы создадим программный код, который будет делать это за нас.
Проанализируем ситуацию: нам нужно, чтобы сегодня менеджеры уже не могли редактировать вчерашние документы. Следовательно, дата запрета должна быть установлена на конец вчерашнего дня. Рассмотрим пример кода, который можно поместить в модуль регламентного задания или в процедуру при начале работы системы (если база файловая):
Процедура УстановитьДатуЗапретаАвтоматически()
// Определяем дату, которую нужно установить (вчерашний день)
НоваяДатаЗапрета = НачалоДня(ТекущаяДата()) - 1;
// Получаем набор записей регистра сведений
НаборЗаписей = РегистрыСведений.ГраницыЗапретаИзмененияДанных.СоздатьНаборЗаписей();
// Если нужно установить для конкретной группы пользователей
// НаборЗаписей.Отбор.Пользователь.Установить(НужнаяГруппаИлиПользователь);
Запись = НаборЗаписей.Добавить();
Запись.ГраницаЗапрета Изменений = НоваяДатаЗапрета;
// Заполняем остальные измерения, если используется сегментация по организациям
НаборЗаписей.Записать();
КонецПроцедуры
Выясним причину, почему это удобно: данный способ не требует изменения каждого документа в конфигурации. Система при попытке записи или проведения любого объекта сама обращается к этому регистру и выдает стандартное сообщение об ошибке, если дата документа меньше установленной границы.
Если штатный механизм по каким-то причинам не подходит (например, нужно более гибкое условие, зависящее от статуса документа или конкретного реквизита), мы можем применить Подписку на событие. Это позволит нам внедрить проверку ПередЗаписью для всех необходимых типов документов одновременно.
Разберем этот метод подробнее. В конфигураторе создадим новый объект Подписка на событие:
ПередЗаписью.Посмотрим на пример реализации кода в обработчике:
Процедура ПроверитьДатуЗапретаПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Пропускаем проверку для администраторов
Если РольДоступна("ПолныеПрава") Тогда
Возврат;
КонецЕсли;
// Если документ уже был проведен и мы пытаемся его изменить
Если Источник.Проведен И НачалоДня(Источник.Дата) < НачалоДня(ТекущаяДата()) Тогда
Сообщить("Редактирование документов за прошлые периоды запрещено!");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Этот код эффективно блокирует попытки изменения любых документов, дата которых меньше текущей. Мы используем НачалоДня, чтобы разрешить редактирование документов, созданных сегодня, но запретить всё, что было создано до 00:00:00 текущих суток.
Как упоминалось на форуме, одним из быстрых способов борьбы с «хитрыми» менеджерами является ограничение прав на Отмену проведения. В 1С:УТ 10.3 права настраиваются в ролях пользователя.
Проанализируем ситуацию: если менеджер не может отменить проведение документа, он не сможет изменить его движения в регистрах. Рассмотрим, как это настроить:
МенеджерПоПродажам).Важно: этот метод имеет недостаток. Если менеджер допустил ошибку в текущий день, он также не сможет её исправить без помощи старшего сотрудника. Поэтому данный вариант лучше комбинировать с первым способом.
Если менеджеры уже были пойманы на изменении документов, то помимо запрета важно внедрить систему слежения. В 1С:УТ 10.3 часто встраивают подсистему Версионирование объектов (из состава Библиотеки Стандартных Подсистем или аналогичную).
Выясним, чем это поможет в нашем случае:
Проанализировав все варианты, мы рекомендуем следующий алгоритм действий для достижения максимальной безопасности:
ГраницыЗапретаИзмененияДанных на ТекущаяДата() - 86400 (одни сутки).Record Level Security (ограничение на уровне записей), чтобы документы прошлых периодов становились недоступными для изменения на уровне прав SQL-запроса, однако помните, что это может замедлить работу системы.Рассмотрим подробнее программный нюанс. Если ваша база работает в файловом режиме, регламентные задания сами по себе не запустятся. Вам потребуется либо выделенный сеанс, либо использование функции ВыполнитьОбработкуЗаданий() в процедуре ПриНачалеРаботыСистемы одного из пользователей (например, того, кто первым приходит в офис).
Таким образом, комбинируя штатные механизмы даты запрета с небольшой доработкой кода для их автоматизации, вы создадите надежную систему защиты данных, которая исключит человеческий фактор и предотвратит махинации с документами задним числом.