Как настроить права, интерфейс и индивидуальные даты запрета изменения для бухгалтера в УТ 11.2?

← На главную

При настройке рабочих мест для профильных специалистов, таких как бухгалтер по реализации, перед разработчиком и администратором 1С часто встают две важные задачи. Во-первых, необходимо ограничить видимость интерфейса, оставив только целевые разделы (например, Продажи, Закупки, Склад, Казначейство). Во-вторых, нужно настроить гибкие даты запрета редактирования данных — так, чтобы разные типы документов имели свои уникальные границы запрета (например, реализация товаров блокировалась прошлым днем, а счета на оплату можно было редактировать без ограничений).

В рамках этой статьи мы подробно разберем, как решить эти задачи в конфигурации 1С:Управление торговлей, редакция 11.2 (УТ 11.2), используя как типовые механизмы, так и аккуратную программную доработку.

Типичные ошибки при проектировании прав и интерфейсов

Прежде чем перейти к правильному алгоритму настройки, давайте разберем популярную ошибку, которую часто совершают начинающие специалисты. Попытка скопировать роль ПолныеПрава, переименовать её (например, в БухгалтерРеализации) и затем снять флаги видимости подсистем в конфигураторе приводит к следующим проблемам:

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

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

Часть 1. Правильная настройка интерфейса и прав пользователя (скрытие подсистем)

В системе 1С:Предприятие 8.3 все настройки прав и видимости разделов должны выполняться в режиме 1С:Предприятие с использованием механизмов подсистемы управления доступом. Давайте разберем этот процесс по шагам.

Шаг 1. Создание профиля групп доступа

Вместо того чтобы вносить изменения в конфигураторе, откроем программу под администратором и перейдем в раздел НСИ и администрирование → Настройка пользователей и прав → Профили групп доступа.

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

ДобавлениеИИзменениеРеализацийТоваровУслуг — для работы с расходными накладными;
ЧтениеЗаказовКлиентов — для просмотра заказов покупателей без возможности их изменения;
ДобавлениеИИзменениеДокументовНаличныхДенежныхСредств и ДобавлениеИИзменениеДокументовБезналичныхДенежныхСредств — для работы с ПКО, РКО и банковскими выписками;
РазделПродажи, РазделЗакупки, РазделСклад, РазделКазначейство — роли, определяющие базовую видимость соответствующих разделов на панели разделов.

Обязательно убедитесь, что в профиль включена роль ЗапускТонкогоКлиента (или ЗапускВебКлиента), а также роль БазовыеПраваУТ (или аналогичная базовая роль конфигурации). Без базовых прав пользователь не сможет даже авторизоваться в системе.

Шаг 2. Создание группы доступа и привязка пользователя

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

При таком подходе все ненужные разделы (например, «Бюджетирование», «Администрирование», «Производство») исчезнут автоматически, так как у пользователя не будет ни одной роли, дающей право просмотра объектов из этих разделов.

Шаг 3. Персональная настройка панели разделов

Если пользователю по роду деятельности необходимы права на просмотр документов из раздела «Закупки», но сам раздел визуально загромождает его рабочий стол, мы можем скрыть его непосредственно в режиме предприятия под учетной записью пользователя:

Откроем базу под пользователем «Бухгалтер реализации».
В правом верхнем углу нажмем кнопку главного меню (три горизонтальные полосы или шестеренка) → Настройки → Настройка панели разделов....
В открывшемся окне перенесем ненужные разделы из правой колонки («Выбранные разделы») в левую колонку («Доступные разделы») и нажмем ОК.

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

Часть 2. Настройка дат запрета изменения данных

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

Типовой функционал настройки дат запрета

Для активации механизма перейдем в НСИ и администрирование → Настройка пользователей и прав и в группе Даты запрета изменения установим соответствующий флаг. Перейдем по ссылке Настроить.

Интерфейс БСП предоставляет широкие возможности:

Мы можем использовать относительные (динамические) даты: «Предыдущий день», «Конец прошлого месяца», «Конец прошлой недели». Система сама будет сдвигать границу запрета при наступлении нового календарного дня.
Мы можем настроить запреты в разрезе Адресатов (конкретных пользователей или групп пользователей).
Доступна детализация по Разделам (например, для раздела «Продажи» установить одну дату, для «Закупок» — другую) или по Разделам и объектам (в разрезе Организаций или Складов внутри раздела).

Важное ограничение платформы: Типовой функционал УТ 11.2 не позволяет установить разные даты запрета для разных видов документов внутри одного раздела (например, заблокировать изменение «Реализации товаров и услуг» вчерашним днем, а «Счет на оплату» оставить доступным для редактирования за любой период). Все документы продаж жестко привязаны к единому разделу «Продажи».

Чтобы реализовать требования автора из постановки задачи, нам потребуется программное вмешательство. Рассмотрим, как это сделать правильно, используя штатные механизмы расширения БСП.

Программное разделение дат запрета по типам документов

Для реализации сложной логики проверки дат запрета мы должны использовать переопределяемые общие модули механизма дат запрета изменений. Основную роль здесь играет модуль ДатыЗапретаИзмененияПереопределяемый.

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

Шаг 1. Регистрация источников данных

В процедуре ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения регистрируются метаданные документов, подлежащих проверке. Посмотрим на пример заполнения:


Процедура ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения(Знач ИсточникиДанных) Экспорт
    
    // Шаблон регистрации: ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Таблица", "ПолеДаты", "Раздел", "ПолеОбъекта")
    
    // Регистрируем Реализацию товаров и услуг
    ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Документ.РеализацияТоваровУслуг", "Дата", "Продажи", "Организация");
    
    // Регистрируем Авансовый отчет
    ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Документ.АвансовыйОтчет", "Дата", "АвансовыеОтчеты", "Организация");
    
КонецПроцедуры

Шаг 2. Кастомизация проверки перед записью документов

Наиболее элегантный и надежный способ установить персональные ограничения по датам для документов (без создания десятка новых разделов дат запрета) — использовать процедуру ПередПроверкойЗапретаИзменения в том же общем модуле. Данный метод вызывается системой непосредственно перед тем, как БСП начнет сопоставлять дату документа с регистром сведений ДатыЗапретаИзменения.

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


Процедура ПередПроверкойЗапретаИзменения(ИсточникиДанных, Отказ) Экспорт
    
    Для Каждого СтрокаИсточника Из ИсточникиДанных Цикл
        
        // Получим метаданные объекта для анализа его типа
        ИмяДокумента = СтрокаИсточника.НоваяВерсияОбъекта.Метаданные().Имя;
        ДатаДокумента = СтрокаИсточника.НоваяВерсияОбъекта.Дата;
        
        // Счета на оплату и Заказы клиентов разрешено редактировать без ограничений по дате
        Если ИмяДокумента = "СчетНаОплатуКлиенту" Или ИмяДокумента = "ЗаказКлиента" Тогда
            СтрокаИсточника.Проверить = Ложь; // Отключаем стандартную проверку БСП
            Продолжить;
        КонецЕсли;
        
        // Реализация товаров и услуг, Возвраты, РКО, ПКО - ограничение "Предыдущий день"
        Если ИмяДокумента = "РеализацияТоваровУслуг" 
            Или ИмяДокумента = "ВозвратТоваровОтКлиента" 
            Или ИмяДокумента = "ВозвратТоваровПоставщику"
            Или ИмяДокумента = "РасходныйКассовыйОрдер"
            Или ИмяДокумента = "ПриходныйКассовыйОрдер" Тогда
            
            ГраницаРедактирования = НачалоДня(ТекущаяДата()) - 1; // Вчерашний день
            Если ДатаДокумента < ГраницаРедактирования Тогда
                ВызватьИсключение "Редактирование документа '" + СтрокаИсточника.НоваяВерсияОбъекта + "' запрещено! Разрешено изменять только документы за текущий и предыдущий день.";
            КонецЕсли;
            
            СтрокаИсточника.Проверить = Ложь; // Проверка пройдена успешно вручную
            Продолжить;
        КонецЕсли;
        
        // Заказы поставщикам, Поступления товаров - ограничение "Конец прошлого месяца"
        Если ИмяДокумента = "ЗаказПоставщику" Или ИмяДокумента = "ПриобретениеТоваровУслуг" Тогда
            
            // Рассчитаем дату окончания позапрошлого месяца
            НачалоТекущегоМесяца = НачалоМесяца(ТекущаяДата());
            КонецПрошлогоМесяца = НачалоТекущегоМесяца - 1;
            ГраницаРедактирования = НачалоМесяца(КонецПрошлогоМесяца); // Начало прошлого месяца
            
            Если ДатаДокумента < ГраницаРедактирования Тогда
                ВызватьИсключение "Редактирование документа '" + СтрокаИсточника.НоваяВерсияОбъекта + "' запрещено! Период закрыт для редактирования.";
            КонецЕсли;
            
            СтрокаИсточника.Проверить = Ложь;
            Продолжить;
        КонецЕсли;
        
        // Сборки и разборки товаров - ограничение "Конец прошлой недели"
        Если ИмяДокумента = "СборкаТоваров" Тогда
            
            ТекущийДеньНедели = ДеньНедели(ТекущаяДата());
            НачалоТекущейНедели = НачалоДня(ТекущаяДата()) - (ТекущийДеньНедели - 1) * 86400;
            ГраницаРедактирования = НачалоТекущейНедели; // Начало текущей недели (все что раньше - под запретом)
            
            Если ДатаДокумента < ГраницаРедактирования Тогда
                ВызватьИсключение "Редактирование сборок/разборок за прошлую неделю и ранее запрещено!";
            КонецЕсли;
            
            СтрокаИсточника.Проверить = Ложь;
            Продолжить;
        КонецЕсли;
        
    КонецДляКаждого;
    
КонецПроцедуры

Разберем, как работает этот алгоритм. При попытке записи любого документа система вызывает нашу переопределяемую процедуру. Мы анализируем имя документа в метаданных и, если оно соответствует нашим критериям, рассчитываем динамическую дату ограничения на лету. Если документ оказывается «старше» разрешенной даты, транзакция прерывается вызовом исключения с понятным для пользователя текстом. Если проверка пройдена, мы устанавливаем свойство СтрокаИсточника.Проверить = Ложь, сообщая БСП, что стандартный платформенный механизм проверки дат запрета для данного документа вызывать уже не требуется.

Для документов, которые не вошли в наши условия фильтрации, стандартный механизм БСП продолжит работать в штатном режиме, используя настройки из регистра сведений ДатыЗапретаИзменения.

Резюме

Применяя данный комплексный подход, мы получаем чистое, легко масштабируемое решение:

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

← На главную