Как в 1С:Бухгалтерия 2.0 разрешить создание документов, но запретить их редактирование?

← На главную

В практике работы любой бухгалтерии часто возникает задача ограничить права определенных сотрудников. Типичное требование главного бухгалтера — разрешить пользователю (например, оператору или младшему бухгалтеру) создавать новые документы, но полностью исключить возможность редактирования уже существующих или ранее сохраненных данных. На первый взгляд задача кажется стандартной, однако при попытке решить ее только лишь настройкой ролей администраторы сталкиваются с серьезными техническими препятствиями. В этой статье мы подробно разберем, почему штатное разделение прав в ролях не всегда работает так, как ожидается, и рассмотрим наиболее эффективные способы решения этой задачи программированием и штатными инструментами.

Почему стандартная настройка ролей в конфигураторе приводит к ошибкам?

Рассмотрим популярную ошибку, которую совершают многие администраторы. Пытаясь решить задачу «в лоб», они копируют типовую роль (например, Бухгалтер), переименовывают ее и снимают флажки с прав Изменение и Редактирование для нужных документов, оставляя при этом права Чтение, Добавление и Просмотр. Однако при попытке пользователя создать документ система мгновенно выдает ошибку «Нарушение прав доступа». Выясним причину такого поведения платформы «1С:Предприятие».

Существует несколько технических причин, почему урезание прав роли блокирует работу:

Запись связанных регистров. При проведении и даже простом сохранении любого документа в 1С система делает сопутствующие записи в регистры бухгалтерии, накопления или сведений. Если у новой роли урезаны права на изменение этих связанных регистров (или нет прав на их чтение), платформа заблокирует транзакцию записи самого документа.
Интерактивное добавление vs Неинтерактивное изменение. Для создания документа пользователю необходимы права Добавление и Интерактивное добавление. Но как только документ в первый раз записывается в базу данных, он перестает быть новым в памяти платформы. Любое повторное нажатие кнопки «Записать» (например, при дозаполнении документа в процессе работы) расценивается платформой как действие Изменение, на которое у роли стоит жесткий запрет.
Проблемы обновления метаданных. В конфигурациях, использующих механизмы Библиотеки стандартных подсистем (БСП), при ручном добавлении новых ролей в конфигураторе система не видит их корректно в режиме «1С:Предприятие», пока не будет запущено обновление вспомогательных данных. Без этого подсистема управления доступом будет выдавать системную ошибку прав.

Помимо прочего, внесение изменений непосредственно в структуру ролей основной конфигурации снимает ее с поддержки (переводит в режим «Редактируется с сохранением поддержки»). Это существенно усложняет последующие обновления программного продукта.

Решение №1. Подписка на событие ПередЗаписью

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

Разберем по шагам, как настроить такую подписку в конфигураторе:

Откройте конфигуратор и перейдите в ветку Общие -> Подписки на события.
Добавьте новую подписку на событие, назовите ее, например, ЗапретРедактированияДокументовПередЗаписью.
В свойстве Источник выберите типы документов, для которых должно действовать ограничение (или выберите тип ДокументОбъект, чтобы ограничение распространялось на все документы базы).
В свойстве Событие выберите ПередЗаписью.
В свойстве Обработчик укажите процедуру в общем модуле (модуль должен быть неглобальным, с установленными свойствами Сервер и Вызов сервера).

Рассмотрим простейший пример программного кода для этой процедуры, который блокирует изменение любого не нового документа:


Процедура ЗапретРедактированияДокументовПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт

    // Проверяем, назначен ли этот запрет текущему пользователю.
    // (Для примера используем проверку на наличие роли "ОграниченныйДоступ")
    Если РольДоступна("ОграниченныйДоступ") Тогда
        
        // Если документ уже существует в базе (не является новым)
        Если НЕ Источник.ЭтоНовый() Тогда
            Отказ = Истина;
            ВызватьИсключение "У вас нет прав на редактирование существующих документов!";
        КонецЕсли;
        
    КонецЕсли;

КонецПроцедуры

Важное примечание: Использование жесткой конструкции Если НЕ Источник.ЭтоНовый() имеет один существенный практический недостаток. Пользователь может начать создавать документ, частично заполнить его, нажать кнопку «Записать» (чтобы не потерять данные), после чего документ запишется и перестанет быть новым. С этого момента пользователь больше не сможет внести в него ни одного изменения. Чтобы избежать этой проблемы, проанализируем более гибкие сценарии логики.

Решение №2. Продвинутая логика ограничений в подписке на события

Чтобы не парализовать работу пользователей, мы можем усложнить условия проверки в подписке на событие. Рассмотрим три наиболее популярных сценария автоматического контроля.

Вариант А. Блокировка только проведенных документов

Пока документ является просто записанным черновиком, пользователь может его редактировать сколько угодно раз. Но как только документ проводится (то есть формирует движения в учете), редактирование закрывается.


Если РольДоступна("ОграниченныйДоступ") Тогда
    // Если документ уже проведен и мы пытаемся его изменить
    Если Источник.Проведен И НЕ Источник.ЭтоНовый() Тогда
        Отказ = Истина;
        Сообщить("Редактирование проведенных документов запрещено вашим руководством!", СтатусСообщения.Важное);
    КонецЕсли;
КонецЕсли;

Вариант Б. Проверка по реквизиту «Автор» или «Ответственный»

Документ разрешено редактировать только тому пользователю, который его создал. Другие пользователи с аналогичной ролью изменить чужой документ не смогут.


Если РольДоступна("ОграниченныйДоступ") Тогда
    // Проверяем соответствие текущего пользователя и ответственного в документе
    Если НЕ Источник.ЭтоНовый() И (Источник.Ответственный <> ПараметрыСеанса.ТекущийПользователь) Тогда
        Отказ = Истина;
        Сообщить("Вы не можете редактировать данный документ, так как не являетесь его автором!", СтатусСообщения.Важное);
    КонецЕсли;
КонецЕсли;

Вариант В. Ограничение по времени (временное окно)

Создателю разрешается вносить любые правки в документ, но только в течение ограниченного времени (например, в течение текущего дня или нескольких часов с момента создания документа).


Если РольДоступна("ОграниченныйДоступ") Тогда
    Если НЕ Источник.ЭтоНовый() Тогда
        // Разрешаем редактирование только в день создания документа
        Если НачалоДня(Источник.Дата) <> НачалоДня(ТекущаяДата()) Тогда
            Отказ = Истина;
            Сообщить("Редактирование документов за прошлые дни для вас заблокировано!", СтатусСообщения.Важное);
        КонецЕсли;
    КонецЕсли;
КонецЕсли;

Решение №3. Ограничение на уровне формы (ПриОткрытии)

Если мы хотим, чтобы пользователь сразу видел, что документ доступен ему только для чтения (без возможности интерактивного изменения полей ввода), мы можем программно заблокировать элементы формы. Для этого используется событие формы ПриОткрытии.

Посмотрим на пример кода, который можно прописать в модуле формы документа:


Процедура ПриОткрытии()

    Если РольДоступна("ОграниченныйДоступ") И НЕ ЭтотОбъект.ЭтоНовый() Тогда
        // Делаем форму доступной только для просмотра
        ЭтотОбъект.ТолькоПросмотр = Истина;
    КонецЕсли;

КонецПроцедуры

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

Решение №4. Как избежать «мучений с обновлениями» с помощью расширений

Если ваша база «1С:Бухгалтерия 2.0» работает на современной платформе «1С:Предприятие 8.3» (даже с использованием интерфейса обычных форм), вы можете полностью уйти от проблемы изменения типовой конфигурации. Для этого мы рекомендуем использовать **Расширения конфигурации**.

Разберем, как перенести доработку в расширение:

В конфигураторе выберите пункт меню Конфигурация -> Расширения конфигурации.
Добавьте новое расширение, укажите его назначение (например, Адаптация).
Перенесите в расширение только те объекты, которые вам нужны (например, вашу подписку на событие и общий модуль).
Снимите галочку Безопасный режим в свойствах расширения, чтобы код мог выполняться без ограничений прав.

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

Решение №5. Штатный механизм без программирования: Даты запрета изменения

Если главбух требует закрыть возможность редактирования документов прошлых периодов, программировать вообще не нужно. В БП 2.0 есть штатный и очень гибкий инструмент — Дата запрета изменения данных.

Для его настройки выполните следующие действия:

Перейдите в меню Сервис -> Настройка прав доступа -> Даты запрета изменения данных.
Установите флажок «Использовать ограничение изменения данных».
Настройте ограничение: его можно задать как единым для всех пользователей, так и индивидуально (по организациям или конкретным пользователям/группам).
Установите способ указания даты запрета. Вы можете выбрать динамическое смещение, например, «Конец прошлого дня» или «Предыдущий месяц».

Если настроить автоматическое смещение даты запрета на «Вчера», пользователи смогут беспрепятственно создавать и проводить любые документы за сегодня, но любые вчерашние документы автоматически закроются для редактирования на уровне всей платформы.

Резюме

Мы подробно проанализировали проблему ограничения прав на редактирование при сохранении возможности создания документов в 1С:БП 2.0. Пытаться решить этот вопрос исключительно манипуляциями с ролями в конфигураторе не рекомендуется из-за архитектурных особенностей платформы. Наиболее гибким и правильным техническим решением является создание Подписки на событие ПередЗаписью с проверкой состояния документа (новый, проведенный или ограничение по времени), желательно вынесенной в отдельное расширение конфигурации. Для простых сценариев закрытия прошлых периодов отлично подойдет типовой механизм Даты запрета изменения данных.