Разделение прав на проведение документов разного вида
Здравствуйте!
Появилась задача разделить права на проведение документа в зависимости от вида документа. Пример для понимания: есть объект документ "Приказ". Есть права на этого объект у одного подразделения на создание этого документа, у другого подразделения на изменение и проведение этого документа.
Теперь хотят, чтобы одно из подразделений могло проводить приказы только определенного вида ("ВидПриказа"- -это реквизит документа "Приказ"), а другое подразделение приказы другого вида. Есть такая возможность?
Появилась задача разделить права на проведение документа в зависимости от вида документа. Пример для понимания: есть объект документ "Приказ". Есть права на этого объект у одного подразделения на создание этого документа, у другого подразделения на изменение и проведение этого документа.
Теперь хотят, чтобы одно из подразделений могло проводить приказы только определенного вида ("ВидПриказа"- -это реквизит документа "Приказ"), а другое подразделение приказы другого вида. Есть такая возможность?
По теме из базы знаний
- Обработка выборки документов и выборочное перепроведение по видам движений для 1С-Предприятие-7.7
- Выгрузка-загрузка любых данных (и измененных) между похожими конфигурациями (ФАЙЛ, HTTP, COM) ЛЮБЫХ баз 1С 8.1-8.3 с обработкой и поиском данных по произвольным полям поиска
- Корректировка Поступления не попадает в книгу продаж. Как исправить?
- Особенности разделения объектной модели документа и базы данных в 1С 7.7. Забавный глюк
- Контроль корреспонденций счетов при проведении документов в "1С:Бухгалтерия предприятия 3.0" (расширение)
Найденные решения
Если без RLC, то контролировать подпиской на событие "при проведении", проверять есть ли права у подразделения текущего пользователя.
1. Из соображений наименьшего вмешательства в конфигурацию - я бы тоже посмотрел, в первую очередь, в сторону подписки на событие.
2. Если не брать во внимание соображения из п.1, то подумал бы в сторону статусов, как и советовали. Например, сделал бы статусы:
- Подготовлен
- Передан в управление
- Утвержден управлением - финальный статус
- Утвержден деканатом - финальный статус
Соответственно, документ формирует движения по регистрам только при статусах "Утвержден управлением" и "Утвержден деканатом". А вот доступ к установке этих статусов разграничен по подразделениям. То есть, будет 2 ветки прохождения приказа по маршруту согласования.
2. Если не брать во внимание соображения из п.1, то подумал бы в сторону статусов, как и советовали. Например, сделал бы статусы:
- Подготовлен
- Передан в управление
- Утвержден управлением - финальный статус
- Утвержден деканатом - финальный статус
Соответственно, документ формирует движения по регистрам только при статусах "Утвержден управлением" и "Утвержден деканатом". А вот доступ к установке этих статусов разграничен по подразделениям. То есть, будет 2 ветки прохождения приказа по маршруту согласования.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6)да, так и есть, деканат приказ создает, а управление его проверяет, проводит, но есть приказы, которые деканат сам должен проводить, управление не несет за это ответственности, поэтому и нужно настроить проведение приказов для разных видов приказов
(9) я когда такой вещью заморачивался, делал справочник статусов, там указывал кто может его менять и на какие следующие статусы он может перескочить. В идеале для таких задач есть бизнес процессы, но у нас этот большой документ вырос из документа, который должен был только фиксировать решение - да или нет. Переписывать не охота было. Так вот проверка ролей - при нажатии кнопки. Если у Вас многоступенчатый документ - то может 2 статусами не ограничиться, будет гулять Ваш документ по кругу от подразделения к подразделению и только на последнем проводиться.
Если без RLC, то контролировать подпиской на событие "при проведении", проверять есть ли права у подразделения текущего пользователя.
1. Из соображений наименьшего вмешательства в конфигурацию - я бы тоже посмотрел, в первую очередь, в сторону подписки на событие.
2. Если не брать во внимание соображения из п.1, то подумал бы в сторону статусов, как и советовали. Например, сделал бы статусы:
- Подготовлен
- Передан в управление
- Утвержден управлением - финальный статус
- Утвержден деканатом - финальный статус
Соответственно, документ формирует движения по регистрам только при статусах "Утвержден управлением" и "Утвержден деканатом". А вот доступ к установке этих статусов разграничен по подразделениям. То есть, будет 2 ветки прохождения приказа по маршруту согласования.
2. Если не брать во внимание соображения из п.1, то подумал бы в сторону статусов, как и советовали. Например, сделал бы статусы:
- Подготовлен
- Передан в управление
- Утвержден управлением - финальный статус
- Утвержден деканатом - финальный статус
Соответственно, документ формирует движения по регистрам только при статусах "Утвержден управлением" и "Утвержден деканатом". А вот доступ к установке этих статусов разграничен по подразделениям. То есть, будет 2 ветки прохождения приказа по маршруту согласования.
Так я и написала уже по факту, что вот именно этот документ делает движение в регистр, проводить его обязательно, иначе мне придется снимать с поддержки несколько объектов и "пилить" запросы, зачем усложнять себе задачу и изменять конфигурацию там, где можно это обойти. Мы, наоборот стараемся максимально возможно не менять саму конфигурацию. Кстати, вот Роли у нас свои, их и хотелось править, но не случилось.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот