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