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