Как ограничить пользователю право на неоперативное проведение документов старше 3 дней?

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

Понимание проблемы неоперативного проведения

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

Реализация через программную проверку в модуле объекта

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

Рассмотрим пошагово, как построить логику проверки:

1. Определим роль пользователя: создадим специальную роль, например, РазрешитьНеоперативноеПроведение.
2. В модуле объекта документа вызовем процедуру проверки.
3. Если пользователь не обладает указанной ролью и дата документа старше трех дней от текущей, мы будем вызывать исключение.

Посмотрим на пример реализации кода:

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    Если РежимЗаписи = РежимЗаписиДокумента.Проведение ИЛИ РежимЗаписи = РежимЗаписиДокумента.Запись Тогда
        Если Не РольДоступна("РазрешитьНеоперативноеПроведение") Тогда
            РазницаДней = (ТекущаяДата() - Объект.Дата) / 86400;
            Если РазницаДней > 3 Тогда
                ВызватьИсключение "Неоперативное проведение документов старше 3 дней запрещено для вашего пользователя.";
            КонецЕсли;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Использование подписки на событие

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

Для этого создайте общую подписку на событие ОбработкаПроведения (или ПередЗаписью) для выбранного списка документов. В обработчике этой подписки мы будем получать ссылку на документ, проверять текущего пользователя и дату, после чего принимать решение об отказе в записи.

Почему не стоит использовать шаблоны ограничений (RLS)

Часто возникает соблазн решить задачу через ШаблоныОграничений доступа на уровне записей. Однако мы крайне не рекомендуем этот путь по нескольким причинам:

• Производительность: Условия RLS вычисляются при каждом обращении к данным, что может серьезно замедлить работу всей системы.
• Сложность отладки: Ошибки, вызванные RLS, часто выглядят для пользователя как «ошибка доступа» или отсутствие видимости данных, что затрудняет понимание причин отказа в проведении.
• Кэширование прав: Платформа 1С кэширует права доступа, и динамические условия типа «текущая дата» могут конфликтовать с этим механизмом.

Альтернативные подходы к учету

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

Использование «Даты запрета редактирования» — встроенный механизм 1С, который позволяет закрывать периоды для всех или определенных пользователей. Это стандарт индустрии, который обеспечивает надежность данных.

Ввод документов «Сторно» или «Корректировка» — вместо изменения данных прошлого периода, мы вносим корректирующий документ текущей датой. Это позволяет сохранить прозрачность учета и исключить «хруст» базы, о котором часто говорят опытные разработчики. Разберем этот вариант как предпочтительный, так как он обеспечивает отсутствие проблем с пересчетом себестоимости и складских остатков.

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