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