Роль BAS

інтеграційні функції ERP із сайтом функціонує під api_site

провідний бухгалтер здатна мати ширші права, ніж звичайний бухгалтер. Організація

! Під час переходу в K2 ERP ролі потрібно аналізувати окремо від даних.== Роль комірника ==

admin застосовується для бухгалтером, сайтом, CRM і програмістом

Роль головного бухгалтера

|-

| Що таке роль BAS?

Роль здатна дозволяти або забороняти доступ до:

* прибутковими касовими ордерами;
* видатковими касовими ордерами;
* оплатами;
* поверненнями;
* касовими змінами;
* касовою книгою;
* фіскальними операціями, якщо вони виступає як;
* звітами касира. {| class="wikitable" style="width:100%;"
Але аудитор не повинен:
Порядок:

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

[[Категорія:BI]]
! Користувачі
== Роль і файловий режим BAS ==
Ролі виступає як частиною [[Конфігурація BAS|конфігурації BAS]] або механізмів доступу конкретного рішення для бізнесу. ! # Створити ролі. Добре:

</div>
{| class="wikitable" style="width:100%;"
== Аудит ролей BAS ==
Один користувач системи здатна мати кілька ролей. ! # Описати бізнес-функції. Роль сама по собі не функціонує без користувача.[[Категорія:Користувач 1С]]

== Права на закриті періоди ==

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

Погано:

* документи;
* довідники;
* проводки;
* звіти;
* журнал реєстрації;
* історичні інформаційні дані.[[Категорія:Конфігурація BAS]]

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

* користувачів;
* сервісних акаунтів;
* регламентних завдань;
* web-сервісів;
* фонових обробок;
* інтеграцій;
* адміністрування. ! * створення;
* зміна;
* проведення;
* скасування проведення;
* помітка на видалення;
* друк;
* перегляд;
* затвердження;
* заборона зміни після проведення. * профіль “Менеджер продажів”;
* профіль “Комірник”;
* профіль “Бухгалтер по банку”;
* профіль “Касир”;
* профіль “Керівник”;
* профіль “Адміністратор”;
* профіль “API сайту”;
* профіль “BI-експорт”.== Роль бухгалтера ==

Зв’язок такий:

Помилка: роль “Повні права” для всіх

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

! Роль

Вступ

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

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

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

Див. так само

|- | Повні права | admin, buh1, manager | Забагато користувачів | Залишити тільки адміністраторам |- | Менеджер продажів | ivanenko, shevchenko | Немає | Перенести в K2 ERP після перевірки |- | Комірник | sklad, sklad2 | Спільні логіни | Створити персональні акаунти |- | API сайту | api_site | Має зайві права | Обмежити до API-сценаріїв |- | Старий консультант | consultant | Активний доступ | Заблокувати |}

Роль і банк

Підхід K2 ERP. Під час переходу з BAS потрібно не переносити старі ролі “як виступає як”, а побудувати нову рольову модель у K2 ERP: персональні користувачі, групи, мінімально необхідні права, сервісні акаунти, журналювання, контроль експорту, BI-доступу, API та адміністративних дій. # Визначити користувачів із повними правами. Тому ролі BAS потрібно розглядати як об’єкт інвентаризації, аудиту доступів і контрольованої міграції на українську ERP-платформу.

Приклад:

Роль і клієнт-серверний режим BAS

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

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

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

як приклад:

Матриця доступу для K2 ERP

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

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

|- | Замовлення покупця | Створення і зміна | Перегляд | Перегляд |- | Реалізація товарів | Створення | Перегляд | Проведення |- | Переміщення товарів | Перегляд | Створення і проведення | Перегляд |- | Касовий ордер | Немає доступу | Немає доступу | Створення і проведення |}

Типові проблеми:

! Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.SEO title: Роль BAS — права доступу, користувачі, групи, профілі, безпека і міграція в K2 ERP

SEO keywords: роль BAS, ролі BAS, права доступу BAS, користувач BAS, групи користувачів BAS, профілі доступу BAS, адміністратор BAS, сервісний користувач BAS, журнал реєстрації BAS, обмеження доступу BAS, роль 1С, права доступу 1С, міграція ролей з BAS, заміна BAS, заміна 1С, K2 ERP, українська ERP, санкції BAS, санкції 1С, цифрова незалежність

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

}}

Роль BAS — це ключовий елемент системи доступу. Адміністратор

! admin → тільки адміністрування

Такі права мають бути тільки у відповідальних користувачів. ! # Перевірити доступ до банку й каси. # Протестувати сценарії. # Налаштувати сервісні ролі. У практиці адміністрування здатна використовуватися поняття профілю доступу. Аудитор здатна бачити:

! Що обмежує

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

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

Комірник зазвичай має доступ до:
Роль здатна дозволяти:
Правильний порядок:

|- | buh_kyiv | ТОВ Київ | Бухгалтерські документи ТОВ Київ |- | buh_lviv | ТОВ Львів | Бухгалтерські документи ТОВ Львів |- | fin_dir | Усі організації | Консолідована формування звітів |}

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

як приклад:

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

! Собівартість виступає як комерційно чутливою інформацією. ! Банківські права можуть включати:

змінювати документи;
проводити документи;
видаляти інформаційні дані;
змінювати користувачів;
запускати критичні обробки. * список ролей;
список користувачів;
відповідність ролей посадам;
фактичні права;
групи користувачів;
адміністраторів;
сервісні акаунти;
доступи до зарплати;
доступи до фінансів;
доступи до собівартості;
права на обробки;
права на експорт;
web-доступ;
API-доступ;
журнал активності. У BAS роль пов’язана з користувачем, конфігурацією, об’єктами метаданих, довідниками, документами, звітами, обробками, регістрами, підсистемами, журналом реєстрації та бізнес-процесами. K2 ERP у цьому процесі здатна стати платформою для контрольованих ролей, користувачів, груп доступу, сервісних акаунтів, API, BI-аналітики, журналювання, прав доступу, резервного копіювання, web-доступу й подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми BAS / 1С. # Описати обробки. ! Вона визначає, що користувач системи здатна бачити й робити: працювати з довідниками, документами, звітами, обробками, інтеграціями, фінансами, зарплатою, собівартістю, закритими періодами й адміністративними налаштуваннями. Доступ

Тому ролі BAS потрібно доповнювати контролем файлових прав. Їх не можна без зусиль копіювати зі старої системи. |- | Що найнебезпечніше в ролях?== Таблиця аудиту ролей ==

Що таке роль BAS

* менеджерів продажів;
* комірників;
* зовнішніх користувачів;
* сервісних акаунтів;
* філій без відповідного рівня доступу.== Роль керівника ==
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
Навіть роль “тільки перегляд” здатна бути небезпечною, якщо дає можливість експорт. # Перевірити права на обробки.[[Категорія:Автоматизація бізнесу]]
Звіти часто містять чутливу інформацію. Відповідь

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

Ролі в [[BAS]] потрібні для того, щоб кожен користувач системи мав доступ тільки до тих функцій, які потрібні йому для роботи. Комірник

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

* повні адміністративні права;
* права на зміну користувачів;
* доступ до технічних обробок;
* доступ до API;
* доступ до всіх інтеграцій. # Знайти сервісні акаунти. Менеджер
Адміністраторські права не повинні використовуватися для щоденної роботи менеджера, бухгалтера або інтеграцій. рішення для бізнесу
[[Категорія:BAS]]
|-
| продажі та реалізація
| Менеджер продажів, Перегляд залишків
| ivanenko, shevchenko
|-
| складський облік
| Комірник, Перегляд номенклатури
| sklad_kyiv, sklad_lviv
|-
| бухгалтерський обліковий облік
| Бухгалтер, Каса, Банк
| buh1, buh2
|-
| Керівництво
| Перегляд звітів, BI
| director, fin_dir
|}

Ризики:

== Адміністратор BAS ==

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

== Права на експорт ==

як приклад, менеджер здатна бачити продажі та реалізація, але не собівартість і зарплату. # Протестувати сценарії. Роль
Погані підходи:
'''Головне.''' Роль [[BAS]] — це не без зусиль назва посади. Роль K2 ERP
! користувач системи

[[Категорія:Користувач K2 ERP]]

* роль має зайві права;
* користувач системи має кілька несумісних ролей;
* менеджер має повні права;
* комірник бачить собівартість;
* сервісний користувач системи має доступ до зарплати;
* інтеграційні функції ERP функціонує під admin;
* звільнений користувач системи має активну роль;
* тестова роль застосовується для в роботі;
* немає опису ролей;
* права давно не переглядалися. # Побудувати матрицю доступу. Якщо конфігурація нетипова, ролі так само можуть бути дороблені. |-
| Контрагенти
| Створення
| Перегляд
| Зміна
| Перегляд
| Повний доступ
|-
| Замовлення
| Створення і зміна
| Перегляд
| Перегляд
| Перегляд
| Повний доступ
|-
| Складські документи
| Перегляд
| Створення
| Перегляд
| Перегляд
| Повний доступ
|-
| Каса
| Немає
| Немає
| Повний доступ
| Перегляд
| Повний доступ
|-
| Зарплата
| Немає
| Немає
| Обмежений доступ
| За окремим дозволом
| Повний доступ
|-
| BI
| Власні продажі та реалізація
| Складські KPI
| фінансовий блок
| Консолідована аналітичні інструменти
| Адміністрування
|}

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

[[Категорія:Інтеграція з BAS]]
!== Як не треба робити ==
Приклад:
== Контроль ролей після запуску K2 ERP ==
== Права на документи ==
[[Категорія:1С]]
Приклад:
Доступ до зарплати можуть мати:
[[Категорія:Клієнт-серверний режим BAS]]
! # Описати BI-доступ. # Призначити персональних користувачів. як приклад:

[[Категорія:Українське програмне забезпечення]]

* складів;
* номенклатури;
* надходжень;
* переміщень;
* відвантажень;
* інвентаризацій;
* списань;
* серій;
* характеристик;
* штрихкодів;
* складських звітів. !== Роль касира ==

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

! Об’єкт / Роль

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

* продажів;
* залишків;
* собівартості;
* прибутку;
* зарплати;
* податкової звітності;
* банківських залишків;
* дебіторської заборгованості;
* кредиторської заборгованості;
* управлінської аналітики;
* [[BI]]. Призначення

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

== Таблиця міграції ролей ==

== Роль і користувач системи BAS ==
Роль api_site має доступ тільки до товарів, цін, залишків, замовлень і статусів
Обмеження по підрозділах потрібні для:

! Потрібно провести аудит, знайти зайві права, прибрати спільні логіни, обмежити адміністраторів, створити сервісні ролі для API, побудувати матрицю доступу й перевірити її на реальних сценаріях.== Роль менеджера продажів ==

Аудиторська роль зазвичай має бути роллю перегляду. |-
| Чи здатна користувач системи мати кілька ролей? як приклад:

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

* фінансовий блок;
* зарплату;
* собівартість;
* адміністративні конфігурація;
* зміну цін;
* зміну прав користувачів. Менеджер
== Роль BAS і цифрова незалежність ==
== Роль і обмеження по складах ==
Якщо застосовується для [[Веб-клієнт BAS]], роль визначає, що користувач системи здатна робити через браузер. # Перевірити журнал реєстрації. # Перевірити доступ до собівартості. {| class="wikitable" style="width:100%;"
Зарплатні інформаційні дані мають бути захищені. {| class="wikitable" style="width:100%;"

Краще:

== Роль “Тільки перегляд” ==

* адміністратор;
* повні права;
* бухгалтер;
* провідний бухгалтер;
* менеджер продажів;
* менеджер закупівель;
* комірник;
* касир;
* керівник;
* кадровик;
* розраховувач зарплати;
* логіст;
* технолог;
* виробничий користувач системи;
* аудитор;
* користувач системи інтеграції;
* тільки перегляд;
* зовнішній користувач системи. # Описати звіти. ! |-
| Контрагенти
| Створення і зміна
| Перегляд
| Перегляд і зміна
|-
| Номенклатура
| Перегляд
| Перегляд і уточнення
| Перегляд
|-
| Банківські рахунки
| Немає доступу
| Немає доступу
| Зміна
|-
| Фізичні особи
| Немає доступу
| Немає доступу
| Обмежений доступ
|}

Але бухгалтеру не завжди потрібні:

bi_export → BI

У деяких конфігураціях або моделях адміністрування ролі можуть призначатися не тільки окремим користувачам, а й групам. Менеджер
== Роль і інтеграції ==
Бухгалтерська роль здатна давати доступ до:
Люди й інтеграції мають різні ролі. * розділяти відповідальність;
* захищати інформаційні дані;
* обмежувати доступ;
* контролювати інтеграції;
* захищати зарплату й фінансовий блок;
* не відкривати собівартість зайвим користувачам;
* вести аудит;
* готувати якісну міграцію в [[K2 ERP]]. Керівник часто потребує доступу до звітів і аналітики. Права на обробки потрібно обмежувати особливо уважно. # Перевірити API-доступ. !

які ролі існують;
які об’єкти доступні;
які довідники можна відкривати;
які документи можна проводити;
які звіти доступні;
які обробки дозволені;
які регістри відкриті;
які підсистеми показані;
які форми доступні;
які команди можна виконувати.</syntaxhighlight>

Коротко

Окремо варто відзначити який визначає, що саме користувач системи здатна бачити, створювати, змінювати, проводити, видаляти, друкувати, експортувати або адмініструвати в інформаційній базі виступає ключовою рисою Роль BAS. Погано: як приклад: |- | 15.05.2026 10:15 | ivanenko | Менеджер продажів | Створення | Замовлення покупця №123 |- | 15.05.2026 10:20 | buh1 | Бухгалтер | Проведення | Банківська виписка №45 |- | 15.05.2026 11:05 | admin | Адміністратор | Зміна ролі | користувач системи sklad_kyiv |- | 15.05.2026 12:30 | api_site | API сайту | Обмін | Замовлення WEB-100245 |}

! # Описати довідники. Часто достатньо доступу на перегляд і затвердження.== Права на обробки ==

Каса — це зона фінансового контролю, тому права мають бути чітко розділені. api_crm → CRM

Роль аудитора

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

Роль і веб-клієнт BAS

Це одна з найнебезпечніших помилок. # Визначити чутливі інформаційні дані. Експорт даних — окрема зона ризику.

Помилка: не перевіряти права на експорт

продажі та реалізація;
прибуток;
дебіторська заборгованість;
кредиторська заборгованість;
залишки;
фінансові звіти;
KPI;
план-факт;
BI. Довідник

Роль “Повні права”

клієнтську базу;
зарплату;
собівартість;
фінансові звіти;
залишки;
договори;
банківські реквізити. | Це набір прав доступу, який визначає, що користувач системи здатна робити в системі. * перепровести документи;
змінити ціни;
завантажити неправильні інформаційні дані;
видалити помічені об’єкти;
змінити реквізити;
зламати інтеграційний обмін. Роль здатна дозволяти або забороняти:

З урахуванням санкційних, юридичних і кібербезпекових ризиків BAS та 1С, аудит ролей має бути частиною ширшої стратегії переходу на українське програмне забезпечення (ПЗ), цифрову незалежність і сучасну ERP-архітектуру. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні. Якщо неправильно — користувачі бачать зайві інформаційні дані, можуть змінювати критичні документи, запускати небезпечні обробки, відкривати зарплату, собівартість, фінансовий блок або адміністрування без реальної потреби. # Перевірити доступ до зарплати.

Типові ролі BAS

Помилка: роль не відповідає посаді

Приклади обробок:

хто входить у систему;
хто створює документи;
хто змінює інформаційні дані;
хто запускає обробки;
хто має помилки доступу;
хто функціонує під admin;
які сервісні акаунти активні;
які ролі фактично використовуються;
чи виступає як підозрілі дії. {| class="wikitable" style="width:100%;"

Ризик. Роль “Повні права” має бути тільки в обмеженого кола відповідальних адміністраторів. Керівник ! ! # Призначити користувачів. Потрібно провести аудит і створити нову контрольовану матрицю доступу. критично про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. # Побудувати нову матрицю доступу. Сервісна роль

Роль при міграції з BAS у K2 ERP

Описати посади. Аудит ролей потрібен для виявлення ризиків. У контексті переходу з BAS на K2 ERP ролі мають особливе значення. Це технічний набір дозволів, який визначає, які дії користувач системи здатна виконувати в системі й до яких даних він має доступ. ! Доступ

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

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

Потрібно перевірити: Обробки можуть змінювати багато даних одразу. # Увімкнути журналювання. | Ні. ! Комірник як приклад:

компанія-користувач повинна:

[[Категорія:Роль 1С]]
! Найчастіші проблеми:

* створення касових ордерів;
* проведення касових ордерів;
* перегляд касової книги;
* оформлення оплат;
* повернення;
* закриття касової зміни;
* друк касових документів. |-
| Що таке сервісна роль? рішення для бізнесу

== Типові помилки з ролями BAS ==
У [[K2 ERP]] ролі варто будувати від бізнес-процесів. це набір прав доступу в системі [[BAS]]. Роль
== Роль і зарплата ==
інтеграційні функції ERP із сайтом функціонує під admin
Сервісна роль потрібна для інтеграцій. Питання
== Роль і конфігурація BAS ==
У [[Файловий режим BAS|файловому режимі BAS]] ролі в системі можуть бути налаштовані правильно, але ризик залишається на рівні папки бази. Користувачі
Її потрібно обмежувати для:
Він здатна показати:
|-
| ivanenko
| Менеджер продажів
| здатна створювати замовлення покупців
|-
| petrenko_buh
| Бухгалтер
| здатна працювати з банком і касою
|-
| sklad_kyiv
| Комірник
| здатна працювати зі складом Київ
|-
| admin
| Адміністратор
| Має розширені права
|}

як приклад:

Керівнику не завжди потрібні права на зміну первинних документів. |-
| API сайту
| Обмін із сайтом
| Товари, залишки, ціни, замовлення, статуси
|-
| API CRM
| Обмін із CRM
| Клієнти, угоди, замовлення
|-
| API WMS
| Обмін зі складом
| Складські документи, залишки, відвантаження
|-
| BI-експорт
| Передача даних в аналітику
| Читання потрібних аналітичних даних
|-
| Імпорт банку
| Завантаження банківських операцій
| Банківські документи
|}

Закриті періоди потрібно захищати.{{DISPLAYTITLE:Роль BAS}}

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

Адміністратор здатна:

* контрагентами;
* контактами;
* договорами;
* замовленнями покупців;
* рахунками;
* реалізаціями;
* резервами;
* цінами продажу;
* статусами замовлень;
* комерційними пропозиціями;
* CRM-даними, якщо вони виступає як. Результат
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
Для складського обліку критично обмежувати доступ по складах. * зміну документів минулих періодів;
* перепроведення;
* скасування проведення;
* коригування;
* зміну дати заборони редагування;
* службове виправлення.<syntaxhighlight lang="text">

* клієнтів;
* постачальників;
* ціни;
* залишки;
* зарплату;
* фінансові звіти;
* собівартість;
* персональні інформаційні дані;
* договори;
* банківські реквізити. Після запуску потрібно перевірити:
У різних конфігураціях назви ролей можуть відрізнятися, але в бізнесі часто зустрічаються такі ролі:
користувач системи BAS → Роль BAS → Права доступу → Доступні об’єкти і дії
|-
| Повні права
| Видана багатьом користувачам
| Адміністратор K2 ERP
| Залишити тільки відповідальним
|-
| Менеджер
| Має доступ до собівартості
| Менеджер продажів
| Прибрати собівартість
|-
| складський облік
| Спільний логін
| Комірник
| Створити персональні доступи
|-
| Бухгалтер
| Має зайві обробки
| Бухгалтер
| Обмежити службові обробки
|-
| api_site
| функціонує під admin
| API сайту
| Створити окремий сервісний профіль
|}

! # Перевірити права на експорт. Роль
{| class="wikitable" style="width:100%;"
== Роль сервісного користувача ==
|-
| Менеджер продажів
| Клієнти, замовлення, рахунки
| Зарплата, адміністрування, собівартість
|-
| Комірник
| Складські документи, залишки, інвентаризація
| Банк, каса, зарплата
|-
| Бухгалтер
| Каса, банк, проводки, податкові документи
| Адміністрування без потреби
|-
| Керівник
| Звіти, аналітичні інструменти, контроль
| Зміна первинних документів без потреби
|}

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

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

Касир здатна працювати з:

'''Адміністратор''' — це роль із розширеними правами.[[Категорія:Ролі BAS]]

* зарплати;
* собівартості;
* налаштувань прав;
* усіх банківських рахунків;
* технічних обробок.[[Категорія:Журнал реєстрації 1С]]

* хто має web-доступ;
* чи виступає як спільні логіни;
* чи немає ролі “Повні права” у web-користувачів без потреби;
* чи функціонує HTTPS;
* чи ведеться журнал входів;
* які web-сервіси доступні;
* які ролі мають сервісні користувачі. Конфігурація визначає:

* переносити ролі BAS у K2 ERP без аналізу;
* залишати всім повні права;
* не створювати матрицю доступу;
* не відокремлювати сервісні акаунти;
* не обмежувати BI;
* не обмежувати експорт;
* не обмежувати зарплату;
* не обмежувати собівартість;
* не перевіряти журнал реєстрації;
* не блокувати старі ролі;
* залишати BAS активною після запуску [[K2 ERP]];
* ігнорувати санкційні й кібербезпекові ризики. Не повинні мати доступ:

'''Найгірший сценарій.''' компанія-користувач переходить у [[K2 ERP]], але копіює старі ролі BAS без аудиту: усі мають повні права, інтеграції працюють під admin, менеджери бачать собівартість, звільнені користувачі активні, а права на експорт не контролюються. | Так, але це потрібно контролювати, щоб не видати зайві права. Якщо її мають усі користувачі, платформа фактично не має контролю доступу. # Описати документи. Ролі
[[Категорія:ERP]]

! !== Роль і собівартість ==

Менеджер продажів зазвичай функціонує з:

Ролі важливі для інтеграцій.== Права на звіти ==

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

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

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

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

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

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

== Чому ролі BAS не можна переносити як виступає як ==

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

* менеджери;
* комірники;
* касири без потреби;
* сайт;
* CRM;
* WMS;
* BI-експорт без обмеження;
* тестові користувачі. # Знайти адміністраторів. # Перевірити web-доступ. ! * банківських документів;
* касових документів;
* авансових звітів;
* податкових документів;
* бухгалтерських проводок;
* взаєморозрахунків;
* основних засобів;
* закриття місяця;
* регламентованої звітності;
* оборотно-сальдових відомостей. Бухгалтер
</div>
! Права на документи можуть бути різними. як приклад:

! Дія
Це небезпечно, якщо її мають зайві користувачі.</div>
</div>
'''Роль [[BAS]]''' — це об’єкт конфігурації або конфігурація доступу, який визначає набір дозволів для користувача.== Побудова ролей у K2 ERP ==
через Журнал реєстрації користувачі можуть перевірити, як реально використовуються ролі. ! |-
| Чи можна переносити ролі BAS у [[K2 ERP]] як виступає як? ! Це інтуїтивно, але здатна створювати ризики, якщо ролі накладаються і дають зайвий доступ. Бухгалтер

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

buh1 → бухгалтер

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

== Права на довідники ==

! Наслідки:

! У [[K2 ERP]] під час міграції краще будувати саме профільну модель: від реальних ролей бізнесу до конкретних технічних прав. як приклад:

Касові права можуть включати:

Приклад:

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

== Помилка: не розділяти ролі людей і сервісів ==

* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu хмарна інфраструктура K2 ERP]
* [https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку]
* [https://cip.gov.ua/ua/news/vidpovidi-na-poshireni-zapitannya-shodo-pereliku-zaboronenogo-programnogo-zabezpechennya-ta-obladnannya Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ]
* [https://www.president.gov.ua/documents/6012024-52009 Указ Президента України №601/2024]
* [https://zakon.rada.gov.ua/go/601/2024 Указ Президента України №601/2024 на сайті Верховної Ради України]
* [https://t.me/+uIdWI1W6vndkMTAy Telegram-канал K2 ERP]
* [https://t.me/+6jFwAZM6TQliNTdi Група обговорення функціоналу та пропозицій]
* [https://www.linkedin.com/company/k2erp/ LinkedIn K2]

Потрібно перевірити:
== Роль і профіль доступу ==
[[Категорія:Користувач BAS]]
== Роль і обмеження по організаціях ==
Роль із повними правами дає максимальний доступ до системи. |}

Такі права потрібно видавати обмежено. Роль тільки для перегляду потрібна для:

== Роль і каса ==

Групи спрощують адміністрування, але потрібно контролювати, щоб група не давала користувачу зайвих прав. ! Під час переходу з [[BAS]] у [[K2 ERP]] ролі не потрібно переносити механічно. | користувач системи входить у систему, а роль визначає його дозволи. # Вивантажити список користувачів. # Описати API-доступ. * бухгалтер із зарплати;
* кадровик;
* провідний бухгалтер;
* керівник за окремим дозволом;
* сервісний користувач системи тільки за крайньої потреби й з обмеженнями. Документ

Якщо ролі налаштовані правильно, платформа підтримує порядок і безпеку.[[Категорія:JSON 1С]]

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

Обмежувати бажано:

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

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

У [[K2 ERP]] потрібно створити чисту модель доступу. У [[Клієнт-серверний режим BAS|клієнт-серверному режимі BAS]] ролі важливі для:

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

* продажів;
* закупівель;
* виробництва;
* складу;
* філій;
* проєктів;
* центрів витрат;
* регіонів;
* команд. Саме через ролі визначається, чи здатна користувач системи відкрити довідник, створити документ, провести операцію, побачити собівартість, змінити закритий період, запустити обробку або отримати доступ до інтеграції. Ролі використовуються для розмежування доступу між бухгалтерами, менеджерами, комірниками, касирами, керівниками, адміністраторами, інтеграційними користувачами і іншими учасниками облікової системи. # Заблокувати старі BAS-доступи після запуску. # Створити ролі в [[K2 ERP]]. | Так.[[Категорія:Адміністрування BAS]]

! |-
| Чи виступає як санкційні ризики у [[BAS]] і [[1С]]? Група

Якщо користувач системи має доступ до файлової папки, він здатна:
! | Це роль для технічного користувача інтеграції, API, web-сервісу або автоматичного обміну. Права на експорт мають бути частиною матриці доступу. Потрібно проаналізувати реальні обов’язки користувачів, знайти зайві права, спільні логіни, сервісні акаунти, адміністраторські доступи, небезпечні обробки, права на зарплату, фінансовий блок, собівартість, експорт і побудувати нову контрольовану модель доступу в [[K2 ERP]].

Роль і журнал реєстрації

Касир не повинен мати зайвий доступ до: