Користувачі K2 ERP

Користувачі K2 ERP — це облікові записи людей, сервісів або інтеграцій, які мають доступ до K2 ERP для виконання бізнес-операцій: створення документів, перегляду довідників, погодження заявок, роботи зі складом, продажами, фінансами, виробництвом, HRM, зарплатою, BI, API, звітами, договорами, файлами та іншими модулями системи.

У K2 ERP користувач — це не просто логін і пароль. Це частина рольової моделі безпеки: користувач має ролі, групи, права, обмеження по організаціях, підрозділах, складах, документах, звітах, API, модулях і діях. Права доступу в ERP визначають, хто може переглядати, створювати, редагувати, погоджувати, проводити, видаляти, експортувати або адмініструвати дані, документи, довідники, звіти, дашборди, модулі та інтеграції. :contentReference[oaicite:0]{index=0}

Головне. Користувач K2 ERP — це не “людина, якій дали доступ до системи”, а керована облікова одиниця з ролями, правами, обмеженнями, відповідальністю, журналом дій і місцем у бізнес-процесах.

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

Що таке користувач K2 ERP

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

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

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

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

Користувач і працівник

У K2 ERP важливо не плутати поняття користувач і працівник.

Поняття	Що означає	Приклад
Працівник	Людина як кадрова одиниця	Іваненко Іван, менеджер продажів
Користувач	Обліковий запис для входу в ERP	ivanenko.i
Роль	Набір прав користувача	Менеджер продажів
Група	Об’єднання користувачів або ролей	Відділ продажів Київ

Працівник може не мати доступу до ERP. Наприклад, виробничий працівник може бути в кадровому обліку, але не мати ERP-логіна.

Користувач може бути не працівником. Наприклад, API-користувач для сайту або інтеграції з банком.

Основні реквізити користувача

Картка користувача K2 ERP може містити:

логін;
ПІБ;
email;
телефон;
статус;
працівника, якщо пов’язаний;
підрозділ;
посаду;
організацію;
групу користувачів;
ролі;
мову інтерфейсу;
часовий пояс;
спосіб автентифікації;
дату створення;
дату останнього входу;
дату блокування;
відповідального адміністратора;
коментар;
ознаку API-користувача;
ознаку зовнішнього користувача.

Приклад:

Поле	Значення
Логін	ivanenko.i
ПІБ	Іваненко Іван Іванович
Email	ivanenko@example.com
Підрозділ	Відділ продажів
Роль	Менеджер продажів
Статус	Активний

Типи користувачів K2 ERP

Тип користувача	Хто це	Приклад
Бізнес-користувач	Працює з документами і процесами	Менеджер продажів
Керівник	Погоджує і контролює	Директор, керівник підрозділу
Операційний користувач	Виконує складські, виробничі або сервісні операції	Комірник, майстер
Фінансовий користувач	Працює з грошима, бюджетами, платежами	Фінансист
Обліковий користувач	Веде бухгалтерський або податковий облік	Бухгалтер
HR-користувач	Працює з персоналом	HR, кадровик
Адміністратор	Налаштовує систему	ERP-адміністратор
API-користувач	Використовується інтеграціями	site_api_user
Аудитор	Має обмежений перегляд	Зовнішній аудитор

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

Роль — це набір прав, який визначає, що користувач може робити в K2 ERP.

У K2 ERP ролі потрібні не тільки для заборони доступу. Вони створюють порядок: кожен користувач має свою ділянку, рівень видимості, права дії та відповідальність у процесі. :contentReference[oaicite:1]{index=1}

Приклади ролей:

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

Групи користувачів

Групи користувачів допомагають керувати доступом не по одному користувачу, а по групах.

Приклади груп:

Відділ продажів;
Бухгалтерія;
Фінансовий відділ;
Склад Київ;
Склад Львів;
HR-відділ;
Виробництво;
Керівники;
Адміністратори;
Зовнішні аудитори;
API-інтеграції.

Групи зручні, коли у компанії багато користувачів або кілька філій.

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

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

Типові дії:

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

Приклад:

Дія	Менеджер продажів	Комірник	Фінансист
Перегляд клієнтів	Так	Ні	Частково
Створення замовлення	Так	Ні	Ні
Відвантаження	Ні	Так	Ні
Погодження платежу	Ні	Ні	Так
Експорт фінансового звіту	Ні	Ні	Так

Обмеження доступу

Окрім ролей, потрібні обмеження.

Обмеження можуть бути за:

організацією;
підрозділом;
складом;
філією;
проєктом;
ЦФВ;
видом документа;
статусом документа;
клієнтом;
менеджером;
видом ціни;
звітом;
дашбордом;
модулем;
API-методом.

Наприклад, комірник складу Київ не повинен бачити й редагувати документи складу Львів, якщо це не потрібно для його роботи.

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

K2 ERP є модульною системою. На сторінках K2 ERP Wiki модуль користувачів і прав доступу описується як блок для користувачів, ролей, прав, обмежень доступу і безпеки даних. :contentReference[oaicite:2]{index=2}

Користувач може мати доступ до окремих модулів:

фінанси;
бухгалтерія;
продажі;
закупівлі;
склад;
CRM;
WMS;
виробництво;
MRP;
MES;
HRM;
зарплата;
документообіг;
договори;
HelpDesk;
автотранспорт;
агро;
елеватор;
BI;
API;
адміністрування.

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

Доступ до організацій

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

Приклад:

Користувач	Організація 1	Організація 2	Організація 3
Бухгалтер 1	Так	Ні	Ні
Головний бухгалтер	Так	Так	Так
Менеджер продажів	Так	Ні	Ні
Фінансовий директор	Так	Так	Так

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

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

Складські користувачі мають бачити тільки свої склади, якщо бізнес-процес не потребує іншого.

Приклад:

Користувач	Склад Київ	Склад Львів	Склад Одеса
Комірник Київ	Так	Ні	Ні
Комірник Львів	Ні	Так	Ні
Керівник логістики	Так	Так	Так

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

Доступ до фінансів

Фінансові дані є чутливими.

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

банківські рахунки;
каси;
платіжний календар;
заявки на оплату;
бюджети;
ДДС;
P&L;
управлінський баланс;
фінансові звіти;
дебіторську заборгованість;
кредиторську заборгованість;
фінансові ліміти;
банківські реквізити.

Приклад:

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

Доступ до зарплати

Зарплатні дані потребують окремого захисту.

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

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

Зарплатний бухгалтер може бачити зарплату, але звичайний адміністратор ERP не обов’язково має бачити зарплатні суми.

Доступ до собівартості

Собівартість — комерційно чутлива інформація.

Її потрібно обмежувати для:

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

Приклад:

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

Доступ до звітів і BI

Звіти можуть містити більше чутливої інформації, ніж документи.

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

фінансових звітів;
зарплатних звітів;
управлінського P&L;
ДДС;
собівартості;
маржі;
клієнтської бази;
дебіторки;
кредиторки;
Power BI-дашбордів;
експортів у Excel.

Power BI не повинен обходити права ERP.

API-користувачі

API-користувач — це обліковий запис для інтеграції, а не для людини.

Приклади:

сайт передає замовлення в ERP;
банк передає виписки;
WMS отримує складські завдання;
CRM передає ліди;
Power BI отримує дані;
мобільний застосунок створює заявки;
маркетплейс передає продажі.

API-користувач має мати:

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

Погано:

API працює під користувачем “Адміністратор”.

Краще:

site_api_user має доступ тільки до створення замовлень і читання статусів.

Сервісні користувачі

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

Приклади:

integration_service;
powerbi_export;
bank_sync;
wms_sync;
mail_sender;
backup_report_user;
monitoring_user.

Для сервісних користувачів потрібно:

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

Зовнішні користувачі

Зовнішні користувачі можуть бути:

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

Для них потрібні особливі правила:

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

Адміністратор K2 ERP

Адміністратор ERP відповідає за технічне й організаційне налаштування доступу.

Він може:

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

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

Створення нового користувача

Типовий процес:

Керівник або HR подає заявку.
Вказується працівник.
Вказується посада.
Вказується підрозділ.
Вказуються потрібні модулі.
Вказуються ролі.
Вказуються організації, склади або ЦФВ.
Адміністратор створює користувача.
Користувач отримує доступ.
Дія записується в audit log.
Через певний час доступ перевіряється.

Приклад заявки:

Поле	Значення
Працівник	Петренко Петро
Підрозділ	Відділ закупівель
Роль	Закупівельник
Організація	ТОВ “Компанія”
Склади	Центральний склад
Строк доступу	Постійний

Блокування користувача

Користувача потрібно блокувати, якщо:

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

Блокування краще, ніж видалення, бо історія дій користувача має залишатися в audit log.

Зміна ролі користувача

Роль потрібно змінювати при:

переведенні в інший підрозділ;
зміні посади;
розширенні обов’язків;
завершенні проєкту;
зміні структури компанії;
відкритті нової філії;
впровадженні нового модуля;
виявленні зайвих прав.

Зміна ролі має бути погоджена й зафіксована.

Життєвий цикл користувача

Життєвий цикл користувача:

Заявка → Створення → Призначення ролей → Робота → Перегляд прав → Зміна ролі → Блокування → Архів

Погано, коли користувачі створюються вручну “по дзвінку”, а потім роками не переглядаються.

Audit log користувачів

Audit log має відповідати на питання:

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

K2 ERP як комплексна система об’єднує фінанси, бухгалтерію, продажі, склад, закупівлі, документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі, тому журнал дій потрібен для контролю змін у багатьох пов’язаних процесах. :contentReference[oaicite:3]{index=3}

SSO

SSO або Single Sign-On — це єдиний вхід через корпоративну систему автентифікації.

Переваги:

користувачу не потрібно пам’ятати багато паролів;
доступ централізовано керується ІТ;
простіше блокувати звільнених працівників;
легше впроваджувати політики паролів;
можна підключити 2FA;
зменшується ризик “забутих” логінів.

SSO особливо корисний для середніх і великих компаній.

2FA

2FA або двофакторна автентифікація — це додатковий рівень захисту.

Вона особливо важлива для:

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

2FA не замінює ролі й права, але зменшує ризик входу сторонньої особи.

Паролі користувачів

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

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

Погано:

Логін: sklad
Пароль: 123456

Краще:

Персональний користувач + сильний пароль + 2FA для критичних ролей.

Спільні користувачі

Спільні користувачі — одна з найнебезпечніших помилок.

Приклад:

Логін: Bukhgalteria
Пароль знають усі бухгалтери.

Проблеми:

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

Правильний принцип:

Одна людина = один користувач = персональна відповідальність.

Користувачі і документообіг

У документообігу користувачі беруть участь у маршрутах погодження.

Приклади:

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

Приклад маршруту:

Менеджер → Керівник відділу → Фінанси → Директор → Архів

Якщо користувачі й ролі налаштовані неправильно, документи зависають або потрапляють не тим людям.

Користувачі і фінансові погодження

У фінансах користувачі можуть:

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

Приклад:

Етап	Користувач	Дія
1	Менеджер	Створює заявку на оплату
2	Керівник	Погоджує потребу
3	Фінансист	Перевіряє бюджет
4	Директор	Затверджує
5	Казначей	Формує платіж

Користувачі і склад

Складські користувачі можуть:

приймати товар;
розміщувати товар;
переміщувати товар;
відбирати товар;
списувати товар;
проводити інвентаризацію;
друкувати етикетки;
працювати з ТСД;
виконувати WMS-завдання;
бачити залишки;
не бачити фінансові дані, якщо це не потрібно.

Приклад ролей:

комірник;
старший комірник;
керівник складу;
оператор WMS;
інвентаризаційна комісія;
логіст.

Користувачі і продажі

У продажах користувачі можуть:

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

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

Користувачі і закупівлі

Закупівельники можуть:

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

Користувачі і виробництво

У виробництві користувачі можуть бути:

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

Вони можуть мати доступ до:

специфікацій;
виробничих замовлень;
MRP;
MES;
списання матеріалів;
випуску продукції;
браку;
НЗВ;
собівартості, якщо дозволено.

Користувачі і HRM

HR-користувачі можуть працювати з:

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

HR-доступ має бути обмежений, бо кадрові дані є персональними.

Користувачі і API

API-користувачі не мають “сидіти” в інтерфейсі як люди.

Для них потрібно:

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

Приклад:

API-користувач	Призначення	Права
site_api_user	Замовлення із сайту	Створення замовлень, читання статусів
powerbi_export	BI-аналітика	Читання погоджених наборів даних
bank_sync	Банківська інтеграція	Імпорт виписок, статуси платежів

Користувачі і Power BI

Користувачі Power BI можуть мати окремі права.

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

які дашборди доступні;
які таблиці доступні;
чи видно зарплату;
чи видно собівартість;
чи видно фінансові дані;
чи видно всі організації;
чи є фільтри по підрозділах;
чи можна експортувати дані;
чи є row-level security.

Power BI не повинен ставати способом обійти ERP-права.

Перегляд прав користувачів

Права потрібно регулярно переглядати.

Наприклад:

раз на місяць для критичних ролей;
раз на квартал для всіх користувачів;
після кадрових змін;
після запуску нового модуля;
після інциденту;
перед аудитом;
після міграції з BAS/1С.

Що перевіряти:

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

Звіт по користувачах

Корисний звіт:

Користувач	Роль	Статус	Останній вхід	Ризик
ivanenko.i	Менеджер продажів	Активний	15.05.2026	Немає
petrenko.p	Бухгалтер	Активний	14.05.2026	Доступ до банку
old.user	Менеджер	Активний	01.10.2024	Неактивний користувач
admin2	Адміністратор	Активний	15.05.2026	Повні права

Типові помилки з користувачами K2 ERP

Помилка	Причина	Наслідок
Один логін на відділ	Так простіше	Немає персонального аудиту
Усі мають повні права	Не налаштована рольова модель	Витік або псування даних
Не блокують звільнених працівників	Немає процесу offboarding	Колишні працівники мають доступ
API працює під адміністратором	Швидке налаштування інтеграції	Надмірні ризики
Не переглядають права	Немає регулярного аудиту	Накопичення зайвих доступів
Power BI бачить усе	Немає BI-безпеки	Обхід ERP-прав
Адміністратор бачить зарплату	Не розділені технічні й бізнес-права	Ризик витоку персональних даних

Помилка: усім дали повні права

Це типова помилка після впровадження.

Причини:

потрібно було швидко запустити систему;
не описали ролі;
користувачі скаржилися, що “не бачать кнопку”;
адміністратор не мав часу налаштовувати доступ;
стару модель перенесли з 1С/BAS.

Наслідки:

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

Помилка: не блокують користувачів після звільнення

Після звільнення працівника потрібно:

заблокувати ERP-користувача;
заблокувати SSO або корпоративний доступ;
відкликати API-токени, якщо були;
передати задачі іншому користувачу;
змінити відповідального в документах;
перевірити доступ до Power BI;
перевірити доступ до файлів;
залишити історію дій.

Не потрібно видаляти користувача, якщо його дії вже є в історії документів.

Помилка: API-токени не контролюються

API-токени потрібно обліковувати.

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

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

Без цього інтеграції стають “чорним ящиком”.

Міграція користувачів із 1С/BAS у K2 ERP

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

Потрібно проаналізувати:

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

У матеріалах K2 ERP зазначається, що під час міграції можуть використовуватися дані про користувачів і ролі 1С/BAS: користувачі, профілі доступу, підрозділи, склади, організації, дозволені документи, права на звіти, аудит доступу, Power BI, API та перехід на сучасну ERP. :contentReference[oaicite:4]{index=4}

Що переносити з 1С/BAS

Можна перенести або використати як джерело:

ПІБ користувача;
email;
підрозділ;
посаду;
активність;
роль;
профіль доступу;
організації;
склади;
групи;
історію останнього входу, якщо доступна;
зв’язок із працівником;
відповідальність за документи;
список звітів;
список інтеграційних користувачів.

Але права краще переглядати і перебудовувати, а не копіювати “один в один”.

Що не переносити з 1С/BAS

Не варто переносити:

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

Карта міграції користувачів

Об’єкт 1С/BAS	Що означає	Аналог у K2 ERP	Контроль
Користувач	Обліковий запис	User	Активність, email, працівник
Роль	Набір прав	Role	Не копіювати без аналізу
Профіль доступу	Комбінація прав	Access profile	Переглянути логіку
Організація	Обмеження по юрособі	Company access	Звірити з актуальною структурою
Склад	Обмеження по складу	Warehouse access	Звірити з логістикою
Група користувачів	Об’єднання користувачів	User group	Очистити старі групи
Інтеграційний користувач	Обмін із системами	API user	Мінімальні права, токени

Реплікатор K2 і користувачі

Реплікатор K2 може допомогти при підготовці міграції користувачів із 1С/BAS.

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

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

Користувачі після запуску K2 ERP

Після запуску потрібно контролювати:

чи всі користувачі можуть увійти;
чи немає зайвих прав;
чи працюють ролі;
чи працюють погодження;
чи коректно працює SSO;
чи не залишились старі активні доступи;
чи заблоковано тестові логіни;
чи працюють API-користувачі;
чи не бачить Power BI зайві дані;
чи записується audit log.

Користувачі і архів BAS

Після переходу в K2 ERP стара BAS/1С-база може залишатися архівом.

Правила:

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

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

Санкції та ризики 1С/BAS у контексті користувачів

При міграції користувачів із 1С / BAS потрібно враховувати не лише технічні ролі, а й санкційний та безпековий контекст.

1С історично є російською програмною екосистемою, а BAS пов’язаний із цією технологічною спадщиною. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до санкцій. ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009))

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

Типові питання

Що таке користувач K2 ERP?

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

Чим користувач відрізняється від працівника?

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

Чи можна одному відділу дати один логін?

Ні, це погана практика. Один логін на відділ руйнує аудит і відповідальність. Краще один працівник — один користувач.

Чи потрібно переносити всіх користувачів із 1С/BAS?

Ні. Потрібно перенести тільки актуальних користувачів, переглянути ролі, прибрати старі логіни, спільні облікові записи, звільнених працівників і зайві повні права.

Що таке API-користувач?

API-користувач — це спеціальний обліковий запис для інтеграції, наприклад сайту, банку, WMS або Power BI. Він має мати мінімальні права і окремий журнал запитів.

Навіщо потрібен audit log?

Audit log показує, хто і коли створив, змінив, погодив, видалив або експортував дані. Це основа безпеки, контролю і розслідування помилок.

Коротко

Питання	Відповідь
Що таке користувач K2 ERP?	Обліковий запис людини або сервісу для доступу до ERP.
Основні елементи	Логін, email, працівник, ролі, групи, права, обмеження, статус.
Що найважливіше?	Мінімальні права, персональні логіни, audit log, регулярний перегляд доступів.
Чого не можна робити?	Давати всім повні права, використовувати спільні логіни, не блокувати звільнених.
API-користувач	Окремий користувач для інтеграцій із мінімальними правами.
При міграції з 1С/BAS	Не копіювати хаос, а побудувати нову рольову модель.

Висновок

Користувачі K2 ERP — це основа безпечної роботи системи. Саме через користувачів ERP визначає, хто може бачити клієнтів, створювати документи, погоджувати платежі, працювати зі складом, змінювати ціни, бачити зарплату, експортувати звіти, запускати API або адмініструвати систему.

Правильна модель користувачів складається з персональних логінів, ролей, груп, обмежень, audit log, SSO/2FA для критичних доступів, окремих API-користувачів і регулярного перегляду прав.

Сильна ERP починається не з документів, а з правильно налаштованих користувачів. Якщо користувачі мають зайві права, спільні логіни або неконтрольовані API-токени, навіть найкраща ERP стає ризиковою.

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

Див. також

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