Почему пользователь не может записать документ «Заявка на расходование денежных средств» со списком подотчетных лиц?

← На главную

Мы сталкиваемся с распространенной проблемой в 1С:ERP 2.5, когда пользователь с ограниченными правами не может записать документ «Заявка на расходование денежных средств». Эта ситуация возникает при выборе типа операции «Выдача подотчетнику» и установке флажка «Список подотчетных лиц». Интересно, что при выборе одного подотчетного лица документ записывается и проводится без каких-либо затруднений. Возникает вопрос, почему система ведет себя таким образом и каких именно прав или настроек доступа не хватает пользователю при работе со списком.

1. Первичная диагностика: Анализ журнала регистрации (ЖР)

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

Общий характер ошибки: Часто в Журнале регистрации мы можем увидеть общие сообщения об ошибке, как в нашем случае:


Ошибка при вызове метода контекста (Записать) {ОбщийМодуль.ОбщегоНазначенияУТКлиент.Модуль(1367)}:Результат = Форма.Записать(ПараметрыЗаписи); {ОбщийМодуль.ОбщегоНазначенияУТКлиент.Модуль(1255)}:ЗаписатьОбъект(Форма, ПараметрыЗаписи); {Документ.ЗаявкаНаРасходованиеДенежныхСредств.Форма.ФормаДокумента.Форма(2615)}:ОбщегоНазначенияУТКлиент.Записать(ЭтаФорма, Истина); по причине: У пользователя недостаточно прав на исполнение операции над базой данных.

Это сообщение, хотя и указывает на нехватку прав, не дает нам точного понимания, к какой именно таблице или объекту был ограничен доступ. Такие ошибки относятся к «Ошибка выполнения кода» и не всегда содержат нужные детали.

Поиск детализированной информации: Для выявления конкретной причины отказа в доступе нам нужно искать события с типом «Информация» и событием «Доступ.Отказ в доступе». Именно в этих записях Журнала регистрации система указывает, к какой таблице и над каким действием (чтение, запись, изменение) произошел отказ. Мы должны внимательно просмотреть записи, идущие непосредственно до или после сообщения об общей ошибке. Этот подход помогает точно определить объект метаданных, на который у пользователя не хватает прав.

2. Выявление проблемы в ограничениях доступа на уровне записей (RLS)

После анализа Журнала регистрации, если мы видим отказ в доступе к определенным данным, следующим шагом является анализ настроек RLS (Restriction Level Security) для документа «Заявка на расходование денежных средств». В нашем случае, проблема явно связана с особенностями работы RLS при использовании списка подотчетных лиц.

Особенности RLS при работе с табличными частями: Мы выяснили, что в стандартном варианте RLS для документа «Заявка на расходование денежных средств» используется условие, проверяющее поле Т.ПодотчетноеЛицо из шапки документа. Давайте посмотрим на фрагмент этого RLS-запроса, как он был приведен в обсуждении:


#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда #ДляОбъекта("") #Иначе #ПоЗначениямРасширенный( "Документ.ЗаявкаНаРасходованиеДенежныхСредств","Чтение","", "ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗаявкаНаРасходованиеДенежныхСредств.РасшифровкаПлатежа КАК Т1 ПО Т.Ссылка = Т1.Ссылка", "", "Организации","Т.Организация","И", "Подразделения","Т.Подразделение","И", "Пользователи","Т.КтоЗаявил","И", "ХозяйственныеОперации","ВЫБОР КОГДА Т.ХозяйственнаяОперация = Значение(Перечисление.ХозяйственныеОперации.ВыплатаЗарплаты) ТОГДА Т.ХозяйственнаяОперацияПозарплате ИНАЧЕ Т.ХозяйственнаяОперация КОНЕЦ", "И ВЫБОР КОГДА Т.ХозяйственнаяОперация = Значение(Перечисление.ХозяйственныеОперации.ОплатаПоставщику) ИЛИ Т.ХозяйственнаяОперация = Значение(Перечисление.ХозяйственныеОперации.ВозвратОплатыКлиенту) ТОГДА Т1.Партнер ЕСТЬ NULL ИЛИ", "ГруппыПартнеров","Т1.Партнер", "КОГДА Т.ХозяйственнаяОперация = Значение(Перечисление.ХозяйственныеОперации.ВыдачаДенежныхСредствПодотчетнику) ТОГДА", "ГруппыФизическихЛиц","Т.ПодотчетноеЛицо", "ИНАЧЕ ИСТИНА КОНЕЦ", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","","","","") #КонецЕсли

Обратите внимание на часть, касающуюся «ВыдачаДенежныхСредствПодотчетнику»:


"КОГДА Т.ХозяйственнаяОперация = Значение(Перечисление.ХозяйственныеОперации.ВыдачаДенежныхСредствПодотчетнику) ТОГДА",
"ГруппыФизическихЛиц","Т.ПодотчетноеЛицо",

Когда мы выбираем «Список подотчетных лиц», поле Т.ПодотчетноеЛицо в шапке документа, скорее всего, становится пустым (NULL), поскольку все лица указываются в отдельной табличной части (например, «Лицевые счета сотрудников» или «РасшифровкаПлатежа»). Стандартное условие RLS, которое пытается применить ограничение по Т.ПодотчетноеЛицо, не может корректно сработать, так как это поле пустое. Это приводит к тому, что система не может определить права на подотчетное лицо и, как следствие, отказывает в записи документа, даже если у пользователя есть права на всех физических лиц в списке.

Проверка прав на справочник «Физические лица» и группы доступа: Мы также должны убедиться, что у пользователя есть права на чтение справочника «Физические лица». Если в RLS настроены ограничения на группы физических лиц, то необходимо проверить, что все сотрудники, которых мы включаем в список, входят в те группы, на которые у пользователя есть доступ. Если хотя бы одно физическое лицо из списка недоступно, это также может стать причиной отказа.

3. Предложенное решение: Модификация RLS-запроса

Для решения этой проблемы, когда RLS некорректно срабатывает из-за пустого поля Т.ПодотчетноеЛицо при использовании списка, было предложено модифицировать запрос RLS. Цель модификации — отключить проверку по этому полю, когда активирована опция «Список подотчетных лиц».

Мы предлагаем добавить дополнительное условие НЕ СписокФизЛиц (где СписокФизЛиц — это реквизит документа, который становится Истина, когда установлен флажок «Список подотчетных лиц») в секцию RLS, отвечающую за хозяйственную операцию «Выдача денежных средств подотчетнику».

Пример модификации RLS-запроса:
Изменим фрагмент RLS-запроса таким образом:
```
"КОГДА Т.ХозяйственнаяОперация = Значение(Перечисление.ХозяйственныеОперации.ВыдачаДенежныхСредствПодотчетнику) и НЕ СписокФизЛиц ТОГДА",
"ГруппыФизическихЛиц","Т.ПодотчетноеЛицо",
```
Таким образом, когда хозяйственная операция — это выдача денежных средств подотчетнику И флажок «СписокФизЛиц» НЕ установлен (то есть выбрано одно подотчетное лицо), тогда и только тогда применяется ограничение по ГруппыФизическихЛиц для Т.ПодотчетноеЛицо. Если же флажок «СписокФизЛиц» установлен, то это условие не будет выполняться, и RLS не будет пытаться проверять пустое поле Т.ПодотчетноеЛицо. Это позволяет документу записываться.
Создание новой роли: Для применения этой модификации, чтобы не изменять типовые роли напрямую, мы рекомендуем создать новую роль. В этой новой роли мы скопируем все необходимые права из типовой роли, которая используется для работы с заявками, и внесем указанное изменение в RLS-запрос. Затем эту новую роль мы добавим в профиль доступа пользователя.
Возможные сложности и альтернативы: Следует отметить, что данное решение позволяет записать документ, но не накладывает RLS на каждое отдельное физическое лицо в табличной части. Для более строгого контроля доступа на уровне записей к каждому физическому лицу в списке потребовалось бы значительно более сложное изменение RLS-запроса с использованием подзапросов к табличной части документа. Однако в большинстве случаев предложенное решение является достаточным для устранения ошибки записи. Важно всегда проводить тщательное тестирование после любых изменений в RLS.

4. Проверка прав на связанные объекты и "Независимые права подчиненных объектов"

Помимо настроек RLS для основного объекта, мы должны убедиться, что у пользователя есть все необходимые права на связанные объекты и табличные части.

Доступ к табличной части: При работе со списком подотчетных лиц данные о них хранятся в табличной части документа. В нашем случае это может быть «РасшифровкаПлатежа», или система может внутренне использовать данные, похожие на «Лицевые счета сотрудников». Убедимся, что у роли пользователя есть явные права на:
- Чтение, добавление и изменение записей в табличной части Документ.ЗаявкаНаРасходованиеДенежныхСредств.РасшифровкаПлатежа.
- Чтение и, при необходимости, изменение справочника ФизическиеЛица, элементы которого добавляются в табличную часть.
- Если используются какие-либо регистры сведений, связанные с лицевыми счетами сотрудников, то на них также должны быть предоставлены права.
Настройка «Независимые права подчиненных объектов»: Мы также проверим настройки роли, в частности, флажок «Независимые права подчиненных объектов». Если эта опция установлена, то права на табличные части и реквизиты могут определяться отдельно от прав на сам документ. В этом случае, если у пользователя есть права на документ в целом, но нет явных прав на конкретную табличную часть или ее поля, это может вызвать ошибку. Убедимся, что все необходимые права на табличные части явно указаны в профиле доступа.

5. Общие рекомендации и тестирование

После внесения любых изменений в систему доступа, особенно связанных с RLS, мы настоятельно рекомендуем выполнить следующие шаги:

Тщательное тестирование: Проведем полное функциональное тестирование с участием пользователя, у которого возникала проблема. Убедимся, что он может не только записывать документы со списком подотчетных лиц, но и выполнять все другие необходимые операции.
Обзор стандартных ролей: В 1С:ERP 2.5 существуют типовые роли, такие как «Ответственный за казначейство», «Бухгалтер», «Финансист». Мы должны проанализировать, какие из этих ролей (или их комбинации) наилучшим образом подходят для нужд пользователя и обеспечивают необходимый уровень доступа.
Документирование изменений: Обязательно задокументируем все внесенные изменения в RLS и настройки ролей. Это поможет в будущем при обновлениях конфигурации или при диагностике новых проблем.
Оценка безопасности: Любые изменения в RLS должны быть тщательно проанализированы с точки зрения безопасности. Убедимся, что внесенные изменения не открывают несанкционированный доступ к данным.

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