При настройке прав доступа пользователей в среде 1С:Предприятие разработчики часто сталкиваются с неочевидным поведением платформы. Типичный сценарий: создается новая роль (например, через расширение конфигурации), в которой пользователю предоставляются права на чтение и изменение регистра бухгалтерии, плана счетов и самого документа ОперацияБух (или ручной операции). Однако при попытке отредактировать проводку интерактивно пользователь обнаруживает, что поля «Счет Дт» и «Счет Кт» заблокированы (отображаются серыми и недоступны для выбора), хотя сумма, период и организация открыты для редактирования.
В этой статье мы подробно разберем, почему возникает эта проблема, рассмотрим внутренние платформенные механизмы работы счетов и субконто, а также предоставим пошаговые инструкции по устранению этой неполадки.
---
Это самая распространенная и неочевидная причина блокировки полей выбора счета. Давайте разберем по шагам, как устроена связь счетов и субконто на уровне платформы 1С:
СубконтоДт и СубконтоКт имеют составной тип данных. Этот тип динамически определяется набором характеристик из плана видов характеристик (ПВХ) ВидыСубконтоХозрасчетные.Почему платформа так делает? При изменении счета дебета или кредита в проводке система должна динамически перестроить доступные поля субконто на форме. Если у пользователя нет прав на тип данных нового субконто, система не сможет корректно отобразить или валидировать это поле. Чтобы предотвратить возникновение логических ошибок и нарушение прав доступа, платформа полностью запрещает редактирование полей СчетДт и СчетКт в строке записи регистра.
Как решить эту проблему:
Предоставлять права вручную на каждый справочник, который может выступать в роли субконто, крайне трудоемко. В типовых конфигурациях (БП 3.0, ERP, КА) разработчики фирмы «1С» предусмотрели специальные роли для решения этой задачи. Нам необходимо включить пользователю одну из следующих стандартных ролей:
Назначение этих ролей позволяет обойти платформенное ограничение составного типа без необходимости наделения пользователя административными правами.
---
Иногда разработчики, настраивая роль в конфигураторе или расширении, забывают о разграничении прав на уровне отдельных реквизитов объекта. Недостаточно просто установить галочку «Изменение» на сам объект метаданных РегистрБухгалтерии.Хозрасчетный.
Проанализируем структуру прав роли:
СчетДт, СчетКт, а также СубконтоДт и СубконтоКт установлены флаги «Просмотр» и «Редактирование».Если право «Редактирование» для этих полей снято, то даже при наличии полных прав на запись самого регистра поля выбора счетов на форме останутся недоступными.
---
В современных конфигурациях на базе Библиотеки Стандартных Подсистем (БСП) управление доступностью элементов формы часто выполняется программно на сервере. При создании формы документа ОперацияБух система анализирует роли текущего пользователя и динамически управляет свойствами элементов.
Даже если на уровне метаданных СУБД права настроены идеально, программный код может принудительно установить:
Элементы.ПроводкиСчетДт.Доступность = Ложь;
Элементы.ПроводкиСчетКт.Доступность = Ложь;
Обычно в модуле формы документа или в специализированных общих модулях (например, УправлениеДоступомУП или УправлениеДоступомБП) присутствует проверка на наличие специализированных ролей. Для возможности редактирования проводок у пользователя должна быть назначена одна из следующих ролей:
Проанализируем код формы документа в процедуре ПриСозданииНаСервере, чтобы убедиться, что доступность колонок не отключается принудительно из-за отсутствия этих ролей в профиле пользователя.
---
Если права дорабатываются через расширение, могут возникать платформенные коллизии заимствования объектов. При заимствовании регистра бухгалтерии в расширение стандартные реквизиты и связи с планами счетов могут наследоваться некорректно.
Выясним, как правильно перенести права в расширение:
Хозрасчетный), а также ПВХ ВидыСубконтоХозрасчетные.---
Для того чтобы быстро и точно определить, какой именно объект блокирует доступ к изменению счетов, выполним следующие диагностические шаги:
Шаг 1. Анализ Журнала регистрации на предмет отказов в доступе
Запустим сеанс под проблемным пользователем и попытаемся дважды кликнуть по заблокированному полю «Счет Дт». Сразу после этого зайдем в систему под учетной записью администратора и откроем Журнал регистрации. Установим фильтр по колонке «Статус карты доступа» или по событию Доступ.Отказ в доступе. Платформа зафиксирует обращение к метаданным и укажет конкретный объект (например, справочник Склады или ДоговорыКонтрагентов), на чтение которого пользователю не хватило прав.
Шаг 2. Проверка ограничений RLS (Row Level Security)
Если в системе включено ограничение доступа на уровне записей (по организациям, контрагентам и т.д.), убедимся, что у пользователя есть доступ к тем элементам, которые уже выбраны в проводках существующего документа. Если в проводке выбран объект аналитики, к которому у пользователя нет доступа по RLS, вся строка (включая счет) может заблокироваться для редактирования.
Шаг 3. Очистка кэша конфигурации
Иногда после изменения ролей в расширении платформа продолжает использовать старую карту прав доступа из локального кэша. Обязательно выполним очистку кэша метаданных на рабочем компьютере пользователя (запуск с ключом /ClearCache или удаление базы из списка и повторное добавление).