Сотрудники

Источники требований

1.4 Управление сотрудниками

BR 1.4.3 — permissions-роли

BR 1.4.4 — удалён enum employees.role. Больше нет dropdown «Менеджер/Кассир». Scope сотрудника определяется не ролью, а владением ЮЛ + набором магазинов в permissions-ролях.

Разблокирует ADR-004

Таблица сотрудников с email и паролем — основа для авторизации (BR 1.3).

Владелец франшизы и владелец партнёра управляют сотрудниками: создание, редактирование, деактивация. Набор permissions-ролей сотрудника определяет, что он может делать; scope (см. Ролевая модель) — на какие данные смотрит.

Сущность сотрудника

(Обновлено в BR 1.4.4 — поле role enum удалено)

Поле	Обязательность	Описание
Имя	Обязательно
Фамилия	Обязательно
Email	Обязательно	Для входа в админку. Уникален в рамках франшизы.
Пароль	Обязательно	Для входа в админку. Хранится в защищённом виде (bcrypt).
Телефон	Необязательно	Контактный номер
PIN-код	Необязательно	4 цифры, для входа на POS. Хранится bcrypt. Уникален в рамках ТТ.
Роли	Ноль или больше	Массив объектов-ролей из Роли. Каждая роль задаёт что пользователь может делать. Каждая роль привязана к своему набору ТТ
Статус	Обязательно	Активен / Деактивирован
Флаг “Курьер”	Необязательно	Может ли доставлять заказы

Нет поля role и нет поля legal_entity_id

Enum-роль удалена BR 1.4.4

ЮЛ-привязка владельца партнёра — через legal_entities.owner_user_id (на стороне ЮЛ, не сотрудника). Обычные сотрудники к ЮЛ не привязаны напрямую — только через ТТ (store → legal_entity_id).

Роли сотрудника

(Переработано в BR 1.4.4 — единый слой, без enum)

Определяет что пользователь может делать. Подробно описано в Роли.

Ключевые свойства:

Сотруднику можно назначить несколько ролей одновременно
Для каждой роли сотрудника отдельно указывается набор магазинов, где эта роль действует
Системная роль «Администратор» даёт все permissions и автосоздаётся при bootstrap франшизы
У каждой роли может быть формула зарплаты (см. Зарплата)

Пример назначения:

Иван Петров
 ├── Роль «Менеджер зала»  → магазины: ТТ-1, ТТ-2
 ├── Роль «Курьер»         → магазины: ТТ-3
 └── Роль «Бариста»        → магазины: ТТ-2

Итоговые права сотрудника = объединение permissions всех его ролей. Scope сотрудника (какие данные видит) — определяется по правилам из Ролевая модель:

Если user = legal_entities.owner_user_id и ЮЛ type=franchise → вся франшиза
Если user = legal_entities.owner_user_id и ЮЛ type=franchisee → свои ЮЛ и их ТТ
Иначе → объединение store_ids из всех его permissions-ролей

Ролевая матрица (кто управляет сотрудниками)

(Переработано в BR 1.4.4)

Действие	Владелец франшизы	Владелец партнёра	Обычный сотрудник
Просмотр списка сотрудников	Все сотрудники франшизы	Только своих сотрудников (по своим ТТ/ЮЛ)	Если есть `employees.read` — в рамках своих ТТ
Создание сотрудника	Любого (в любой ТТ франшизы)	Только в своих ТТ	Если есть `employees.edit` — в рамках своих ТТ (обычно не выдаётся)
Редактирование сотрудника	Любого	Только своих	Если есть `employees.edit`
Деактивация сотрудника	Любого	Только своих	Если есть `employees.edit`
Назначение курьеров	Любых	Только своих	—
Создание владельца партнёра (`admin_franchisee`-аналог)	Только неявно через создание ЮЛ партнёра (см. Юридические лица)	Нет	Нет

Системные сотрудники не создаются через форму

Владелец франшизы создаётся вручную при bootstrap (SQL) — см. Франшизы

Владелец партнёра создаётся только в одной транзакции с ЮЛ партнёра — см. Юридические лица

Создание сотрудника

(Переработано в BR 1.4.4 — единый блок «Роли», без dropdown «Менеджер/Кассир», без отдельного поля ТТ)

Обязательные поля

Имя, фамилия, email, пароль

Необязательные поля

Телефон, PIN-код, флаг «Курьер», роли

Блок «Роли»

Единый блок:

Multi-select из активных обычных (не скрытых) ролей франшизы
Для каждой выбранной роли — свой независимый набор ТТ
Магазины ограничены scope’ом текущего пользователя:
- Владелец франшизы видит все ТТ
- Владелец партнёра видит только свои ТТ
- Обычный сотрудник обычно не создаёт других (нет employees.edit)

Нет отдельного поля «Торговая точка»

(Удалено в BR 1.4.4) — раньше dropdown multi-tenancy роли требовал указать одну ТТ. Теперь набор ТТ определяется через ТТ в каждой назначенной роли. Если сотрудник должен работать на одной ТТ — назначают ему одну роль с одной ТТ.

Ограничения

Email — уникален в рамках франшизы
PIN-код — 4 цифры, уникален в рамках ТТ
Роли — только из списка активных обычных ролей; скрытые роли владельцев партнёров недоступны в селекте

Редактирование сотрудника

(Переработано в BR 1.4.4)

Можно менять: ФИО, телефон, email, пароль, PIN-код, флаг «Курьер», набор permissions-ролей и их per-role магазины.

Нельзя менять через форму «Сотрудники»:

Признак владельца партнёра (это определяется owner_user_id на стороне ЮЛ — управляется через карточку ЮЛ)
Скрытую роль владельца партнёра (управляется через карточку ЮЛ партнёра → вкладка «Права»)

Деактивация и реактивация

Деактивация

Сотрудник переводится в статус “Деактивирован”
Не может войти ни в админку, ни на POS
Все его активные сессии завершаются
В списке отображается с пометкой “Деактивирован” (серый)

Реактивация

Можно вернуть в статус “Активен”
Сотрудник снова может входить в систему

Список сотрудников

(Обновлено в BR 1.4.4 — убрана колонка «Multi-tenancy роль», убран соответствующий фильтр)

Колонки

ФИО
Email
Телефон
Роли (перечисление permissions-ролей; скрытая роль владельца партнёра отображается как «Собственные права» без техназвания)
Торговые точки (агрегат уникальных ТТ по всем ролям сотрудника)
Статус (Активен / Деактивирован)
Курьер (да/нет)

Фильтры

По роли
По ТТ
По статусу
(Опционально, UX) Типа «Только владельцы партнёров» — фильтр по признаку owner_user_id на стороне ЮЛ

Поиск

По ФИО, email, телефону

Действия на панели

Добавить сотрудника
Выгрузить из PK — pull-импорт существующих кассиров из ЛК PayKeeper с wizard’ом дозаполнения. Видна при наличии active PK-аккаунта в scope пользователя. Подробнее: Импорт сотрудников из PayKeeper (добавлено в BR 3.5).

Безопасность

Пароль хранится как bcrypt-хэш
PIN-код хранится как bcrypt-хэш
При деактивации — все сессии мгновенно завершаются
POS PIN-логин разрешён только если у сотрудника в permissions есть pos.access (см. Ролевая модель)

Расширение профиля (BR 1.4.1)

Источник

BR 1.4.1

Вкладки карточки сотрудника

Карточка сотрудника организована по вкладкам:

Вкладка	Что содержит	Кто видит
Общая информация	ФИО, email, телефон, PIN, статус, курьер	Владелец франшизы, владелец партнёра (в своём scope), сотрудники с `employees.read`
Роли и магазины	Список permissions-ролей, каждая со своим набором ТТ + индивидуальная формула зарплаты (Переработано в BR 1.4.4 — без отдельного поля multi-tenancy ТТ)	Владелец франшизы, владелец партнёра
Юридические детали	ИНН, паспорт, ВУ, СНИЛС	Владелец франшизы, владелец партнёра
Рабочее время	Отработанные часы за период (план/факт), история смен	Владелец франшизы, владелец партнёра, сотрудник с `schedule.read` / `timesheet.read` в рамках своих ТТ
История заказов	Заказы, оформленные сотрудником	Владелец франшизы, владелец партнёра

История заказов

Вкладка “История заказов” появится после реализации Order Service (BR 2.1). Пока — заглушка.

Юридические детали (новая сущность)

Связь 1:1 с сотрудником. Все поля необязательные. Доступ только у владельцев франшизы и партнёров (в рамках scope). Обычные сотрудники не видят.

Поле	Тип	Описание
ИНН	string	12 цифр для физлица
Серия паспорта	string
Номер паспорта	string
Номер водительского удостоверения	string
Срок действия ВУ	date
СНИЛС	string

Персональные данные

Юридические детали — чувствительные данные. Хранение и доступ должны соответствовать требованиям ФЗ-152.

Разовая миграция при выкатке

BR 1.4.3 (ввод permissions-модели)

(Введено в BR 1.4.3)

При релизе permissions-модели на тестовую среду:

Создаётся системная роль «Администратор»

admin@erp.local привязывается к этой роли

Удаляются все остальные сотрудники (бывшие admin_franchisee, manager, cashier)

Для удаляемых владельцев партнёров — legal_entities.owner_user_id → NULL (ЮЛ и ТТ не удаляются)

BR 1.4.4 (удаление enum)

(Введено в BR 1.4.4)

Дополнительно к миграции BR 1.4.3:

ALTER TABLE employees DROP COLUMN role — enum-колонка удаляется

Все сервисы пересобираются синхронно (авторизационные switch(role) заменены на scope-check + permission-check)

JWT старых клиентов с полем role — игнорируется (backward compat)

Production-миграции не предусмотрено — платформа ещё не в проде.

Связи с другими модулями

Авторизация (BR 1.3) — email и пароль для входа в админку
POS-авторизация — PIN-код + permission pos.access (см. Ролевая модель)
Юридические лица — владельцы партнёров создаются в транзакции с ЮЛ партнёра (см. Юридические лица)
Торговые точки — привязка к ТТ через permissions-роли
Роли — см. Роли
Расписание смен (BR 1.4.1) — планирование графиков работы
Учёт рабочего времени (BR 1.4.1) — фиксация факта
Дашборд активности (BR 1.4.1) — сводка по работе
Зарплата (BR 1.4.1) — формулы и ведомости

ERP Platform Docs

Проводник

Сотрудники

Сотрудники

Сущность сотрудника

Роли сотрудника

Ролевая матрица (кто управляет сотрудниками)

Создание сотрудника

Обязательные поля

Необязательные поля

Блок «Роли»

Ограничения

Редактирование сотрудника

Деактивация и реактивация

Деактивация

Реактивация

Список сотрудников

Колонки

Фильтры

Поиск

Действия на панели

Безопасность

Расширение профиля (BR 1.4.1)

Вкладки карточки сотрудника

Юридические детали (новая сущность)

Разовая миграция при выкатке

BR 1.4.3 (ввод permissions-модели)

BR 1.4.4 (удаление enum)

Связи с другими модулями

Ссылки

Вид графа

Оглавление

Обратные ссылки