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

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

! * окремий логін;

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

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

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

технологами;
майстрами;
операторами;
планувальниками;
контролерами якості;
начальниками змін;
комірниками виробництва. Audit log показує, хто і коли створив, змінив, погодив, видалив або експортував інформаційні дані. ! Він здатна використовуватися для:

Окрім ролей, потрібні обмеження.== Доступ до модулів ==

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

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

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

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

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

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

* організацією;
* підрозділом;
* складом;
* філією;
* проєктом;
* ЦФВ;
* видом документа;
* статусом документа;
* клієнтом;
* менеджером;
* видом ціни;
* звітом;
* дашбордом;
* модулем;
* API-методом. {| class="wikitable" style="width:100%;"
[[Категорія:Закупівлі]]
== Помилка: не блокують користувачів після звільнення ==
Групи зручні, коли у компанії багато користувачів або кілька філій. # Дія записується в audit log. ! ! Що означає
|-
| ivanenko.i
| Менеджер продажів
| Активний
| 15.05.2026
| Немає
|-
| petrenko.p
| Бухгалтер
| Активний
| 14.05.2026
| Доступ до банку
|-
| old.user
| Менеджер
| Активний
| 01.10.2024
| Неактивний користувач системи
|-
| admin2
| Адміністратор
| Активний
| 15.05.2026
| Повні права
|}

Права на компонент не означають автоматизовано повний доступ до всіх документів модуля. Це критично для бухгалтерії, фінансів, зарплати, управлінської звітності й доступу до документів.<syntaxhighlight lang="text">

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

# Керівник або HR подає заявку. | Мінімальні права, персональні логіни, audit log, регулярний перегляд доступів. ! Що означає
'''[[Реплікатор K2]]''' здатна допомогти при підготовці міграції користувачів із 1С/BAS. Пароль знають усі бухгалтери. Указ Президента України №601/2024 ввів у дію рішення для бізнесу РНБО від 2 вересня 2024 року щодо сценарії використання, скасування та внесення змін до санкцій. користувач системи
Приклади груп:
[[Категорія:Модулі K2 ERP]]
Вона особливо важлива для:
|-
| Комірник Київ
| Так
| Ні
| Ні
|-
| Комірник Львів
| Ні
| Так
| Ні
|-
| Керівник логістики
| Так
| Так
| Так
|}

! | Обліковий запис людини або сервісу для доступу до ERP. |-
| Основні елементи
| Логін, email, працівник, ролі, групи, права, обмеження, статус. користувач системи

* які дашборди доступні;
* які таблиці доступні;
* чи видно зарплату;
* чи видно собівартість;
* чи видно фінансові інформаційні дані;
* чи видно всі організації;
* чи виступає як фільтри по підрозділах;
* чи можна експортувати інформаційні дані;
* чи виступає як row-level security. Зарплатний бухгалтер здатна бачити зарплату, але звичайний адміністратор ERP не обов’язково має бачити зарплатні суми.[[Категорія:Користувачі K2 ERP]]

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

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

</syntaxhighlight> ! ! Один працівник здатна мати користувача, але не кожен працівник обов’язково має доступ до ERP. Приклад ролей: Потрібно обмежувати доступ до: Менеджер → Керівник відділу → фінансовий блок → Директор → Архів

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

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

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

Потрібно знати: ! * перегляд;

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

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

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

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

|- | Бухгалтер 1 | Так | Ні | Ні |- | провідний бухгалтер | Так | Так | Так |- | Менеджер продажів | Так | Ні | Ні |- | Фінансовий директор | Так | Так | Так |}

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

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

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

Краще:

! Хто це

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

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

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

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

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

користувач системи K2 ERP — це обліковий запис, через який людина або сервіс отримує доступ до ERP-системи.== Блокування користувача == У фінансах користувачі можуть: HR-користувачі можуть працювати з: Фінансові інформаційні дані виступає як чутливими. !

менеджерів продажів;
комірників;
операторів;
зовнішніх користувачів;
частини керівників;
підрядників;
API-користувачів.SEO title: Користувачі K2 ERP — облікові записи, ролі, права доступу, групи, audit log, SSO, API-користувачі і міграція з 1С/BAS

SEO keywords: користувачі K2 ERP, користувач ERP, права доступу K2 ERP, ролі K2 ERP, групи користувачів ERP, audit log ERP, API користувач ERP, SSO ERP, міграція користувачів з 1С, міграція користувачів з BAS, K2 ERP

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}

* створювати користувачів;
* блокувати користувачів;
* призначати ролі;
* налаштовувати групи;
* перевіряти журнал дій;
* керувати API-користувачами;
* налаштовувати модулі;
* контролювати інтеграції;
* перевіряти помилки;
* готувати звіти з доступу. У K2 ERP користувач системи — це не без зусиль логін і пароль.<syntaxhighlight lang="text">

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

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

Приклад:

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

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

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

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

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

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

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

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

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

Типові дії:

:contentReference [oaicite:0]{index=0} Зарплатні інформаційні дані потребують окремого захисту. Статус адміністраторів; фінансистів; бухгалтерів; зарплатних бухгалтерів; директорів; користувачів із доступом до банку; користувачів із доступом до API; зовнішніх консультантів; віддалених користувачів. * хто створив користувача; хто змінив роль; хто заблокував користувача; хто видав доступ до зарплати; хто видав доступ до банку; хто створив API-токен; хто експортував звіт; хто змінив документ; хто погодив платіж; хто видалив файл; хто змінив фінансові реквізити. # Вказується посада.== Зовнішні користувачі == API-користувач — це обліковий запис для інтеграції, а не для людини. Користувачі Power BI можуть мати окремі права. :contentReference [oaicite:3]{index=3} банківські рахунки; каси; платіжний календар; заявки на оплату; бюджети; ДДС; P&L; управлінський баланс; фінансові звіти; дебіторську заборгованість; кредиторську заборгованість; фінансові ліміти; банківські реквізити. ! користувач системи — це співробітник із перепусткою. * раз на місяць для критичних ролей; раз на квартал для всіх користувачів; після кадрових змін; після запуску нового модуля; після інциденту; перед аудитом; після міграції з BAS/1С. Проблеми: користувач системи здатна бути не працівником. \|-	Працівник	Петренко Петро
Підрозділ	Відділ закупівель
Роль	Закупівельник
Організація	ТОВ “компанія-користувач”
Склади	Центральний складський облік
Строк доступу	Постійний

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

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

Погано: </syntaxhighlight> Логін: sklad

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

Чого не можна робити? Наслідок

Приклад

! При переході з [[1С]] або [[BAS]] не варто механічно переносити всіх користувачів. * спільні логіни;
* старих користувачів;
* користувачів звільнених працівників;
* хаотичні повні права;
* тестових користувачів;
* старі паролі;
* небезпечні ролі;
* інтеграційних користувачів без відповідального;
* застарілі групи;
* доступ до архівних баз як робочий доступ.== Коротко ==

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

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

* доступ тільки для читання;
* обмежені користувачі;
* немає нових операцій;
* немає активних інтеграцій;
* немає регламентних завдань;
* архівні користувачі окремо погоджені;
* журнал доступу зберігається;
* backup збережений;
* дата переходу зафіксована. Приклад:
! * логін;
* ПІБ;
* email;
* телефон;
* статус;
* працівника, якщо пов’язаний;
* підрозділ;
* посаду;
* організацію;
* групу користувачів;
* ролі;
* мову інтерфейсу;
* часовий пояс;
* спосіб автентифікації;
* дату створення;
* дату останнього входу;
* дату блокування;
* відповідального адміністратора;
* коментар;
* ознаку API-користувача;
* ознаку зовнішнього користувача. {| class="wikitable" style="width:100%;"

Після переходу в K2 ERP стара BAS/1С-база здатна залишатися архівом. {| class="wikitable" style="width:100%;"
! * активних користувачів;
* неактивних користувачів;
* колишніх працівників;
* спільні логіни;
* користувачів із повними правами;
* ролі;
* профілі доступу;
* організації;
* підрозділи;
* склади;
* доступ до зарплати;
* доступ до банку;
* доступ до собівартості;
* зовнішні обробки;
* інтеграційних користувачів;
* користувачів Power BI;
* адміністраторів. Життєвий цикл користувача:

* обмежений строк доступу;
* мінімальні права;
* доступ тільки до потрібних модулів;
* заборона зайвого експорту;
* окремий audit log;
* погодження відповідального;
* блокування після завершення робіт. # Адміністратор створює користувача. * неактивних користувачів;
* колишніх працівників;
* спільні логіни;
* користувачів із повними правами;
* доступ до зарплати;
* доступ до банку;
* доступ до API;
* доступ зовнішніх консультантів;
* старі токени;
* зайві групи. {| class="wikitable" style="width:100%;"

[[Категорія:Цифрова незалежність України]]

Приклад:

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

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

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

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

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

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

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

* [[K2 ERP]]
* [[Модулі K2 ERP]]
* [[Права доступу в ERP]]
* [[Ролі K2 ERP]]
* [[Аудит дій]]
* [[Audit log]]
* [[API]]
* [[Інтеграція через JSON]]
* [[Power BI]]
* [[BI система]]
* [[ERP на власному сервері]]
* [[Хмарна ERP]]
* [[K2 Cloud ERP]]
* [[Реплікатор K2]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[Заміна BAS]]
* [[BAS]]
* [[BAF]]
* [[1С]]
* [[Права доступу 1С]]
* [[Роль 1С]]
* [[Інформаційна база BAS]]
* [[Клієнт BAS]]
* [[Тонкий клієнт BAS]]
* [[BAS ERP]]
* [[BAS Бухгалтерія]]
* [[Українське програмне забезпечення]]
* [[Цифрова незалежність]]

! Він здатна:

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

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

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

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

<syntaxhighlight lang="text">

K2 ERP як комплексна ERP платформа об’єднує фінансовий блок, бухгалтерію, продажі та реалізація, складський облік, закупівельна діяльність, електронний документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі, тому журнал дій потрібен для контролю змін у багатьох пов’язаних процесах. * директор;
* фінансовий директор;
* провідний бухгалтер;
* бухгалтер;
* менеджер продажів;
* керівник продажів;
* закупівельник;
* керівник закупівель;
* комірник;
* керівник складу;
* HR;
* зарплатний бухгалтер;
* виробничий майстер;
* технолог;
* диспетчер;
* юрист;
* аналітик;
* адміністратор ERP;
* API-користувач. Приклад маршруту:

Типовий бізнес-процес:

* integration_service;
* powerbi_export;
* bank_sync;
* wms_sync;
* mail_sender;
* backup_report_user;
* monitoring_user. |-
| Що таке користувач системи K2 ERP? ! Працівник здатна не мати доступу до ERP. Поле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API-користувачі не мають “сидіти” в інтерфейсі як люди. Це основа безпеки, контролю і розслідування помилок. Кожен користувач системи має мати тільки той доступ, який потрібен для виконання його роботи. Етап

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

1С історично виступає як російською програмною екосистемою, а BAS пов’язаний із цією технологічною спадщиною. |-

При міграції з 1С/BAS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SSO

* нарахування;

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

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

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

2FA або двофакторна автентифікація — це додатковий рівень захисту. # Вказуються організації, склади або ЦФВ. користувач системи здатна мати доступ до окремих модулів:

site_api_user

Замовлення із сайту

Створення замовлень, читання статусів

powerbi_export

BI-аналітика

Читання погоджених наборів даних

bank_sync

Банківська інтеграційні функції ERP

Імпорт виписок, статуси платежів

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

! 2FA не замінює ролі й права, але зменшує ризик входу сторонньої особи. Відповідь
== Користувачі і API ==
'''Користувачі K2 ERP''' — це основа безпечної роботи системи. Дія

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

Працівник — це кадрова одиниця.== Типові помилки з користувачами K2 ERP ==

* фінансових звітів;
* зарплатних звітів;
* управлінського P&L;
* ДДС;
* собівартості;
* маржі;
* клієнтської бази;
* дебіторки;
* кредиторки;
* Power BI-дашбордів;
* експортів у Excel. :contentReference [oaicite:1]{index=1}

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

Права потрібно регулярно переглядати.== Помилка: усім дали повні права ==

site_api_user має доступ тільки до створення замовлень і читання статусів.=== Чи потрібно переносити всіх користувачів із 1С/BAS? ===

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

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

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

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

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

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

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

Приклад:

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

API-токени потрібно обліковувати. * специфікацій;

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

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

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

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

Логін

ivanenko.i

ПІБ

Іваненко Іван Іванович

Email

ivanenko@example.com

Підрозділ

Відділ продажів

Роль

Менеджер продажів

Статус

Активний

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

! Приклад:

як приклад, виробничий працівник здатна бути в кадровому обліку, але не мати ERP-логіна. :contentReference [oaicite:4]{index=4}

2FA

* сайт передає замовлення в ERP;
* банк передає виписки;
* WMS отримує складські задача;
* CRM передає ліди;
* Power BI отримує інформаційні дані;
* мобільний застосунок створює заявки;
* маркетплейс передає продажі та реалізація. {| class="wikitable" style="width:100%;"
!== Що переносити з 1С/BAS ==

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

* картками працівників;
* кадровими документами;
* прийомом;
* переведеннями;
* звільненнями;
* відпустками;
* лікарняними;
* табелями;
* штатним розписом;
* організаційною структурою;
* заявками працівників. Це частина рольової моделі безпеки: користувач системи має ролі, групи, права, обмеження по організаціях, підрозділах, складах, документах, звітах, API, модулях і діях. |-
| Що найважливіше? Не варто переносити:

Приклад:
! Саме через користувачів ERP визначає, хто здатна бачити клієнтів, створювати документи, погоджувати платежі, працювати зі складом, змінювати ціни, бачити зарплату, експортувати звіти, запускати API або адмініструвати систему. Краще один працівник — один користувач системи.{{DISPLAYTITLE:Користувачі K2 ERP}}
== Користувачі і продажі та реалізація ==
</div>
== Основні реквізити користувача ==
== Типи користувачів K2 ERP ==
|-
| Перегляд клієнтів
| Так
| Ні
| Частково
|-
| Створення замовлення
| Так
| Ні
| Ні
|-
| Відвантаження
| Ні
| Так
| Ні
|-
| Погодження платежу
| Ні
| Ні
| Так
|-
| Експорт фінансового звіту
| Ні
| Ні
| Так
|}

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

Приклади:

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

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

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

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

! На сторінках K2 ERP Wiki компонент користувачів і прав доступу описується як блок для користувачів, ролей, прав, обмежень доступу і безпеки даних.[[Категорія:Зарплата]]

== Користувачі і архів BAS ==
Зовнішні користувачі можуть бути:
Пароль: 123456

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

! Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:компанія-користувач 8 і BAS ERP. користувач системи — це обліковий запис для входу в ERP.[[Категорія:K2 ERP]]

* створити окремий обліковий запис;
* обмежити доступ тільки потрібними методами;
* вести журнал запитів;
* мати відповідального;
* контролювати токени;
* блокувати після завершення інтеграції;
* не використовувати права адміністратора. ! K2 ERP виступає як модульною системою. ([Держспецзв’язку](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))

[[Категорія:Аудит дій]]
! Поняття

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

У матеріалах K2 ERP зазначається, що під час міграції можуть використовуватися інформаційні дані про користувачів і ролі 1С/BAS: користувачі, профілі доступу, підрозділи, склади, організації, дозволені документи, права на звіти, аудит доступу, Power BI, API та перехід на сучасну ERP. * створювати ліди;
* вести клієнтів;
* створювати угоди;
* створювати комерційні пропозиції;
* створювати замовлення;
* контролювати оплату;
* бачити своїх клієнтів;
* бачити свої продажі та реалізація;
* бачити маржу, якщо дозволено;
* погоджувати знижки;
* бачити дебіторку. Аналог у K2 ERP
Сервісні користувачі потрібні для фонових задач і системних процесів.== Користувачі і виробництво ==

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

</div>

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

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

Приклад:
Без цього інтеграції стають “чорним ящиком”. Вони створюють порядок: кожен користувач системи має свою ділянку, рівень видимості, права дії та відповідальність у процесі. Потрібно перенести тільки актуальних користувачів, переглянути ролі, прибрати старі логіни, спільні облікові записи, звільнених працівників і зайві повні права. # Вказуються ролі. Права доступу в ERP визначають, хто здатна переглядати, створювати, редагувати, погоджувати, проводити, видаляти, експортувати або адмініструвати інформаційні дані, документи, довідники, звіти, дашборди, модулі та інтеграції.[[Категорія:Продажі]]

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

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

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

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

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

Приклади: Корисний звіт: Блокування краще, ніж видалення, бо історія продукту дій користувача має залишатися в audit log. складський облік Одеса Обмеження можуть бути за: конкурентні переваги: Power BI не повинен ставати способом обійти ERP-права.