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

 

Наслідки:

Простий приклад:

</div>

== Двофакторна автентифікація ==
! # Розділити бізнес-користувачів і сервісні акаунти. Етап

* входу в систему;
* визначення прав;
* журналювання дій;
* персональних налаштувань;
* підписання або підтвердження операцій;
* участі в бізнес-процесах;
* відстеження відповідальності.[[Категорія:1С]]

як приклад:

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

== Матриця доступу ==

== Приклад журналу дій ==

Кожна важлива дія користувача має журналюватися.== Організація користувача ==
== Паролі ==
== Типові помилки в налаштуванні користувачів ==
Погано:

manager

У [[K2 ERP]] потрібно створювати нову модель доступу, а не переносити старий хаос.[[Категорія:Цифрова незалежність України]]

'''Роль''' визначає, що користувач системи здатна робити в системі. |-
| Чи виступає як санкційні ризики у [[BAS]] і [[1С]]?[[Категорія:Інтеграція з BAS]]
Під час переходу з [[BAS]] або [[1С]] у [[K2 ERP]] потрібно проаналізувати старих користувачів. У контексті переходу з [[BAS]] або [[1С]] на [[K2 ERP]] користувачі мають особливе значення, тому що потрібно не без зусиль перенести список логінів, а правильно побудувати нову модель доступу: хто що бачить, хто що здатна створювати, хто здатна проводити документи, хто має доступ до фінансів, зарплати, складу, собівартості, інтеграцій, адміністрування та аналітики. # Регулярно переглядати права. користувач системи

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

* задачі;
* документи в роботі;
* KPI;
* повідомлення;
* швидкі дії;
* звіти;
* фільтри;
* обрані функції. ! Тип

== Висновок ==

* документи;
* звіти;
* журнали;
* довідники;
* проводки;
* історію змін. Якщо всі працюють під одним логіном, відповідальність зникає. ! * випадкових помилок;
* несанкціонованих змін;
* витоку даних;
* конфлікту обов’язків;
* зловживань;
* хаосу в документах;
* неконтрольованого експорту даних. Адміністратор
|-
| Замовлення покупця
| Створення і зміна
| Перегляд
| Перегляд
|-
| Реалізація
| Створення
| Перегляд
| Проведення
|-
| Складські залишки
| Перегляд
| Зміна через документи
| Перегляд
|-
| Собівартість
| Немає доступу
| Немає доступу
| Перегляд
|-
| Каса
| Немає доступу
| Немає доступу
| Повний доступ
|}

У [[BI]] користувачі так само мають різні права. # Налаштувати мінімально необхідні права.== Таблиця міграції користувачів ==
== Вступ ==
== користувач системи і права на експорт ==
|-
| api_site
| інтеграційні функції ERP із сайтом
| Замовлення, товари, залишки, статуси
|-
| api_wms
| інтеграційні функції ERP зі складом
| Складські документи, залишки, переміщення
|-
| api_crm
| інтеграційні функції ERP з CRM
| Клієнти, угоди, статуси
|-
| bi_export
| Передача даних у BI
| Читання аналітичних даних
|-
| bank_import
| Імпорт банківських операцій
| Банківські документи
|}

[[Категорія:Права доступу]]

'''Підхід K2 ERP.''' У [[K2 ERP]] користувач системи має бути прив’язаний до реальної ролі в бізнесі: бухгалтер, менеджер, комірник, керівник, касир, логіст, адміністратор, інтегратор, сервісний користувач системи або інша роль. Для кожного API-користувача потрібно визначити:

* [[K2]]
* [[K2 ERP]]
* [[ERP]]
* [[BAS]]
* [[1С]]
* [[Права доступу]]
* [[Ролі K2 ERP]]
* [[Групи користувачів K2 ERP]]
* [[API]]
* [[BI]]
* [[Журналювання]]
* [[Кібербезпека]]
* [[Конфігурація BAS]]
* [[Клієнт-серверний режим BAS]]
* [[Файловий режим BAS]]
* [[Резервна копія 1С]]
* [[Журнал реєстрації 1С]]
* [[Web-сервіси 1С]]
* [[JSON 1С]]
* [[Інтеграція з BAS]]
* [[Інтеграція з 1С]]
* [[Міграція з BAS]]
* [[Міграція з 1С]]
* [[Заміна BAS]]
* [[Заміна 1С]]
* [[Оперативний облік 1С]]
* [[Регламентований облік 1С]]
* [[Довідники 1С]]
* [[Документи 1С]]
* [[Українське програмне забезпечення]]
* [[Автоматизація бізнесу]]
* [[Цифрова незалежність]]
* [[Деколонізація обліку]]

входу. Роль

Для складських і торгових ролей критично мати складський облік за замовчуванням. # Зберегти історію дій. як приклад:
Обліковий запис — це технічне представлення користувача в системі. | Заблокувати, зняти активні права, перепризначити задачі й залишити історію дій.== Людина і користувач системи ==
як приклад:
|-
| Що таке користувач системи [[K2 ERP]]? Приклад:

! Організація
[[Категорія:Адміністрування]]
== користувач системи K2 ERP і цифрова незалежність ==
При звільненні працівника користувача не обов’язково видаляти. Профіль користувача здатна містити:

Сервісний користувач системи не повинен мати зайвих прав. Це підвищує зручність роботи, але не повинно порушувати єдині правила обліку. * про нові задачі;
* про погодження;
* про помилки;
* про завершення обробки;
* про зміну статусу;
* про наближення строку;
* про перевищення ліміту;
* про відхилення в процесі. * логін і пароль;
* корпоративний обліковий запис;
* одноразовий код;
* двофакторна автентифікація;
* токен;
* інтеграційні функції ERP з каталогом користувачів;
* API-ключ для сервісних користувачів.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

У будь-якій ERP-системі користувач системи — це точка входу в бізнес-процеси. | Активних користувачів, ролі, групи, адміністраторів, сервісні акаунти, спільні логіни й зайві права. ! Адміністраторські права мають бути обмежені й контрольовані. {| class="wikitable" style="width:100%;"

це обліковий запис людини або сервісу в системі [[K2 ERP]]. Він здатна:
[[Категорія:Ролі користувачів]]
як приклад:
Групи користувачів допомагають керувати доступами. Доступ до персональних даних має бути обмежений реальними потребами роботи. | Які довідники, документи, звіти, обробки, BI-дані та API-методи доступні користувачу. # Описати групи користувачів. Приклад:

'''Права доступу''' визначають, які дії дозволені користувачу.<syntaxhighlight lang="text">

</div>
== користувач системи і відповідальність ==
== Коротко ==
== користувач системи і друковані форми ==
Але не повинен:
! * контролювати дії;
* захищати інформаційні дані;
* обмежувати доступ;
* розділяти ролі;
* уникати спільних логінів;
* захищати зарплату, фінансовий блок й собівартість;
* контролювати інтеграції;
* вести аудит;
* підтримувати порядок у бізнес-процесах. Поле

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

== Роль користувача ==
Аудиторський доступ зазвичай має бути тільки для перегляду.[[Категорія:Групи користувачів]]

* персональні паролі;
* періодична зміна для критичних ролей;
* блокування звільнених користувачів;
* окремі паролі для сервісних інтеграцій;
* журналювання входів;
* двофакторна автентифікація для важливих доступів. |-
| Що таке сервісний користувач системи? Автентифікація — це перевірка, що користувач системи виступає як тим, за кого себе видає. # Описати ролі. користувач системи у [[K2 ERP]] має права доступу, ролі, профіль, конфігурація, підрозділ, організацію, історію дій і відповідальність за операції, які він виконує в системі. Роль

!== Підрозділ користувача ==

[[Категорія:Конфігурація BAS]]

[[Категорія:Журналювання]]

[[Категорія:BAS]]

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

користувач системи здатна мати:

! Доступ
sklad / пароль для всіх комірників
{| class="wikitable" style="width:100%;"

Після запуску [[K2 ERP]] потрібно перевірити:

* неможливо встановити відповідального;
* складно розслідувати помилки;
* немає персональної історії;
* пароль оперативно поширюється;
* звільнений працівник здатна знати доступ. Тому під час переходу в [[K2 ERP]] потрібно не копіювати стару хаотичну модель користувачів із BAS/1С, а створювати нову контрольовану модель ролей, доступів і відповідальності. як приклад:
== користувач системи і складські інформаційні дані ==
[[Категорія:Web-сервіси 1С]]
[[Категорія:Безпека]]
Це зменшує ризики:
! | Бо неможливо встановити відповідального за дії, помилки або зміни. Хто це
api_site
Без правильної моделі користувачів ERP оперативно перетворюється на хаос: усі бачать усе, адміністраторські права роздані зайвим людям, документи змінюються без контролю, а відповідальність за помилки неможливо встановити. # Перевірити права на тестових сценаріях. API-користувач має бачити тільки ті інформаційні дані, які потрібні для інтеграції. # Описати групи доступу. ! # Налаштувати склади й каси за замовчуванням. Приклад

!== Обліковий запис ==

Найчастіші проблеми:

* переносити всіх користувачів із BAS без аналізу;
* залишати спільні логіни;
* видавати всім повні права;
* не вести журнал дій;
* не блокувати звільнених користувачів;
* не розділяти бізнес-користувачів і сервісні акаунти;
* не обмежувати доступ до зарплати;
* не обмежувати доступ до собівартості;
* не перевіряти API-доступи;
* не переглядати права після запуску;
* ігнорувати санкційні й кібербезпекові ризики старої системи. ! Окремі продукти [[1С]] і [[BAS]] внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні. # Перевірити доступи. Фінансові інформаційні дані мають бути захищені. користувач системи
користувач системи здатна мати статус:
__TOC__
|-
| buh_kyiv
| ТОВ Київ
| Бухгалтерські документи ТОВ Київ
|-
| buh_lviv
| ТОВ Львів
| Бухгалтерські документи ТОВ Львів
|-
| fin_dir
| Усі організації
| Консолідована фінансова аналітичні інструменти
|}

'''Цифрова незалежність.''' Перехід у [[K2 ERP]] — це можливість не тільки замінити BAS або 1С, а й навести порядок у користувачах, ролях, доступах, сервісних акаунтах, журналах і відповідальності. # Перевірити доступ до BI. Роль має відповідати реальній роботі людини. | Це обліковий запис людини або сервісу, через який виконується робота в системі. * менеджер Києва створює замовлення з Основного складу;
* комірник філії бачить тільки складський облік Львів;
* інтернет-магазин резервує товар на складі E-commerce;
* виробництво списує матеріали зі складу Виробництво. {| class="wikitable" style="width:100%;"

користувач системи здатна мати персональні конфігурація:
api_wms → складська платформа
== Що таке користувач системи K2 ERP ==
як приклад:
|-
| продажі та реалізація
| Менеджер, керівник продажів
| Клієнти, замовлення, рахунки
|-
| складський облік
| Комірник, керівник складу
| Надходження, переміщення, залишки
|-
| бухгалтерський обліковий облік
| Бухгалтер, провідний бухгалтер
| Каса, банк, податки, проводки
|-
| Інтеграції
| Сервісні користувачі
| API, обміни, технічні операції
|}

! Мета — не без зусиль дати людям доступ, а створити контрольовану, безпечну й зрозумілу модель роботи. як приклад:

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

! # Заблокувати старі доступи в BAS після запуску. ivanenko

як приклад:

Двофакторна автентифікація додає другий рівень захисту.

до однієї організації;
до кількох організацій;
до всіх організацій;
тільки до консолідованої аналітики. Це частина системи контролю доступу забезпечується через Головне. користувач системи K2 ERP — це не без зусиль логін; так само реалізовано відповідальності, безпеки, журналювання, бізнес-процесів і цифрової дисципліни підприємства. Матриця доступу — це таблиця, яка показує, хто що здатна робити. # Перевірити корпоративну пошту.

! !

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

Створити персональні облікові записи. buh

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

користувач системи і бізнес-процеси

|- | admin | Активний | Адміністратор | Створити окремий контрольований admin-доступ |- | manager | Спільний логін | Не переносити | Створити персональні логіни менеджерам |- | ivanenko | Активний | Менеджер продажів | Перенести як персонального користувача |- | old_buh | Звільнений | Немає | Не переносити, залишити в архіві історії |- | api_site | Сервісний | API сайту | Створити новий API-доступ з обмеженими правами |}

bi_export → BI

Приклад:

Описати організаційну структуру. Доступ

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

Добре:

Собівартість — чутлива інформаційні матеріали. Дата Під час переходу з BAS/1С у K2 ERP компанія-користувач повинна: |- | 15.05.2026 10:15 | ivanenko | Створено документ | Замовлення покупця №123 |- | 15.05.2026 10:20 | petrenko.buh | Проведено документ | Банківська виписка №45 |- | 15.05.2026 11:05 | admin | Змінено роль | користувач системи sklad01 |- | 15.05.2026 12:30 | api_site | API-запит | Створення замовлення WEB-100245 |}

user

! !

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

Користувачі можуть брати участь у бізнес-процесах. ! * клієнтів;

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

як приклад:

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

як приклад: ! ! Одна людина здатна мати один або кілька облікових записів, але в нормальній практиці краще мати один персональний обліковий запис для кожної людини. Користувачі не повинні довільно змінювати закриті періоди. * несанкціонований вхід;

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

користувач системи здатна експортувати: |- | Контрагенти | Створення | Перегляд | Зміна | Перегляд | Повний доступ |- | Замовлення | Створення і зміна | Перегляд | Перегляд | Перегляд | Повний доступ |- | Складські документи | Перегляд | Створення | Перегляд | Перегляд | Повний доступ |- | Каса | Немає | Немає | Повний доступ | Перегляд | Повний доступ |- | Зарплата | Немає | Немає | Обмежений доступ | Перегляд за дозволом | Повний доступ |- | Адміністрування | Немає | Немає | Немає | Немає | Повний доступ |}

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

! Правильний підхід. Користувачі K2 ERP мають налаштовуватися через ролі, групи, підрозділи, організації, склади, каси, права доступу й журналювання. Погано: |- | ivanenko | Менеджер продажів | Відділ продажів | Клієнти, замовлення, рахунки |- | petrenko | Бухгалтер | бухгалтерський обліковий облік | Банк, каса, проводки, формування звітів |- | sklad01 | Комірник | складський облік | Надходження, переміщення, інвентаризація |- | api_site | Сервісний користувач системи | Інтеграції | API для сайту |}

Краще:

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

Під час переходу з BAS або 1С у K2 ERP не потрібно переносити стару модель доступу “як виступає як”. Роль

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

</syntaxhighlight> 123

користувач системи і закриті періоди

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

api_site → сайт

користувач системи має отримувати тільки ті права, які потрібні для його роботи. Роль у K2 ERP Якщо всім видати повні права, платформа стає неконтрольованою.

Робочий стіл користувача здатна відображати:

Якщо працівник звільнився, але доступ залишився, виникають ризики:

Ризики:

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

як приклад, сайт має доступ до:

один пароль для всіх;
пароль `123456`;
пароль збігається з логіном;
пароль записаний на папірці біля монітора;
пароль адміністратора знають усі;
пароль сервісного користувача не змінюється роками;
звільнений працівник зберігає доступ. * менеджери;
комірники;
касири;
зовнішні користувачі;
сервісні API;
аудитори без відповідного дозволу. | Ні. ! Окремо варто відзначити через який виконується вхід, робота з довідниками, документами, звітами, бізнес-процесами, інтеграціями, BI-аналітикою і іншими функціями ERP-системи виступає ключовою рисою користувач системи K2 ERP. Повідомлення допомагають не втрачати важливі події. Правильна модель користувачів оптимізує встановити відповідальність. ! користувач системи

sklad.kyiv.01

усі менеджери працюють під одним логіном `manager`;
усі комірники працюють під одним логіном `sklad`;
бухгалтерський обліковий облік функціонує під одним логіном `buh`;
адміністраторський пароль знають усі. buh / пароль для всієї бухгалтерії

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

Права на експорт потрібно обмежувати й журналювати. Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій. * змінювати документи;

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

Правильно налаштовані користувачі дозволяють:

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

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

У старій BAS/1С часто буває хаос:

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

Каса за замовчуванням

Не кожен користувач системи ERP має бачити фінансову інформацію. api_crm → CRM

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

Заблокувати обліковий запис. # Документувати зміни в доступах. Приклади:

Принцип мінімально необхідного доступу

Приклад: користувач системи K2 ERP — це обліковий запис, який дає можливість людині або сервісу працювати із системою. # Навчити користувачів. | Так. Типові ролі

Логін	ivanenko
ПІБ	Іваненко Іван Іванович
Посада	Менеджер продажів
Підрозділ	Відділ продажів
складський облік за замовчуванням	базовий складський облік
Роль	Менеджер продажів
Статус	Активний

BI-доступ не повинен відкривати більше даних, ніж потрібно користувачу. * мова інтерфейсу;

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

Погано:

* менеджер бачить тільки своїх клієнтів;

комірник функціонує тільки зі своїм складом;
касир бачить тільки свою касу;
керівник бачить підлеглих;
філія бачить тільки свої документи;
директор бачить усю компанію. # Забрати активні ролі. * працівників;
клієнтів;
фізичних осіб;
пайовиків;
контактних осіб;
водіїв;
пацієнтів або інших осіб, якщо це галузеве рішення для бізнесу. * Сайт K2 ERP
Wiki K2 ERP
хмарна інфраструктура K2 ERP
Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку
Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ
Указ Президента України №601/2024
Указ Президента України №601/2024 на сайті Верховної Ради України
Telegram-канал K2 ERP
Група обговорення функціоналу та пропозицій
LinkedIn K2

критично про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. # Перевірити відкриті задачі. |-

Чому не можна використовувати спільні логіни?== Помилка: сервісний користувач системи має зайві права ==

Найгірший сценарій. компанія-користувач переходить у K2 ERP, але копіює стару модель BAS: спільні логіни, зайві права, активні звільнені користувачі, інтеграції під адміністратором і відсутність журналювання. як приклад, менеджеру потрібні замовлення і клієнти, а бухгалтеру — банк, каса й формування звітів. {| class="wikitable" style="width:100%;"

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

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

Контроль після запуску

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

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

</syntaxhighlight>

petrenko.buh

рахунків;
накладних;
актів;
касових ордерів;
податкових документів;
договорів;
етикеток;

ТТН. # Визначити критичні інформаційні дані.

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

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

[[Категорія:Автоматизація бізнесу]]

* прибрати спільні логіни;
* заблокувати старі доступи;
* створити нову рольову модель;
* обмежити зайві права;
* захистити персональні й фінансові інформаційні дані;
* замінити старі сервісні акаунти;
* перевести інтеграції на контрольований API;
* вести журнал дій;
* не залишати BAS активною робочою системою. # Описати ролі. # Перепризначити документи.== Адміністратор K2 ERP ==

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

== Помилка: усі адміністратори ==

Обліковий запис має бути унікальним. Статус
З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], конфігурація користувачів у [[K2 ERP]] має бути частиною ширшої стратегії переходу на українське програмне забезпечення (ПЗ), цифрову незалежність і сучасну [[ERP]]-архітектуру.[[Категорія:Персональні дані]]
! |-
| Що перевірити при міграції з BAS? Аудитор здатна бачити:
{| class="wikitable" style="width:100%;"
== Етапи конфігурація користувачів у K2 ERP ==
Для критичних ролей бажано використовувати посилений контроль входу. * створювати користувачів;
* блокувати користувачів;
* змінювати ролі;
* налаштовувати доступи;
* керувати довідниками;
* налаштовувати інтеграції;
* переглядати журнали;
* виконувати службові операції;
* допомагати користувачам;
* контролювати технічні конфігурація. # Увімкнути журналювання важливих дій. * вхід у систему;
* вихід із системи;
* створення документа;
* зміну документа;
* проведення документа;
* скасування проведення;
* зміну довідника;
* зміну ціни;
* зміну прав;
* запуск обробки;
* експорт даних;
* помилки;
* API-запити;
* спроби доступу без прав. як приклад:
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
== Аудиторський доступ ==
{{SEO
|title=Користувач K2 ERP — обліковий запис, ролі, права доступу, групи, безпека і міграція з BAS
|description=Користувач K2 ERP: що це таке, як налаштовуються облікові записи, ролі, права доступу, профілі, групи, підрозділи, сервісні користувачі, журналювання, безпека, типові помилки і міграція користувачів з BAS та 1С у K2 ERP.
|keywords=користувач K2 ERP, користувач ERP, користувач BAS, користувач 1С, права доступу K2 ERP, ролі K2 ERP, групи користувачів K2 ERP, профіль користувача, обліковий запис ERP, сервісний користувач, адміністратор K2 ERP, журналювання K2 ERP, міграція користувачів з BAS, міграція користувачів з 1С, заміна BAS, заміна 1С, українська ERP, санкції BAS, санкції 1С, цифрова незалежність
|image=https://erp.kyiv.ua
}}
[[Категорія:Міграція з BAS]]
Це зменшує кількість помилок при введенні документів. Журналювання потрібне для безпеки, аудиту й розслідування помилок. користувач системи у BAS

* бухгалтерський обліковий облік;
* продажі та реалізація;
* закупівельна діяльність;
* складський облік;
* Каса;
* Логістика;
* Виробництво;
* Керівництво;
* Адміністратори;
* Інтеграції;
* Аудитори. '''Сервісний користувач системи''' — це технічний обліковий запис для інтеграцій або автоматичних процесів. Пароль має бути достатньо складним і персональним. Підрозділ
== користувач системи і собівартість ==
== Приклади ролей ==
Для них потрібно вказувати:
== Мова і локальні конфігурація ==
== Активний і заблокований користувач системи ==
Це небезпечно. Правильний порядок:

{| class="wikitable" style="width:100%;"

! Добрі практики:
|-
| Створення замовлення
| Менеджер
| Вводить клієнта і товари
|-
| Перевірка боргу
| Бухгалтер
| Перевіряє оплату або ліміт
|-
| Резерв
| складський облік
| Резервує товар
|-
| Відвантаження
| Комірник
| Підтверджує відвантаження
|-
| Контроль
| Керівник
| Переглядає звіт
|}

admin

Краще створювати окремого сервісного користувача для кожної інтеграції. # Перевірити API-ключі, якщо були. Об’єкт / Роль

== Як не треба робити ==

* випадково змінити довідники;
* видалити інформаційні дані;
* змінити закриті документи;
* побачити зарплату;
* змінити права інших користувачів;
* запустити небезпечну обробку;
* експортувати конфіденційні інформаційні дані. # Описати права доступу. Часто краще заблокувати, щоб зберегти історію дій.== Див. так само ==

Журнал здатна фіксувати:

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

== Як правильно налаштовувати користувачів K2 ERP ==
== користувач системи після звільнення працівника ==
Приклад:

! |-
| Що визначає роль користувача? * ПІБ;
* посаду;
* підрозділ;
* email;
* телефон;
* мову;
* часовий пояс;
* організацію;
* складський облік за замовчуванням;
* касу за замовчуванням;
* роль;
* конфігурація інтерфейсу;
* підпис;
* відповідального керівника. API-доступ має бути пов’язаний із конкретним сервісним користувачем. # Налаштувати підрозділи, склади, каси й організації. # Створити користувачів. # Призначити ролі. Об’єкт
Приклад:

== Тимчасові користувачі ==
[[Категорія:K2]]
!</div>

[[Категорія:Права доступу]]

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

До них можуть належати:

* каса магазину;
* каса офісу;
* валютна каса;
* каса філії;
* каса кур’єра;
* каса ресторану. Деякі користувачі можуть мати права на друк документів. # Визначити сервісних користувачів. Адміністратор має розширені права. Комірник

== користувач системи і BI ==

* хто змінив ціну;
* хто списав товар;
* хто провів касову операцію;
* хто видалив документ;
* хто відкрив зарплатний звіт;
* хто змінив реквізити контрагента;
* хто запустив імпорт;
* хто затвердив платіж. Об’єкт

Для складу критично розділяти доступ. У результаті нова ERP успадковує старі ризики. |-
| Що робити зі звільненим користувачем? # Періодично переглядати права. |-
| Менеджер продажів
| Створення клієнтів, замовлень, рахунків, перегляд статусів
|-
| Комірник
| Приймання, переміщення, списання, інвентаризація
|-
| Бухгалтер
| Каса, банк, проводки, податкові документи, формування звітів
|-
| Касир
| Касові операції, оплати, повернення
|-
| Закупівельник
| Постачальники, замовлення постачальникам, надходження
|-
| Логіст
| Доставка, маршрути, рейси, статуси відвантажень
|-
| Керівник
| Звіти, [[BI]], контроль KPI
|-
| Адміністратор
| конфігурація, користувачі, ролі, довідники, інтеграції
|}

Приклад:

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

== Чому не можна використовувати адміністратора для інтеграцій ==

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

! # Провести тестування. Правильний підхід:

Погані підходи:

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

<syntaxhighlight lang="text">

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

{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
! Якщо в системі кілька юридичних осіб, користувач системи здатна мати доступ:

! |-
| Бізнес-користувач
| Працівник, який виконує операції
| Менеджер, бухгалтер, комірник
|-
| Керівник
| користувач системи для контролю й аналітики
| Директор, фінансовий директор, керівник складу
|-
| Адміністратор
| користувач системи для налаштувань системи
| ERP-адміністратор
|-
| Сервісний користувач системи
| Технічний акаунт для інтеграцій
| api_site, api_wms, bi_export
|-
| Аудитор
| користувач системи для перегляду й перевірки
| Внутрішній або зовнішній аудитор
|}

користувач системи здатна отримувати повідомлення:

Можливі способи:

менеджер продажів;
бухгалтер;
провідний бухгалтер;
комірник;
касир;
закупівельник;
логіст;
кадровик;
керівник;
адміністратор;
інтегратор;
аудитор. Для кожної інтеграції краще створювати окремого користувача з обмеженими правами. У K2 ERP можна виділити кілька типів користувачів. Призначення

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

manager / пароль для всіх менеджерів

список користувачів;
активних користувачів;
заблокованих користувачів;
адміністраторів;
сервісних користувачів;
користувачів інтеграцій;
ролі;
групи;
фактичні обов’язки;
підрозділи;
права на звіти;
права на обробки;
права на закриті періоди. # Заблокувати старі BAS-доступи після запуску. ! * хто створив документ;
хто змінив довідник;
хто провів операцію;
хто затвердив заявку;
хто переглянув звіт;
хто змінив ціну;
хто списав товар;
хто відкрив фінансову інформацію;
хто запустив інтеграцію;
хто виконав адміністративну дію. |-

Чи можна інтеграції запускати під адміністратором? # Налаштувати організації. рішення для бізнесу

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

інтеграційні функції ERP здатна змінити зайві інформаційні дані;
складно зрозуміти джерело помилки;
неможливо розділити відповідальність;
при витоку пароля зловмисник отримує повний доступ;
журнал дій показує адміністратора, а не реальний сервіс;
неможливо обмежити API. Керівник

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

Він потрібен для:

Для касира або бухгалтера здатна бути налаштована каса за замовчуванням.

Чому не можна без зусиль скопіювати користувачів із BAS

Краще:

Користувачі при міграції з BAS або 1С

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

Її не завжди мають бачити:

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

Через користувачів платформа розуміє:

Менеджер Погана практика — підключати сайт, CRM або WMS під адміністратором. Значення