Механизм «Даты запрета изменения» в конфигурациях 1С:Комплексная автоматизация (КА 2.4), 1С:ERP, УТ и других решениях на базе БСП (Библиотеки стандартных подсистем) предоставляет очень гибкие возможности. Однако при включении детализации по пользователям, разделам учета и объектам часто возникает путаница: в каком порядке применяются эти настройки и какое ограничение сработает, если они противоречат друг другу? Разберем логику работы этого механизма подробно и по шагам.
Проанализируем базовый алгоритм. Система использует жесткую иерархию приоритетов. Если для конкретной операции (комбинации пользователя, раздела и объекта) подходит несколько настроек, 1С всегда выбирает настройку с наивысшим приоритетом, игнорируя остальные.
Рассмотрим 9 уровней приоритета (от самого высокого к самому низкому), которые заложены в программном коде общих модулей 1С:
Посмотрим на пример: если для пользователя "Иванов" установлена индивидуальная дата запрета на уровне «Любой раздел и любой объект» (приоритет 7), а для группы "Все пользователи" установлена дата на конкретный раздел учета (приоритет 6), то для "Иванова" сработает правило группы "Все пользователи", так как детализация по разделу имеет больший приоритет.
Из-за описанной выше системы приоритетов возникает неочевидный нюанс. Выясним причину, почему бывает сложно дать полные права на редактирование одному человеку, если для остальных настроены строгие ограничения по разделам.
Если вы хотите настроить одному пользователю "доступ всегда и везде" (поставить пустую дату без ограничений), но не укажете в его настройках конкретные разделы учета, его правило получит низкий приоритет (уровень 7). Если при этом для всех остальных пользователей заданы ограничения с указанием конкретных разделов (уровень 6), то для нашего суперпользователя сработают эти общие ограничения по разделам!
Чтобы обойти эту проблему, вам придется явно дублировать настройки: назначать этому пользователю разрешение персонально по каждому разделу учета, который присутствует в базе. Иначе приоритет более детализированной общей настройки перекроет его персональную общую настройку.
Рассмотрим ситуацию, когда один и тот же сотрудник состоит в двух разных группах пользователей, и для этих групп установлены разные даты запрета одного уровня приоритета. Что произойдет в этом случае?
В типовой логике платформенных запросов БСП для таких случаев применяется наиболее строгая из дат (максимальная дата запрета). Это сделано для того, чтобы гарантировать безопасность закрытого периода. Система выберет дату, которая сильнее ограничивает права на изменение.
Обратите внимание на то, как в КА 2.4 и ERP реализована привязка к объектам. В качестве «объектов» детализации чаще всего выступают элементы справочника Организации. Типовой функционал не позволяет установить дату запрета строго на организацию в отрыве от разделов учета. Они всегда идут в связке, что требует внимательности при настройке, чтобы не запутаться в матрице доступов.
Дату запрета не обязательно каждый раз менять вручную. Разберем механизм относительных дат. В системе можно выбрать динамические значения, например, «Конец прошлого месяца» или «Конец прошлого квартала».
Кроме того, можно настроить отсрочку — указать количество дней после наступления новой относительной даты, в течение которых пользователям еще разрешено вносить корректировки в закрываемый период. Таймер отсчитает заданное время, и дата запрета сдвинется автоматически без участия администратора.
Важно понимать разницу между ручным вводом и синхронизацией. Дата запрета изменения защищает базу только от ручных правок пользователей. Она не влияет на изменения, которые приходят при синхронизации данных (обменах) из других информационных баз.
Для защиты от изменения данных извне существует отдельная настройка — «Дата запрета загрузки данных». При этом следует помнить, что запрет загрузки не применяется для узлов Распределенной информационной базы (РИБ), так как РИБ технически требует полной идентичности всех узлов.
Запрет распространяется не только на запись, проведение или отмену проведения документов. Если период закрыт, пользователи не смогут даже просто пометить объекты на удаление (или снять пометку), если дата создания этих объектов (документов) попадает в закрытый период. В первую очередь этот механизм контролирует проводкообразующие документы и документы, формирующие движения по регистрам накопления.
Наличие у пользователя роли "Полные права" автоматически не отключает действие даты запрета. Для управления самими датами требуется назначить специальную роль — «Добавление и изменение дат запрета изменения».
Если вам как программисту необходимо выполнить служебную обработку данных в закрытом периоде (например, массовое перепроведение или исправление реквизитов), вы можете временно отключить этот механизм в коде. Для этого в БСП предусмотрен специальный метод, который вызывается в привилегированном режиме:
УстановитьПривилегированныйРежим(Истина);
ДатыЗапретаИзменения.ОтключитьПроверкуДатЗапрета();
// ... ваш код для изменения и записи объектов в закрытом периоде ...
Используйте этот метод с осторожностью, чтобы не нарушить целостность регламентированного и управленческого учета в закрытых периодах.