Перейти до вмісту

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

Матеріал з K2 ERP Wiki

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

!; !; Приклади:

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

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

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

Він має змогу:

[[Категорія:Реплікатор K2]]

* раз на місяць для критичних ролей;
* раз на квартал для всіх користувачів;
* після кадрових змін;
* після запуску нового модуля;
* після інциденту;
* перед аудитом;
* після міграції з BAS/1С.;== Що таке користувач системи K2 ERP ==
Логін: Bukhgalteria
Для паролів потрібні правила:
{| class="wikitable" style="width:100%;"
Погано, коли користувачі створюються вручну “по дзвінку”, а потім роками не переглядаються.; складський облік Київ

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

* ініціатор;
* погоджувач;
* виконавець;
* контролер;
* підписант;
* юрист;
* фінансист;
* директор;
* архіваріус.; !; Приклад
2FA не замінює ролі й права, але зменшує ризик входу сторонньої особи.; HR-користувачі можуть працювати з:
== Типові помилки з користувачами K2 ERP ==
|-
| Працівник
| Петренко Петро
|-
| Підрозділ
| Відділ закупівель
|-
| Роль
| Закупівельник
|-
| Організація
| ТОВ “організація”
|-
| Склади
| Центральний складський облік
|-
| Строк доступу
| Постійний
|}

Спільні користувачі — одна з найнебезпечніших помилок.; Архів BAS не повинен залишатися другою робочою системою.; * мінімальна довжина;
* складність;
* заборона простих паролів;
* заборона спільних паролів;
* періодична зміна, якщо це передбачено політикою;
* блокування після підозрілих спроб;
* заборона передачі паролів колегам;
* окремі паролі для сервісних користувачів;
* захист API-токенів.; На сторінках K2 ERP Wiki компонент користувачів і прав доступу описується як блок для користувачів, ролей, прав, обмежень доступу і безпеки даних.;== Див.; додатково ==

!; Працівник має змогу не мати доступу до ERP.;[[Категорія:Power BI]]

Приклади:

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

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

* фінансовий блок;
* бухгалтерський обліковий облік;
* продажі та реалізація;
* закупівельна діяльність;
* складський облік;
* CRM;
* WMS;
* виробництво;
* MRP;
* MES;
* HRM;
* зарплата;
* електронний документообіг;
* договори;
* HelpDesk;
* автотранспорт;
* агро;
* елеватор;
* BI;
* API;
* адміністрування.; |-
| Що найважливіше?; Персональний користувач системи + сильний пароль + 2FA для критичних ролей.; {| class="wikitable" style="width:100%;"
== Ролі користувачів ==
[[Категорія:Кібербезпека]]
!; |-
| API-користувач
| Окремий користувач системи для інтеграцій із мінімальними правами.; !; SSO особливо корисний для середніх і великих компаній.;<syntaxhighlight lang="text">

користувач системи має змогу бути не працівником.; користувач системи

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

* переведенні в інший підрозділ;
* зміні посади;
* розширенні обов’язків;
* завершенні проєкту;
* зміні структури компанії;
* відкритті нової філії;
* впровадженні нового модуля;
* виявленні зайвих прав.;<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

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

* технологами;
* майстрами;
* операторами;
* планувальниками;
* контролерами якості;
* начальниками змін;
* комірниками виробництва.; '''2FA''' або двофакторна автентифікація — це додатковий рівень захисту.; Останній вхід

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

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

</div>

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

== Коротко ==

* потрібно було оперативно запустити систему;
* не описали ролі;
* користувачі скаржилися, що “не бачать кнопку”;
* адміністратор не мав часу налаштовувати доступ;
* стару модель перенесли з 1С/BAS.;<syntaxhighlight lang="text">
== Користувачі і продажі та реалізація ==
|-
| Перегляд клієнтів
| Так
| Ні
| Частково
|-
| Створення замовлення
| Так
| Ні
| Ні
|-
| Відвантаження
| Ні
| Так
| Ні
|-
| Погодження платежу
| Ні
| Ні
| Так
|-
| Експорт фінансового звіту
| Ні
| Ні
| Так
|}

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

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

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

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

* користувачу не потрібно пам’ятати багато паролів;
* доступ централізовано керується ІТ;
* простіше блокувати звільнених працівників;
* легше впроваджувати політики паролів;
* можна підключити 2FA;
* зменшується ризик “забутих” логінів.;== Доступ до модулів ==
[[Категорія:Міграція з BAS]]
Ні.; Працівник — це кадрова одиниця.; :contentReference [oaicite:3]{index=3}

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

!; Указ Президента України №601/2024 ввів у дію рішення для бізнесу РНБО від 2 вересня 2024 року щодо сфера застосування, скасування та внесення змін до санкцій.; Це істотно для бухгалтерії, фінансів, зарплати, управлінської звітності й доступу до документів.;[[Категорія:1С]]

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

Фінансові інформаційні дані є собою чутливими.;== Доступ до звітів і BI ==

Приклад:

Логін: sklad

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

* хто створив токен;
* для якої інтеграції;
* які права має токен;
* коли створений;
* коли змінювався;
* де застосовується;
* хто відповідальний;
* як його відкликати;
* чи є собою журнал API-запитів.; Ні, це погана практика.; Держспецзв’язку веде офіційно затверджений перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:організація 8 і BAS ERP.; :contentReference [oaicite:0]{index=0}

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

!; Організація 3

У K2 ERP істотно не плутати поняття '''користувач системи''' і '''працівник'''.;[[Категорія:Користувачі ERP]]

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

<syntaxhighlight lang="text">

Зарплатні інформаційні дані потребують окремого захисту.; Етап
!; {| class="wikitable" style="width:100%;"

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

* чи всі користувачі можуть увійти;
* чи немає зайвих прав;
* чи працюють ролі;
* чи працюють погодження;
* чи коректно функціонує SSO;
* чи не залишились старі активні доступи;
* чи заблоковано тестові логіни;
* чи працюють API-користувачі;
* чи не бачить Power BI зайві інформаційні дані;
* чи записується audit log.; Це частина рольової моделі безпеки: користувач системи має ролі, групи, права, обмеження по організаціях, підрозділах, складах, документах, звітах, API, модулях і діях.; |}
class="wikitable" style="width:100%;"

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

2FA

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

У K2 ERP ролі потрібні не тільки для заборони доступу.; Статус

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

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

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

  • обмежені користувачі;
  • немає нових операцій;
  • немає активних інтеграцій;
  • немає регламентних завдань;
  • архівні користувачі окремо погоджені;
  • журнал доступу зберігається;
  • backup збережений;
  • дата переходу зафіксована.; Права доступу визначають, що користувач системи має змогу робити.; API-користувачі не мають “сидіти” в інтерфейсі як люди.; API-користувач
  1. Керівник або HR подає заявку.; Дія
  • картками працівників;
  • кадровими документами;
  • прийомом;
  • переведеннями;
  • звільненнями;
  • відпустками;
  • лікарняними;
  • табелями;
  • штатним розписом;
  • організаційною структурою;
  • заявками працівників.;
  • специфікацій;
  • виробничих замовлень;
  • MRP;
  • MES;
  • списання матеріалів;
  • випуску продукції;
  • браку;
  • НЗВ;
  • собівартості, якщо дозволено.;
  • перегляд;
  • створення;
  • редагування;
  • погодження;
  • проведення;
  • скасування;
  • видалення;
  • друк;
  • експорт;
  • імпорт;
  • адміністрування;
  • запуск інтеграцій;
  • перегляд audit log;
  • створення API-токенів.; !; Проблеми:

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

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

</syntaxhighlight>

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

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

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

Що таке користувач системи K2 ERP?; * менеджерів продажів;
  • комірників;
  • операторів;
  • зовнішніх користувачів;
  • частини керівників;
  • підрядників;
  • API-користувачів.; Організація 2
Бухгалтер 1 Так Ні Ні
центральний бухгалтер Так Так Так
Менеджер продажів Так Ні Ні
Фінансовий директор Так Так Так

Без цього інтеграції стають “чорним ящиком”.; :contentReference [oaicite:4]{index=4} !; !; Потрібно обмежувати доступ до:

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

Після переходу в K2 ERP стара BAS/1С-база має змогу залишатися архівом.; Менеджер → Керівник відділу → фінансовий блок → Директор → Архів

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

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

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

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

site_api_user має доступ тільки до створення замовлень і читання статусів.; користувач системи — це обліковий запис для входу в ERP.; !; * користувачі бачать зайву інформацію;

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

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

'''Роль''' — це набір прав, який визначає, що користувач системи має змогу робити в K2 ERP.; API функціонує під користувачем “Адміністратор”.; # Вказуються організації, склади або ЦФВ.; Користувача потрібно блокувати, якщо:

== Доступ до зарплати ==
<syntaxhighlight lang="text">
{| class="wikitable" style="width:100%;"

[[Категорія:Безпека ERP]]

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

Права на компонент не означають автономно повний доступ до всіх документів модуля.; Собівартість — комерційно чутлива відомості.; * створювати ліди;
* вести клієнтів;
* створювати угоди;
* створювати комерційні пропозиції;
* створювати замовлення;
* контролювати оплату;
* бачити своїх клієнтів;
* бачити свої продажі та реалізація;
* бачити маржу, якщо дозволено;
* погоджувати знижки;
* бачити дебіторку.; !; | Давати всім повні права, використовувати спільні логіни, не блокувати звільнених.; Саме через користувачів ERP визначає, хто має змогу бачити клієнтів, створювати документи, погоджувати платежі, працювати зі складом, змінювати ціни, бачити зарплату, експортувати звіти, запускати API або адмініструвати систему.; Значення

Пароль: 123456

* спільні логіни;
* старих користувачів;
* користувачів звільнених працівників;
* хаотичні повні права;
* тестових користувачів;
* старі паролі;
* небезпечні ролі;
* інтеграційних користувачів без відповідального;
* застарілі групи;
* доступ до архівних баз як робочий доступ.; # Вказується підрозділ.; Питання
|-
| Комірник Київ
| Так
| Ні
| Ні
|-
| Комірник Львів
| Ні
| Так
| Ні
|-
| Керівник логістики
| Так
| Так
| Так
|}

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

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

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

У K2 ERP користувач системи — це не без ускладнень логін і пароль.;[[Категорія:Права доступу]]

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

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

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

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

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

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

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

!; Призначення

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

!; |-
| При міграції з 1С/BAS
| Не копіювати хаос, а побудувати нову рольову модель.; Наслідки:

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

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

K2 ERP як інтегрована платформа об’єднує фінансовий блок, бухгалтерію, продажі та реалізація, складський облік, закупівельна діяльність, електронний документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі, з цієї причини журнал дій потрібен для контролю змін у багатьох пов’язаних процесах.; # Адміністратор створює користувача.; '''[[Реплікатор K2]]''' має змогу допомогти при підготовці міграції користувачів із 1С/BAS.; як ілюстрація, API-користувач для сайту або інтеграції з банком.; API-користувач — це спеціальний обліковий запис для інтеграції, як ілюстрація сайту, банку, WMS або Power BI.; користувач системи
== Зовнішні посилання ==
'''SSO''' або Single Sign-On — це єдиний вхід через корпоративну систему автентифікації.; Що означає

* хто створив користувача;
* хто змінив роль;
* хто заблокував користувача;
* хто видав доступ до зарплати;
* хто видав доступ до банку;
* хто створив API-токен;
* хто експортував звіт;
* хто змінив документ;
* хто погодив платіж;
* хто видалив файл;
* хто змінив фінансові реквізити.;[[Категорія:HRM]]
== Що не переносити з 1С/BAS ==
!; '''Головне.''' користувач системи K2 ERP — це не “людина, якій дали доступ до системи”, а керована облікова одиниця з ролями, правами, обмеженнями, відповідальністю, журналом дій і місцем у бізнес-процесах.; Краще один працівник — один користувач системи.; !; | Обліковий запис людини або сервісу для доступу до 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))
Обмеження можуть бути за:
HR-доступ має бути обмежений, бо кадрові інформаційні дані є собою персональними.; Роль

* працівник звільнився;
* користувач системи змінив посаду;
* доступ більше не потрібен;
* виявлено підозрілу активність;
* завершився договір із підрядником;
* завершився період аудиту;
* API-токен скомпрометовано;
* обліковий запис не застосовується.;== Обмеження доступу ==
Зміна ролі має бути погоджена й зафіксована.; # користувач системи отримує доступ.; !;<syntaxhighlight lang="text">

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

!;[[Категорія:Продажі]]

Потрібно проаналізувати:
Приклади ролей:
=== Що таке користувач системи K2 ERP? ===
Audit log показує, хто і коли створив, змінив, погодив, видалив або експортував інформаційні дані.; користувач системи

Не варто переносити:
Права потрібно регулярно переглядати.; '''Групи користувачів''' допомагають керувати доступом не по одному користувачу, а по групах.; Організація 1
== Спільні користувачі ==
== Блокування користувача ==
API-користувач має мати:
API-токени потрібно обліковувати.; Поняття

{{DISPLAYTITLE:Користувачі K2 ERP}}

'''Проста аналогія.''' ERP — це офіс із багатьма кімнатами.;== Помилка: API-токени не контролюються ==

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

[[Категорія:Ролі K2 ERP]]

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

Приклад:

* integration_service;
* powerbi_export;
* bank_sync;
* wms_sync;
* mail_sender;
* backup_report_user;
* monitoring_user.; Права

Потрібно обмежувати:
У виробництві користувачі можуть бути:
'''Користувачі K2 ERP''' — це основа безпечної роботи системи.;[[Категорія:Міграція даних]]

[[Категорія:API-користувач]]

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

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

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

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

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

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

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

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

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

K2 ERP є собою модульною системою.; Типовий бізнес-процес:

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

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

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

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

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

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

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

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

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

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

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

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

</syntaxhighlight>

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

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

; !; Поле
  • нарахування;
  • утримання;
  • податки;
  • банківські реквізити працівників;
  • розрахункові листки;
  • відомості на виплату;
  • кадрові документи;
  • лікарняні;
  • відпустки;
  • персональні інформаційні дані;
  • зарплатні звіти.; # Вказуються потрібні модулі.; :contentReference [oaicite:2]{index=2}
  • фінансових звітів;
  • зарплатних звітів;
  • управлінського P&L;
  • ДДС;
  • собівартості;
  • маржі;
  • клієнтської бази;
  • дебіторки;
  • кредиторки;
  • Power BI-дашбордів;
  • експортів у Excel.; Дія
ivanenko.i Менеджер продажів Активний 15.05.2026 Немає
petrenko.p Бухгалтер Активний 14.05.2026 Доступ до банку
old.user Менеджер Активний 01.10.2024 Неактивний користувач системи
admin2 Адміністратор Активний 15.05.2026 Повні права

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

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

Роль потрібно змінювати при: Audit log має відповідати на питання: Картка користувача K2 ERP має змогу містити: Для них потрібно:

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

{{SEO


Висновок

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

  • які дашборди доступні;
  • які таблиці доступні;
  • чи видно зарплату;
  • чи видно собівартість;
  • чи видно фінансові інформаційні дані;
  • чи видно всі організації;
  • чи є собою фільтри по підрозділах;
  • чи можна експортувати інформаційні дані;
  • чи є собою row-level security.; Ролі визначають, у які кімнати він має змогу заходити, які документи брати, що підписувати, що змінювати, а що тільки переглядати.; Користувачі Power BI можуть мати окремі права.; Краще:

Приклади:

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

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

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

!; користувач системи — це співробітник із перепусткою.; !; # Через певний час доступ перевіряється.; це облікові записи людей, сервісів або інтеграцій, які мають доступ до K2 ERP; додатково реалізовано перегляду довідників, погодження заявок, роботи зі складом, продажами, фінансами, виробництвом, HRM, зарплатою, BI, API, звітами, договорами, файлами та іншими модулями системи виступає ключовою рисою виконання бізнес-операцій: створення документів забезпечується через Користувачі K2 ERP.; Але права краще переглядати і перебудовувати, а не копіювати “один в один”.;</syntaxhighlight>

</syntaxhighlight> Це типова помилка після впровадження.; {| class="wikitable" style="width:100%;"

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

  • організацією;
  • підрозділом;
  • складом;
  • філією;
  • проєктом;
  • ЦФВ;
  • видом документа;
  • статусом документа;
  • клієнтом;
  • менеджером;
  • видом ціни;
  • звітом;
  • дашбордом;
  • модулем;
  • API-методом.; * сайт передає замовлення в ERP;
  • банк передає виписки;
  • WMS отримує складські задача;
  • CRM передає ліди;
  • Power BI отримує інформаційні дані;
  • мобільний застосунок створює заявки;
  • маркетплейс передає продажі та реалізація.; При переході з або BAS у K2 ERP користувачів потрібно не копіювати механічно, а переосмислити: прибрати спільні логіни, заблокувати старих користувачів, створити нові ролі, обмежити доступ до зарплати, банку, собівартості, Power BI та API, а стару BAS-базу залишити тільки як захищений архів для читання.; * менеджер продажів бачить оплату свого клієнта;
  • фінансист бачить платіжний календар;
  • директор бачить загальний ДДС;
  • комірник не бачить фінансові звіти.;
  • неможливо визначити, хто змінив документ;
  • неможливо провести аудит;
  • складно відкликати доступ;
  • пароль передається між людьми;
  • права стають надмірними;
  • немає персональної відповідальності.; | Мінімальні права, персональні логіни, audit log, регулярний перегляд доступів.;== API-користувачі ==
  • комірник;
  • старший комірник;
  • керівник складу;
  • оператор WMS;
  • інвентаризаційна комісія;
  • логіст.; Приклад:
  • ПІБ користувача;
  • email;
  • підрозділ;
  • посаду;
  • активність;
  • роль;
  • профіль доступу;
  • організації;
  • склади;
  • групи;
  • історію останнього входу, якщо доступна;
  • зв’язок із працівником;
  • відповідальність за документи;
  • список звітів;
  • список інтеграційних користувачів.;=== Чим користувач системи відрізняється від працівника? ===

переважні аспекти:

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

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

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

!; :contentReference [oaicite:1]{index=1} |- | Працівник | Людина як кадрова одиниця | Іваненко Іван, менеджер продажів |- | користувач системи | Обліковий запис для входу в ERP | ivanenko.i |- | Роль | Набір прав користувача | Менеджер продажів |- | Група | Об’єднання користувачів або ролей | Відділ продажів Київ |}

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

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

SSO

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

Краще: Приклад: </syntaxhighlight> Зовнішні користувачі можуть бути:

; Типові дії:

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

  • директор;
  • фінансовий директор;
  • центральний бухгалтер;
  • бухгалтер;
  • менеджер продажів;
  • керівник продажів;
  • закупівельник;
  • керівник закупівель;
  • комірник;
  • керівник складу;
  • HR;
  • зарплатний бухгалтер;
  • виробничий майстер;
  • технолог;
  • диспетчер;
  • юрист;
  • аналітик;
  • адміністратор ERP;
  • API-користувач.; Можна перенести або використати як джерело:
  • неактивних користувачів;
  • колишніх працівників;
  • спільні логіни;
  • користувачів із повними правами;
  • доступ до зарплати;
  • доступ до банку;
  • доступ до API;
  • доступ зовнішніх консультантів;
  • старі токени;
  • зайві групи.; !; # Дія записується в audit log.;
!; Значення

'''Сильна ERP починається не з документів, а з правильно налаштованих користувачів.''' Якщо користувачі мають зайві права, спільні логіни або неконтрольовані API-токени, навіть найкраща ERP стає ризиковою.;== Створення нового користувача ==
Потрібно знати:
1С історично є собою російською програмною екосистемою, а BAS пов’язаний із цією технологічною спадщиною.; # Вказується посада.;[[Категорія:Audit log]]

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

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

як ілюстрація, комірник складу Київ не повинен бачити й редагувати документи складу Львів, якщо це не потрібно для його роботи.; Power BI не повинен обходити права ERP.; Він має мати мінімальні права і окремий журнал запитів.; API-користувач — це обліковий запис для інтеграції, а не для людини.; # Вказується працівник.; Приклад: