В очередной статье, посвящённой практике перехода с 1С:УПП на 1С:ERP, мы рассмотрим перенос пользователей в новую автоматизированную систему с сохранением прежних прав на примере кейса одного из наших заказчиков, крупного производителя кофейной продукции. Автор статьи: Дмитрий Малышев - разработчик 1С с 2004 года на платформах 1С 7.7, 8.1, 8.2, 8.3. Сертификат «1С:Эксперт по технологическим вопросам». Участник 30 проектов полного цикла внедрения 1С:УПП и 1C: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С:УПП и 1С:ERP, нами было разработано расширение: «Аудит ролей», позволившее установить соответствие между пользователями и их правами в 1С:УПП и 1С:ERP, тем самым реализовав требуемую наследуемость прав при переходе, чтобы можно было увидеть права пользователя при работе и в прошлой, и в новой системе. В расширении были созданы нужные сущности: АР:Пользователь, АР:Подразделение, АР:Должностные обязанности, АР:Область данных, АР:Роль, АР:Таблица прав. В них были загружены данные из матрицы прав, полученной из 1С:УПП.  Если смотреть файл аудита и расширение, то был установлен следующий мэпинг: Имя файла => АР:Подразделение (справочник расширения); Колонка «ИмяПользователя» => АР:Пользователь (справочник расширения); Колонки ролей => АР:Роль (справочник расширения); Колонка «Роль 1С» => АР:Область данных (справочник расширения); Колонка «Position» => АР:Должностные обязанности (справочник расширения); Ячейки с правом => АР:Таблица прав (регистр сведений расширения).  Кому интересны обработки, с помощью которых можно получить матрицы прав 1С:УПП,и загрузить в ERP таблицы, спрашивайте в комментариях. Рис 1.1 Как выглядит Расширение «Аудит ролей» в конфигураторе и предприятии По итогу загрузки, например, файла с правами бухгалтерии в 1С:ERP получилась такая картина:  Рис 1.2 Просмотр таблицы пользователей бухгалтерии в 1С:ERP отчётом «Анализ таблицы прав»  Следующим шагом стала установка пользователей и профилей в 1С:ERP в соответствие с данными 1С:УПП. Пользователей переносили с помощью «1С:Конвертация данных 2.0» следующим образом: Создали в расширении «Аудит ролей» у типового справочника «Пользователи» дополнительные реквизиты (они нужны на время, это атрибуты «Пользователя информационной базы», связанного с элементом справочника «Пользователи»).  Рис 2.1 Временные реквизиты Пользователя Выгрузили обработками MD82Exp.epf и MD83Exp.epf из 1С:УПП и 1С:ERP структуры метаданных и загрузил их в базу 1С:Конвертации. В базе 1С:Конвертации создали новую конвертацию из 1С:УПП в 1С:ERP с правилом выгрузки данных (ПВД) «Пользователи» и правилом конвертации объекта (ПКО) для справочника Пользователи.  Рис 2.2 Правила обмена для пользователей  Параметры выгружали следующим образом: получали связанного пользователя информационной базы и его атрибут отправляли в нужный параметр. Затем, после загрузки объекта в приёмник, прописали заполнение ранее добавленных реквизитов из параметров.   После этого сохранили правила в файл. Затем обработкой «Универсальный обмен данными XML» (V8Exchan82.epf - есть в составе 1С:Конвертация) выгрузили пользователей из 1С:УПП и аналогичной обработкой «Универсальный обмен данными XML» (V8Exchan83.epf) загрузили пользователей в 1С:ERP. Пользователи после такой загрузки в базу 1С:ERP являются пока «не живыми», не активными, то есть элемент в справочнике «Пользователи» есть, но нет связанного пользователя информационной базы, позволяющего войти в 1С:ERP. Для активизации пользователей нужно выполнить обработку «АР: Активировать пользователей» из расширения «Аудит ролей». Рис 2.3 Обработка активации пользователей  Подбираем нужных пользователей (множественный выбор или Ctr+A если всех). Активируем пользователей ИБ. Можно сгенерировать пароль (только заранее, т.к. он установится при предыдущем действии активации). Роли — это общие объекты конфигурации, предназначенные для реализации ограничения прав доступа в прикладных решениях. В процессе ведения списка пользователей прикладного решения каждому пользователю ставится в соответствие список ролей, которыми определяется, какие действия, над какими объектами метаданных может выполнять пользователь.  Рис 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 Пример опциональных профилей: «Рассылка отчетов», «Касса», «Номенклатура», «Контрагенты»… Ввод значений по умолчанию из 1С:УПП для пользователей было решено преобразовать через создание расширения для значений по умолчанию и механизмов статистики 1С (заполняющих автоматически основные реквизиты шапки на основе ранее введенных 3 объектов данного типа). В новом расширении предусмотрели задание настроек для всех пользователей и персональные — по заполнению любых реквизитов форм объектов.  Рис 4.1 Настройки пользователя по умолчанию в 1С:УПП Рис 4.2 Подсистема значений по умолчанию Рис 4.3 Основная форма редактирования Рис 4.4 Пример установки реквизитов для заказа Рис 4.5 Выбор для объекта формы, в которой для нового объекта устанавливаются реквизиты  Это расширение, которое позволило онлайн устанавливать фильтры видимости в формах списков документов и справочников, права на открытие их форм и запреты изменения самих объектов. Права можно установить для всех пользователей, конкретных групп пользователей, подразделений или персонально. Настройки на любое сочетание реквизитов объекта «И/ИЛИ» реализованы через механизмы компоновки данных. Рис 5.1 Подсистема гибких прав Рис 5.2 Основное рабочее окно Рис 5.3 Пример окон прав: а) доступ только к определенной группе контрагентов, б) доступ к изменению только своих заявок ДС Обработка предназначена для просмотра / изменения ролей пользователей. Отличие от аналогов - позволяет более гибко назначать роли путём выделения произвольных областей в форме отчёта и нажатием одной кнопки. Позволяет назначать роли и группы и профили в удобном режиме и получать дополнительную аналитическую информацию по всевозможным разрезам. Обладает уникальным функционалом. Позволяет загружать в справочники, табличные части, регистры сведения, движения документа, поточно загружать документы, а также одновременно загружать в справочники, являющиеся реквизитами загружаемых объектов, с полноценной настройкой. Обработка на управляемых формах, работает на всех версиях 1С предприятия 8.2 и 8.3 Возможность без доработок конкретизировать пользователям права Просмотра и Изменения объектов базы 1С, установив ограничения с помощью отборов системы компоновки данных. При заполнении документов и справочников пользователи часто сталкиваются с необходимостью ввода одних и тех же реквизитов. Заполнение в документах некоторых из них, таких как «Организация», «Склад» и т.п., выполняется реализованным в 1С механизмом подстановки значения из последних 3-5 введенных документов. Если же вы хотите заполнять все реквизиты шапки (и даты, и флажки, и другие поля, включая дополнительные реквизиты), то вам поможет данный механизм. Подключаемая обработка. Помогает при конструировании профилей доступа пользователей (настройке прав пользователей), экономит время на добавлении/удалении одной и той же роли сразу в нескольких профилях. Панель, вызываемая для объекта комбинацией клавиш Alt+Z (для документа, справочника, плана вида характеристик, плана счетов и т.д.). Возможности: «Редактор всех реквизитов, таблиц и движений», «Анализ прав к объекту», «Поиск ссылок на объект с фильтрами», «Сторно движений документа», «Выгрузка/загрузка текущего объекта между базами». Подключается как «Расширение». Предназначается для запуска сеанса другого пользователя из своего сеанса 1С (если пароль вам неизвестен). Обработка для массовой проверки доработок конфигурации: «Открытие форм», «Печать», «Формирование отчётов», «Проведение документов», «Запись справочников», «ПВХ», «ПВР». Выдаёт список обнаруженных ошибок. Рекомендуется применять для тестирования обновленной конфигурации, перед установкой пользователям. В коде используются универсальные методы поэтому подходит для большинства конфигураций, построенных на базе библиотеки стандартных подсистем. Настраиваем для пользователей 1С разрешённое количество открытых сеансов к текущей базе данных 1С в привязке к компьютерам, чтобы у пользователя не было возможности превысить допустимое количество сеансов или зайти с чужого компьютера. Если пользователю не хватает прав на объект, то на практике в 90 % случаев, недостающую роль можно найти через типовой регистр сведений Права ролей. Также с помощью дополнительного отчёта или небольшого расширения можно ускорить описанный процесс. Расширение позволяет настроить для пользователей выполнение отчётов в привилегированном режиме, убирает тормоза формирования отчета, возникающие при наложении прав пользователя на запросы отчета, позволяет обойти ошибки формирования отчёта из-за отсутствия прав на часть объектов у пользователя.