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

Автор статьи: Дмитрий Малышев - разработчик 1С с 2004 года на платформах 1С 7.7, 8.1, 8.2, 8.3. Сертификат «1С:Эксперт по технологическим вопросам». Участник 30 проектов полного цикла внедрения 1С:УПП и 1C:ERP.

Переход с 1С:УПП на 1C:ERP: перенос пользователей вместе с правами в 1С:ERP

Введение

В 2020-2021 году я участвовал в роли руководителя команды разработчиков в проекте «Управление продажами в международной компании на базе 1С:ERP». К слову, проект стал победителем на конкурсе «1С:Проекта года: Лучший проект с использованием технологии «Дистанционное внедрение», проводившемся «Фирмой 1С».

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

Успешный опыт «удалёнки»

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

Сам заказчик работает в режиме 24х7 и является одним из крупнейших предприятий в РФ по производству кофе. На начало проекта в качестве основы корпоративной системы компания была автоматизирована на базе программы 1С:УПП редакции 1.2 (даже не 1.3). По завершению проекта в 2021-м году перешли на ERP 2.5 (Начинали в 2020 м году, когда 2.5. была ещё в бета версии, но были рекомендации фирмы 1С запускать новые проекты на ней, а не на 1С:ERP 2.4. 

Рис 1.1 Схема ИТ-архитектуры проекта

По плану проекта компания переходила от связки 1С:УПП + 1С:ДО + множественных интеграций с внешними решениями на связку 1С:ERP + ЗУП + ДО + с поддержкой тех же интеграций. Основные работы начали в августе 2020 года, а закончили - в апреле 2021-го.

В подобных случаях перехода с УПП на ERP одной из задач является миграция пользователей и настройка их ролей аналогично их правам в старой системе. Эту тему я и раскрою подробнее. Отмечу особенность проекта: при внедрении наша команда должна была учитывать проведение обязательных ежеквартальных аудитов прав пользователей сторонней компанией (эта вынужденная мера была связана с торговлей акциями клиента на фондовом рынке).

Сохранение наследования прав при переходе из 1С:УПП в 1С:ERP

 Если кратко, сторонняя компания-аудитор каждый квартал проверяла доступы в 1С:

  • анализировала список пользователей с полными правами,

  • выборочно контролировала доступы пользователей к запрещенным объектам,

  • контролировала документы, подписанные руководителем ИТ-подразделения и директором по подразделениям со списками пользователей и уровнями доступа.

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

В расширении были созданы нужные сущности: АР:Пользователь, АР:Подразделение, АР:Должностные обязанности, АР:Область данных, АР:Роль, АР:Таблица прав. В них были загружены данные из матрицы прав, полученной из 1С:УПП. 

Если смотреть файл аудита и расширение, то был установлен следующий мэпинг:

  • Имя файла => АР:Подразделение (справочник расширения);

  • Колонка «ИмяПользователя» => АР:Пользователь (справочник расширения);

  • Колонки ролей => АР:Роль (справочник расширения);

  • Колонка «Роль 1С» => АР:Область данных (справочник расширения);

  • Колонка «Position» => АР:Должностные обязанности (справочник расширения);

  • Ячейки с правом => АР:Таблица прав (регистр сведений расширения).

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

Рис 1.1 Как выглядит Расширение «Аудит ролей» в конфигураторе и предприятии

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

Рис 1.2 Просмотр таблицы пользователей бухгалтерии в 1С:ERP отчётом «Анализ таблицы прав»

 Следующим шагом стала установка пользователей и профилей в 1С:ERP в соответствие с данными 1С:УПП.

2. Перенос справочника пользователей из 1С:УПП в 1С:ERP

Пользователей переносили с помощью «1С:Конвертация данных 2.0» следующим образом:

  1. Создали в расширении «Аудит ролей» у типового справочника «Пользователи» дополнительные реквизиты (они нужны на время, это атрибуты «Пользователя информационной базы», связанного с элементом справочника «Пользователи»).

 Рис 2.1 Временные реквизиты Пользователя

  1. Выгрузили обработками MD82Exp.epf и MD83Exp.epf из 1С:УПП и 1С:ERP структуры метаданных и загрузил их в базу 1С:Конвертации.

  2. В базе 1С:Конвертации создали новую конвертацию из 1С:УПП в 1С:ERP с правилом выгрузки данных (ПВД) «Пользователи» и правилом конвертации объекта (ПКО) для справочника Пользователи. 

Рис 2.2 Правила обмена для пользователей

 Параметры выгружали следующим образом: получали связанного пользователя информационной базы и его атрибут отправляли в нужный параметр.

Затем, после загрузки объекта в приёмник, прописали заполнение ранее добавленных реквизитов из параметров.

 

  1. После этого сохранили правила в файл. Затем обработкой «Универсальный обмен данными XML» (V8Exchan82.epf - есть в составе 1С:Конвертация) выгрузили пользователей из 1С:УПП и аналогичной обработкой «Универсальный обмен данными XML» (V8Exchan83.epf) загрузили пользователей в 1С:ERP.

  2. Пользователи после такой загрузки в базу 1С:ERP являются пока «не живыми», не активными, то есть элемент в справочнике «Пользователи» есть, но нет связанного пользователя информационной базы, позволяющего войти в 1С:ERP. Для активизации пользователей нужно выполнить обработку «АР: Активировать пользователей» из расширения «Аудит ролей».

Рис 2.3 Обработка активации пользователей 

  • Подбираем нужных пользователей (множественный выбор или Ctr+A если всех).

  • Активируем пользователей ИБ.

  • Можно сгенерировать пароль (только заранее, т.к. он установится при предыдущем действии активации).

3. Создание профилей доступа в 1С:ERP 

Немного теории…

Роли — это общие объекты конфигурации, предназначенные для реализации ограничения прав доступа в прикладных решениях. В процессе ведения списка пользователей прикладного решения каждому пользователю ставится в соответствие список ролей, которыми определяется, какие действия, над какими объектами метаданных может выполнять пользователь. 

Рис 3.1 Схема настройки прав

Общая схема системы прав доступа подразумевает:

  • Создание ролей для доступа к объектам отдельно для чтения и для записи.

  • Объединение ролей в профили (в том числе поставляемые).

  • Назначение профилей группам доступа с ограничением доступа по видам доступа.

  • Добавление в группы доступа пользователей и групп пользователей.

Такой механизм обладает гибкостью и универсальностью. Это позволяет его достаточно широко применять. Однако непосредственное использование этого механизма громоздко и трудоемко. 

Вернемся к практике…

В 1С:УПП нет деления на профили, поэтому каждый пользователь – это по сути набор ролей. А в нашем случае «уникальный» набор ролей, т.к. компания коммерческая с оптимизированными бизнес-процессами, и каждый сотрудник уникален и на своем месте со своими обязанностями (т.е. у всех разные наборы ролей). В компании насчитывалось 150 уникальных наборов прав в 1С:УПП. По итогу в 1С:ERP их привели к 60 базовым профилям и 30 — опциональным.

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

Рис 3.2 Получившиеся в итоге базовые и опциональные профили

Первым шагом мы разделили пользователей на группы по подразделениям (это было дано в таблицах аудита). В каждом подразделении выделили базовые профили и профиль руководителя (профили позволяющие входить в 1С и работать в базе).

При этом пользователи, имеющие одинаковые базовые профили (бухгалтера, менеджеры закупок и продаж) имели доступ к разным областям данных в рамках своего подразделения: «Редактированию номенклатуры», «Редактированию договоров», «Редактированию контрагентов» и т.п. (эти права решили регулировать «маленькими» опциональными профилями).

Далее сопоставили получившиеся базовые профили с подходящими типовыми предопределенными профилями из 1С:ERP [в составе 1С:ERP уже есть профили их брали за основу для ускорения настройки прав].

 Рис. 3.3 Пример таблицы соответствия: «Базовый профиль» и «Типовой профиль» 1С ERP.

Подобранные типовые профили (см. правую колонку) мы копировали и переименовывали (как в левой колонке). Они должны были стать базовыми, позволяющими заходить в программу и в ней работать.

Дальше, в ходе развития прав, получившиеся профили можно изменять, вычищая от запрещённых объектов, и добавлять права на используемые пользователем объекты.

Базовый профиль – в основном соответствует должностным обязанностям и называется примерно [Подразделение:Должность]. Он назначается всем пользователям в этом подразделении с этой должностью.

Но, например, бухгалтера с одной должностью видят разные области данных:

  • кто-то на ОС,

  • кто-то на кассе,

  • кто-то договора меняет,

  • и т.п.

В результате права на ОС, на кассу, на договоры разделялись как профили опций и содержали в составе небольшой набор ролей.

По итогу набор прав каждого поименованного пользователя из бухгалтерии складывался как: базовой профиль + профили опций.

Например:

  • «Иванова» имела права: [Бухгалтерия: Базовый бухгалтер] + [Бухгалтерия: ОС];

  • «Петрова» имела права: [Бухгалтерия: Базовый бухгалтер] + [Бухгалтерия: Касса] + [Договора]. 

Рис 3.4 Пример прав пользователя, скомбинированный из базового профиля и опциональных

Профили опций (они же опциональные профили) - не дают доступа в систему, а содержат только доступы к видам объектов 1С, принадлежащих указанной области данных, или доступ к определенному функционалу системы (например, к ЭДО, обменам, загрузкам/выгрузкам и т. п.).

Также были сформированы общие для всех профили опций такие как: [Номенклатура], [Контрагенты], [Договоры], [ЭДО] и т.п., которые могли назначаться в разных подразделениях и обеспечивали доступ к указанным объектам.

На время старта был создан 1 профиль [Все права без зарплаты], под которым все работали. Он был без полных прав, содержал доступ ко всем объектам, но без зарплаты. Его назначали и всем пользователям, пока их персональные профили находились в процессе настройки. Далее постепенно пользователей отключали от общего мегапрофиля [Все права без зарплаты] и переводили на свои базовые и опциональные профили.

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

Известно, что наличие таких МегаПрофилей в базе у пользователей, к которым он прикреплён, периодически в целом по базе провоцирует серьезные «тормоза». Чтобы снять нагрузку на базу у тех, у кого пока этот МегаПрофиль был включен, подключали привилегированный режим отчётов (кроме отчётов по зарплате, конечно). Также у многих пользователей профили были частично настроены, в результате при выполнении отчёта не было прав на какой то тип объекта, находящийся в составе составного типа какого-то реквизита (очень много ситуаций помноженное на число пользователей) при этом RLS не было, а реальная работа в базе уже велась.

Остановить и просить подождать в этой ситуации не было подходящим вариантом. Быстро, через привилегированный режим, этим расширением купировали проблему без ущерба для безопасности данных. Потом устраняли проблемы в настройках профилей.

С введением большого общего МегаПрофиля и параллельной настройкой прав обязательно возникают проблемы на запуске. Для ускорения проекта вводили привилегированный режим операций Привилегированные отчеты. Он позволяет настроить для пользователей выполнение отчётов в привилегированном режиме, при этом 1) убирает «тормоза» формирования отчёта, возникающие при наложении прав пользователя на запросы отчёта; 2) позволяет обойти ошибки формирования отчёта из-за отсутствия прав на часть объектов у пользователя. 

Рис 3.5 Пример разработанных прав пользователей по подразделениям «Бухгалтериия» и «Производство»

 Рис 3.5 Пример базового профиля Бухгалтера 

 Рис 3.6 Пример опциональных профилей: «Рассылка отчетов», «Касса», «Номенклатура», «Контрагенты»…

4. Автоматизация заполнения объектов

Ввод значений по умолчанию из 1С:УПП для пользователей было решено преобразовать через создание расширения для значений по умолчанию и механизмов статистики 1С (заполняющих автоматически основные реквизиты шапки на основе ранее введенных 3 объектов данного типа). В новом расширении предусмотрели задание настроек для всех пользователей и персональные — по заполнению любых реквизитов форм объектов.

 Рис 4.1 Настройки пользователя по умолчанию в 1С:УПП

Рис 4.2 Подсистема значений по умолчанию

Рис 4.3 Основная форма редактирования

Рис 4.4 Пример установки реквизитов для заказа

Рис 4.5 Выбор для объекта формы, в которой для нового объекта устанавливаются реквизиты 

5. Гибкие права доступа к объектам

Это расширение, которое позволило онлайн устанавливать фильтры видимости в формах списков документов и справочников, права на открытие их форм и запреты изменения самих объектов. Права можно установить для всех пользователей, конкретных групп пользователей, подразделений или персонально. Настройки на любое сочетание реквизитов объекта «И/ИЛИ» реализованы через механизмы компоновки данных.

Рис 5.1 Подсистема гибких прав

Рис 5.2 Основное рабочее окно

Рис 5.3 Пример окон прав: а) доступ только к определенной группе контрагентов, б) доступ к изменению только своих заявок ДС

Функционал использованных готовых обработок (интересующиеся списком использованных решений-ресурсов пишите запросы в комментариях)

  1. Обработка предназначена для просмотра / изменения ролей пользователей. Отличие от аналогов - позволяет более гибко назначать роли путём выделения произвольных областей в форме отчёта и нажатием одной кнопки.

  2. Позволяет назначать роли и группы и профили в удобном режиме и получать дополнительную аналитическую информацию по всевозможным разрезам.

  3. Обладает уникальным функционалом. Позволяет загружать в справочники, табличные части, регистры сведения, движения документа, поточно загружать документы, а также одновременно загружать в справочники, являющиеся реквизитами загружаемых объектов, с полноценной настройкой. Обработка на управляемых формах, работает на всех версиях 1С предприятия 8.2 и 8.3

  4. Возможность без доработок конкретизировать пользователям права Просмотра и Изменения объектов базы 1С, установив ограничения с помощью отборов системы компоновки данных.

  5. При заполнении документов и справочников пользователи часто сталкиваются с необходимостью ввода одних и тех же реквизитов. Заполнение в документах некоторых из них, таких как «Организация», «Склад» и т.п., выполняется реализованным в 1С механизмом подстановки значения из последних 3-5 введенных документов. Если же вы хотите заполнять все реквизиты шапки (и даты, и флажки, и другие поля, включая дополнительные реквизиты), то вам поможет данный механизм.

  6. Подключаемая обработка. Помогает при конструировании профилей доступа пользователей (настройке прав пользователей), экономит время на добавлении/удалении одной и той же роли сразу в нескольких профилях.

  7. Панель, вызываемая для объекта комбинацией клавиш Alt+Z (для документа, справочника, плана вида характеристик, плана счетов и т.д.). Возможности: «Редактор всех реквизитов, таблиц и движений», «Анализ прав к объекту», «Поиск ссылок на объект с фильтрами», «Сторно движений документа», «Выгрузка/загрузка текущего объекта между базами». Подключается как «Расширение».

  8. Предназначается для запуска сеанса другого пользователя из своего сеанса 1С (если пароль вам неизвестен).

  9. Обработка для массовой проверки доработок конфигурации: «Открытие форм», «Печать», «Формирование отчётов», «Проведение документов», «Запись справочников», «ПВХ», «ПВР». Выдаёт список обнаруженных ошибок. Рекомендуется применять для тестирования обновленной конфигурации, перед установкой пользователям. В коде используются универсальные методы поэтому подходит для большинства конфигураций, построенных на базе библиотеки стандартных подсистем.

  10. Настраиваем для пользователей 1С разрешённое количество открытых сеансов к текущей базе данных 1С в привязке к компьютерам, чтобы у пользователя не было возможности превысить допустимое количество сеансов или зайти с чужого компьютера.

  11. Если пользователю не хватает прав на объект, то на практике в 90 % случаев, недостающую роль можно найти через типовой регистр сведений Права ролей. Также с помощью дополнительного отчёта или небольшого расширения можно ускорить описанный процесс.

  12. Расширение позволяет настроить для пользователей выполнение отчётов в привилегированном режиме, убирает тормоза формирования отчета, возникающие при наложении прав пользователя на запросы отчета, позволяет обойти ошибки формирования отчёта из-за отсутствия прав на часть объектов у пользователя.

Комментарии (2)


  1. VVizard
    17.05.2022 11:33

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

    Есть вопрос по разделам:

    "4. Автоматизация заполнения объектов"

    "5. Гибкие права доступа к объектам"

    Как они относятся к теме статьи? Не все получилось сделать ролями и часть делали с помощью "5. Гибкие права доступа к объектам" ? В УПП был аналогичный функционал?

    Плюс не понятно как при маппинге пользователей УПП на типовые профили решалась проблема с тем что в типовом профиле есть лишние права.

    Т.е. понятна ситуация когда есть типовой профиль и к нему нужно добавить дополнительные права, делаем опциональный профиль и таким образом получаем требуемую функциональность. Но если в типовом профиле есть лишние права то такой вариант не сработает.

    Неужели у вас не было таких вариантов?


    1. ERP Автор
      17.05.2022 14:32

      По поводу ссылок на расширения: всё можно найти здесь, и вопросы сюда же перезадайте, если ещё актуально: https://infostart.ru/1c/articles/1627919/