Права доступу

Права доступу — це система правил, яка визначає, хто з користувачів ERP-системи може переглядати, створювати, редагувати, погоджувати, проводити, видаляти, експортувати або адмініструвати дані, документи, довідники, звіти, дашборди, модулі та інтеграції.

У контексті K2 ERP права доступу потрібні для захисту бізнес-даних, розмежування відповідальності, контролю дій користувачів, побудови маршрутів погодження, безпечної роботи з фінансами, складом, CRM, зарплатою, виробництвом, WMS, API, дашбордами та бізнес-процесами.

Правильно налаштовані права доступу дозволяють компанії працювати прозоро: менеджер бачить своїх клієнтів, комірник — свої складські завдання, бухгалтер — документи обліку, фінансовий директор — платежі й бюджети, керівник — дашборди, а адміністратор — налаштування системи.

Головне. Права доступу в ERP — це не просто «можна» або «не можна». Це основа безпеки, відповідальності, контролю, аудиту, документообігу, BP-моделей, дашбордів і управління бізнесом.

Важливе застереження. Продукти 1С та частина екосистеми BAS пов’язані з санкційними, безпековими та репутаційними ризиками в Україні. Держспецзв’язку оприлюднює перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, а публічні огляди зазначають, що до нього входять продукти 1С і BAS. Перед використанням, підтримкою або закупівлею BAS/1С компанії варто перевіряти актуальні офіційні переліки, санкційні списки, політики кібербезпеки та вимоги комплаєнсу.

Українська альтернатива. K2 ERP може розглядатися як українська альтернатива BAS/1С для компаній, яким потрібні сучасні права доступу, ролі, користувачі, BP-моделі, WMS, CRM, фінанси, дашборди, Power BI, AI, API, інтеграції та контроль безпеки даних.

Що таке права доступу

Права доступу — це набір правил, які визначають, що саме може робити користувач у системі.

Права доступу відповідають на питання:

хто може увійти в систему;
які модулі доступні користувачу;
які документи він може бачити;
які документи він може створювати;
які документи він може редагувати;
які документи він може проводити;
які документи він може погоджувати;
які документи він може видаляти;
які довідники він може змінювати;
які звіти він може відкривати;
які дашборди він може бачити;
які дані він може експортувати;
які API-методи він може використовувати;
які налаштування системи йому доступні.

Для чого потрібні права доступу в ERP

Права доступу потрібні не тільки для захисту від помилок або шахрайства. Вони допомагають побудувати керовану систему роботи компанії.

Завдання	Що дають права доступу
Безпека даних	захищають фінанси, зарплату, клієнтів, договори, склади та комерційну інформацію
Розподіл відповідальності	кожен користувач має доступ тільки до своїх задач і документів
Контроль дій	система фіксує, хто створив, змінив, погодив або видалив документ
Документообіг	документи проходять правильні маршрути погодження
BP-модель	бізнес-процеси працюють за ролями, етапами та умовами
Аудит	можна перевірити історію дій користувачів
Дашборд	керівники бачать потрібні показники, а працівники — тільки свою частину
API	зовнішні системи отримують доступ тільки до дозволених даних

Користувач

Користувач — це людина або технічний обліковий запис, який працює в ERP.

Користувач може бути:

менеджером з продажів;
бухгалтером;
фінансовим директором;
комірником;
закупівельником;
виробничим працівником;
HR;
керівником;
адміністратором;
зовнішнім підрядником;
API-користувачем;
сервісним користувачем для інтеграцій.

У K2 ERP кожному користувачу можуть призначатися ролі, права, підрозділи, доступні модулі, документи, склади, організації та дашборди.

Роль користувача

Роль користувача — це набір прав, який описує типову функцію працівника в компанії.

Наприклад:

Один користувач може мати одну або кілька ролей.

Наприклад, керівник складу може мати ролі:

Комірник;
Керівник складу;
Матеріально відповідальна особа;
Користувач WMS-дашборду.

RBAC

RBAC або Role-Based Access Control — це модель управління доступом на основі ролей.

У RBAC права не видаються кожному користувачу вручну по одному. Замість цього створюються ролі, а користувачі отримують ролі.

Приклад:

Роль	Типові права
Менеджер з продажів	клієнти, угоди, замовлення покупців, рахунки, свої продажі
Комірник	приймання, розміщення, комплектація, інвентаризація, складські завдання
Бухгалтер	первинні документи, банк, податки, зарплата, основні засоби
Фінансовий директор	платежі, бюджети, фінансові звіти, погодження оплат
Директор	дашборди, фінанси, продажі, склад, ключові звіти
Адміністратор	користувачі, ролі, налаштування, інтеграції

Типи прав доступу

Права доступу можуть бути різних типів.

Тип права	Що означає
Перегляд	користувач може бачити дані
Створення	користувач може створювати нові записи або документи
Редагування	користувач може змінювати дані
Проведення	користувач може проводити документ і впливати на облік
Погодження	користувач може затверджувати документ або етап процесу
Видалення	користувач може видаляти записи
Експорт	користувач може вивантажувати дані
Друк	користувач може друкувати документи
Адміністрування	користувач може змінювати налаштування системи
API-доступ	користувач або сервіс може працювати через API

Рівні доступу

У ERP права доступу можуть працювати на різних рівнях.

Рівень	Приклад
Система	доступ до входу в ERP
Модуль	доступ до CRM, WMS, фінансів, зарплати, виробництва
Документ	доступ до замовлень, рахунків, актів, оплат
Довідник	доступ до номенклатури, контрагентів, складів, працівників
Поле	доступ до окремих полів, наприклад собівартості або зарплати
Запис	доступ тільки до своїх клієнтів, свого складу або свого підрозділу
Дія	проведення, погодження, друк, експорт, видалення
Звіт	доступ до звітів і дашбордів
API	доступ зовнішніх систем до певних методів і даних

Доступ до модулів

У K2 ERP права можуть обмежувати доступ до окремих модулів.

Наприклад:

Менеджеру з продажів не обов’язково бачити зарплату. Комірнику не обов’язково бачити фінансовий результат. Бухгалтеру не завжди потрібен доступ до налаштувань WMS. Саме для цього й потрібні права доступу.

Доступ до документів

Права доступу до документів визначають, що користувач може робити з документами.

Приклади документів:

Для кожного документа можна налаштовувати окремі права:

перегляд;
створення;
редагування;
проведення;
погодження;
друк;
експорт;
видалення.

Доступ до довідників

Довідники — це основа обліку. Якщо користувачі без контролю змінюють довідники, у системі швидко з’являється хаос.

Типові довідники:

Приклад правила:

Довідник	Хто може переглядати	Хто може змінювати
Номенклатура	менеджери, склад, бухгалтерія	адміністратор номенклатури
Контрагенти	менеджери, бухгалтерія, керівники	менеджери та бухгалтерія за правилами
Склади	склад, закупівлі, керівники	адміністратор складу
Працівники	HR, бухгалтерія, керівник	HR і адміністратор
Ролі	адміністратор	адміністратор

Доступ до полів

Іноді потрібно обмежувати не весь документ, а окремі поля.

Наприклад:

менеджер бачить ціну продажу, але не бачить собівартість;
комірник бачить кількість, але не бачить закупівельну ціну;
HR бачить кадрові дані, але не бачить фінансові платежі;
керівник бачить зарплатний фонд, але не бачить деталізацію по всіх працівниках;
бухгалтер бачить податкові параметри, але не змінює комерційні умови продажу.

Польові права доступу особливо важливі для:

зарплати;
фінансів;
собівартості;
маржі;
персональних даних;
банківських реквізитів;
комерційних умов;
внутрішніх коментарів.

Доступ до записів

Доступ до записів означає, що користувач бачить не всі дані, а тільки частину.

Приклади:

менеджер бачить тільки своїх клієнтів;
керівник відділу бачить клієнтів свого відділу;
регіональний менеджер бачить тільки свій регіон;
комірник бачить тільки свій склад;
бухгалтер бачить тільки свою організацію;
HR бачить тільки працівників певного підрозділу;
директор бачить усі дані.

Це важливо для компаній із кількома складами, філіями, юридичними особами, підрозділами або напрямами бізнесу.

Права доступу і BP-модель

Права доступу тісно пов’язані з BP-моделями.

BP-модель визначає, як рухається процес, а права доступу визначають, хто може виконувати кожен етап.

Приклад:

Етап BP-моделі	Роль	Право доступу
Створення заявки	Ініціатор	створення заявки
Погодження керівником	Керівник підрозділу	погодження заявки
Перевірка бюджету	Фінансист	перегляд бюджету та погодження
Оплата	Бухгалтер	створення платіжного документа
Контроль	Директор	перегляд дашборда і статусів

Без прав доступу BP-модель не буде безпечною, бо будь-хто зможе виконати чужий етап або змінити критичний документ.

Права доступу і документообіг

У документообігу права доступу визначають, хто може:

створити документ;
відправити документ на погодження;
погодити документ;
відхилити документ;
повернути на доопрацювання;
підписати документ;
зареєструвати документ;
закрити документ;
переглянути історію погоджень.

Приклад маршруту погодження договору:

Менеджер створює договір.
Юрист перевіряє юридичні умови.
Фінансист перевіряє бюджет і ризики.
Директор погоджує договір.
Відповідальний підписує договір.
Бухгалтерія реєструє документ.

Кожен етап має свою роль і свої права.

Права доступу і WMS

У WMS для складу права доступу критично важливі, бо склад — це зона матеріальної відповідальності.

Типові ролі WMS:

комірник;
старший комірник;
керівник складу;
матеріально відповідальна особа;
логіст;
закупівельник;
менеджер продажів;
аудитор складу.

Приклад прав:

Операція	Комірник	Керівник складу	Бухгалтер
Приймання товару	так	так	перегляд
Розміщення по комірках	так	так	ні
Переміщення	так	так	перегляд
Списання	ні	погодження	проведення
Інвентаризація	участь	створення	проведення результатів
Перегляд собівартості	ні	за потреби	так

Права доступу і CRM

У CRM права доступу допомагають захистити клієнтську базу.

Потрібно контролювати:

хто бачить клієнтів;
хто може створювати ліди;
хто може змінювати контакти;
хто бачить історію комунікацій;
хто може передавати клієнта іншому менеджеру;
хто бачить комерційні умови;
хто бачить маржинальність;
хто може експортувати клієнтську базу.

Приклад:

менеджер бачить своїх клієнтів;
керівник бачить клієнтів команди;
директор бачить усіх клієнтів;
адміністратор CRM може змінювати налаштування;
експорт клієнтської бази дозволений тільки керівнику.

Права доступу і фінанси

Фінансовий модуль потребує особливо жорсткого контролю.

Потрібно обмежувати доступ до:

банківських рахунків;
каси;
оплат покупців;
оплат постачальникам;
заявок на оплату;
бюджетів;
cash flow;
зарплатного фонду;
податкових платежів;
фінансового результату;
прибутку;
маржинальності.

Приклад фінансових ролей:

Роль	Доступ
Бухгалтер	банк, каса, первинні документи, податки
Фінансовий менеджер	заявки на оплату, бюджети, cash flow
Фінансовий директор	погодження оплат, фінансовий результат, дашборди
Директор	всі фінансові дашборди та ключові звіти
Менеджер	тільки інформація по оплатах своїх клієнтів

Права доступу і зарплата

Зарплата — один із найчутливіших розділів ERP.

Права доступу повинні обмежувати:

оклади;
премії;
утримання;
податки;
лікарняні;
відпустки;
персональні дані;
банківські реквізити;
нарахування;
виплати;
зарплатні звіти.

Типове правило: зарплатні дані бачить тільки бухгалтерія, HR, керівник у межах дозволів і директор.

Права доступу і дашборди

Дашборд може містити дуже чутливу інформацію.

Наприклад:

продажі;
прибуток;
маржа;
дебіторка;
кредиторка;
зарплата;
cash flow;
податки;
залишки;
собівартість;
продуктивність працівників.

Тому потрібно налаштовувати, хто бачить який дашборд.

Дашборд	Хто може бачити
Дашборд продажів	менеджери, керівник продажів, директор
Фінансовий дашборд	фінансовий директор, бухгалтерія, директор
Складський дашборд	склад, логістика, керівник, директор
Дашборд зарплати	HR, бухгалтерія, директор
Дашборд виробництва	виробництво, плановики, керівник, директор
Дашборд керівника	власник, директор, топменеджмент

Права доступу і API

API відкриває доступ до даних ERP для зовнішніх систем.

Тому API-доступ потрібно обмежувати так само уважно, як і доступ користувачів.

API може використовуватися для:

інтернет-магазину;
маркетплейсу;
мобільного додатку;
Power BI;
банку;
доставки;
CRM;
сайту;
AI-сервісу;
зовнішньої аналітики.

Для API потрібно визначити:

які методи доступні;
які дані можна читати;
які дані можна змінювати;
які документи можна створювати;
які обмеження діють;
який токен використовується;
коли токен потрібно відкликати;
які дії логуються.

Аудит дій користувачів

Аудит дій користувачів — це журнал, який показує, хто і що зробив у системі.

Аудит може фіксувати:

вхід у систему;
створення документа;
зміну документа;
проведення документа;
скасування проведення;
видалення;
зміну довідника;
погодження;
відхилення;
експорт даних;
зміну прав доступу;
API-запит.

Аудит потрібен для безпеки, внутрішнього контролю, розслідування помилок і захисту компанії.

Принцип мінімальних прав

Принцип мінімальних прав означає, що користувач має отримувати тільки ті права, які потрібні йому для роботи.

Наприклад:

менеджер не повинен мати доступ до зарплати;
комірник не повинен змінювати ціни продажу;
бухгалтер не повинен змінювати права адміністратора;
API-користувач не повинен мати повний доступ до всіх даних;
стажер не повинен бачити фінансовий результат компанії.

Цей принцип зменшує ризик помилок, витоку даних і зловживань.

Типові ролі в K2 ERP

Роль	Основні права
Адміністратор	користувачі, ролі, налаштування, модулі, інтеграції
Директор	всі ключові дашборди, звіти, погодження критичних документів
Фінансовий директор	бюджети, платежі, cash flow, фінансові звіти, погодження оплат
Бухгалтер	банк, каса, первинні документи, податки, зарплата, основні засоби
Менеджер з продажів	клієнти, угоди, замовлення, рахунки, оплати своїх клієнтів
Керівник продажів	команда продажів, плани, звіти, дашборди продажів
Закупівельник	постачальники, заявки, замовлення постачальникам, закупівельні ціни
Комірник	приймання, розміщення, переміщення, комплектація, інвентаризація
Керівник складу	складські операції, МВО, звіти, інвентаризації, контроль залишків
HR	працівники, кадрові документи, відпустки, частина зарплатних даних
Користувач API	обмежений доступ для інтеграцій

Приклад прав доступу для торгової компанії

Об’єкт	Менеджер	Комірник	Бухгалтер	Директор
Клієнти	свої клієнти	ні	перегляд	всі
Замовлення покупця	створення і редагування своїх	перегляд для відвантаження	перегляд	всі
Рахунок покупцю	створення	ні	проведення	всі
Оплата покупця	перегляд своїх	ні	створення і проведення	всі
Складські залишки	перегляд доступних	повний складський доступ	перегляд	всі
Собівартість	ні	ні	так	так
Дашборд продажів	свої продажі	ні	перегляд	всі

Приклад прав доступу для складу

Операція	Комірник	Старший комірник	Керівник складу	Бухгалтер
Приймання	так	так	так	перегляд
Розміщення	так	так	так	ні
Переміщення	так	так	так	перегляд
Інвентаризація	участь	створення	затвердження	проведення результатів
Списання	ні	створення	погодження	проведення
Перегляд залишків	свій склад	свій склад	всі склади	всі склади
Перегляд собівартості	ні	ні	за потреби	так

Приклад прав доступу для фінансів

Операція	Менеджер	Бухгалтер	Фінансовий директор	Директор
Створити рахунок покупцю	так	так	перегляд	перегляд
Внести оплату покупця	ні	так	перегляд	перегляд
Створити заявку на оплату	так	так	так	так
Погодити оплату	ні	ні	так	так
Провести оплату	ні	так	ні	перегляд
Перегляд cash flow	ні	частково	так	так
Перегляд прибутку	ні	частково	так	так

Типові помилки при налаштуванні прав доступу

Помилка	Наслідок	Як уникнути
Усім дати повний доступ	ризик помилок, витоку даних і зловживань	застосовувати принцип мінімальних прав
Налаштовувати права окремо кожному користувачу	складно підтримувати систему	використовувати ролі
Не обмежити експорт	клієнтська база або фінансові дані можуть бути вивантажені	окремо контролювати експорт
Не обмежити видалення	важливі документи можуть бути видалені	дозволити видалення тільки адміністраторам або через погодження
Не вести аудит	неможливо знайти відповідального за помилку	увімкнути журнал дій
Не перевіряти права після зміни посади	колишній працівник зберігає зайвий доступ	регулярно переглядати ролі
Дати API повний доступ	зовнішня система може отримати надмірні дані	створювати окремі API-ролі
Не обмежити зарплату	витік персональних і фінансових даних	створити окремі ролі для зарплати й HR

Як налаштовувати права доступу

Типовий порядок налаштування прав доступу в ERP:

Описати структуру компанії.
Визначити ролі користувачів.
Визначити модулі, з якими працює кожна роль.
Визначити документи для кожної ролі.
Визначити довідники для кожної ролі.
Визначити дії: перегляд, створення, редагування, проведення, погодження.
Визначити доступ до звітів і дашбордів.
Визначити доступ до полів.
Визначити доступ до записів.
Налаштувати API-доступ.
Увімкнути аудит дій.
Перевірити права на тестових користувачах.
Навчити адміністраторів.
Регулярно переглядати права.

Чеклист прав доступу

Питання	Так/Ні
Чи є список ролей користувачів?
Чи кожна роль має опис?
Чи обмежений доступ до фінансів?
Чи обмежений доступ до зарплати?
Чи обмежений доступ до собівартості?
Чи обмежений експорт даних?
Чи обмежене видалення документів?
Чи налаштовані права для API?
Чи ведеться аудит дій?
Чи переглядаються права після звільнення або зміни посади?
Чи є окремі права для дашбордів?
Чи права доступу пов’язані з BP-моделями?

Права доступу при переході з BAS/1С на K2 ERP

Під час переходу з BAS або 1С на K2 ERP не варто сліпо копіювати старі права доступу.

У старих системах часто бувають проблеми:

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

Під час переходу на K2 ERP варто:

описати ролі з нуля;
прибрати зайві права;
обмежити чутливі дані;
налаштувати BP-моделі;
створити дашборди відповідно до ролей;
налаштувати журнал дій;
створити окремі API-ролі;
перевірити права перед запуском.

Права доступу як частина безпеки K2 ERP

У K2 ERP права доступу можуть бути частиною ширшої системи безпеки.

До неї можуть входити:

користувачі;
ролі;
групи;
підрозділи;
організації;
права на модулі;
права на документи;
права на довідники;
права на поля;
права на записи;
права на API;
журнал дій;
дашборд безпеки;
контроль активних сесій;
блокування доступу;
історія змін.

Права доступу і AI

AI може допомагати аналізувати права доступу.

Штучний інтелект може:

знаходити користувачів із надмірними правами;
виявляти підозрілі дії;
аналізувати частоту використання ролей;
підказувати, які права можна прибрати;
знаходити неактивних користувачів;
пояснювати ризики доступу;
формувати звіт для адміністратора;
попереджати про небезпечні комбінації прав.

Приклад AI-підказки:

AI-підказка. Користувач має одночасно права на створення заявки на оплату, погодження цієї заявки та проведення платежу. Це створює ризик відсутності розподілу обов’язків. Рекомендується розділити права між ролями «Ініціатор», «Фінансовий директор» і «Бухгалтер».

Права доступу і Power BI

Якщо дані з ERP передаються в Power BI, права доступу потрібно враховувати і в аналітиці.

Потрібно визначити:

хто бачить фінансові звіти;
хто бачить продажі;
хто бачить маржу;
хто бачить зарплату;
хто бачить склад;
хто бачить дані по підрозділах;
чи потрібна фільтрація по ролях;
чи можна експортувати дані з Power BI.

У K2 ERP відкрита архітектура бази даних може дозволяти будувати BI-аналітику, але права доступу мають бути продумані не тільки в ERP, а й у зовнішніх системах.

Коротко

Питання	Відповідь
Що таке права доступу?	Це правила, які визначають, хто і що може робити в ERP: переглядати, створювати, змінювати, погоджувати, проводити, видаляти або експортувати дані.
Для чого потрібні права доступу?	Для безпеки, розподілу відповідальності, контролю дій, документообігу, BP-моделей, аудиту та захисту даних.
Що таке роль користувача?	Це набір прав для типової функції: менеджер, бухгалтер, комірник, фінансовий директор, директор, адміністратор.
Що таке RBAC?	Це модель управління доступом на основі ролей, коли права видаються ролям, а користувачі отримують ролі.
Чи можна обмежити доступ до окремих полів?	Так. Наприклад, можна приховати собівартість, зарплату, маржу або персональні дані.
Чи потрібно обмежувати API?	Так. API-доступ має мати окремі ролі, обмежені методи, токени та журнал дій.
Чи треба копіювати права з BAS/1С?	Ні. Під час переходу на K2 ERP краще переглянути ролі, прибрати зайві права й налаштувати доступ за реальними процесами.
Чи є K2 ERP альтернативою BAS/1С?	Так. K2 ERP може бути українською альтернативою BAS/1С із сучасними правами доступу, ролями, BP-моделями, дашбордами, API та інтеграціями.

Висновок

Права доступу — це фундамент безпеки ERP-системи. Вони визначають, хто може бачити дані, створювати документи, змінювати довідники, погоджувати операції, проводити платежі, працювати зі складом, переглядати зарплату, відкривати дашборди, використовувати API та адмініструвати систему.

У K2 ERP права доступу можуть бути пов’язані з ролями, користувачами, BP-моделями, документообігом, WMS, CRM, фінансами, зарплатою, виробництвом, дашбордами, Power BI, AI та інтеграціями.

Правильне налаштування прав доступу дозволяє компанії зменшити ризики, захистити дані, прибрати хаос, забезпечити розподіл обов’язків, контролювати дії користувачів і будувати прозору систему управління.

Під час переходу з BAS або 1С на K2 ERP права доступу потрібно не копіювати механічно, а переглядати з урахуванням реальних бізнес-процесів, безпеки, ролей, дашбордів, API та сучасних вимог до української ERP.

Головний результат. Права доступу в K2 ERP дозволяють компанії перейти від хаотичного доступу до керованої системи безпеки: ролі, користувачі, документи, довідники, поля, записи, BP-моделі, WMS, CRM, фінанси, зарплата, дашборди, API, аудит і контроль дій — у сучасній українській ERP-платформі.

Див. також

Зовнішні посилання