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