Як влаштовані права доступу в Customera?

Чому кількох готових ролей завжди замало — і як виглядає система, у якій права підлаштовуються під реальних людей і посади.

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

Відкриваєте налаштування користувачів — а там нічого.

Є роль «Комірник». Вона відкриває всі три склади одразу — або не відкриває нічого. Проміжного немає. Щоб зробити доступ лише до одного складу, треба кликати підрядника, чекати доробки й релізу, а часом ще й назавжди втратити можливість оновлювати систему.

Доступ не мусить бути рубильником (on/off). Його можна зібрати під конкретну людину з чотирьох окремих частин.
— Ідея, на якій побудована Customera

Чотири осі, які працюють окремо

Готових ролей завжди замало. Бо роль у звичних системах — це одразу три речі в одному: що людині можна робити, які дані вона бачить і яке меню перед нею. І якщо хочеш змінити дрібницю — треба переробляти усе.

Права — що людина може робити. Бачити, створювати, редагувати, видаляти, проводити. Окремо — точкове право редагувати вже закритий період.

Рядки — які саме записи їй видно. Права кажуть: «Можна працювати з продажами». А ця вісь уточнює: але лише по своєму складу, своїй касі, своїй організації.

Групи — що конкретно їй видали. Готовий пакет: права + обмеження за рядками + список людей. Збирає й міняє адміністратор прямо в застосунку.

Робоче місце — який екран вона бачить. Набір сторінок і меню під посаду. Директору — короткий екран зі зведеннями, комірнику — прийом товару й залишки.

Поодинці кожна вісь проста. Уся перевага — в тому, що вони комбінуються. Ту саму людину можна обмежити конкретним складом, не переписуючи роль. Те саме право — показати в різних робочих місцях. А коли роль уже є, доступ новому працівнику збирається за хвилини.

Далі — приклади реальних ситуацій.

Комірник, який має бачити лише свій склад

Новий комірник на складі №2. Має бачити залишки й документи тільки свого складу, приймати товар, продажі не проводити, закупівлі — лише переглядати.

Зазвичай: два погані варіанти. Дати роль «Комірник» — і він бачить усі три склади. Або замовити доробку під один склад, але це вже додаткові гроші й очікування релізу.

У Customera: адміністратор бере групу «Комірник — Склад №2»: роль плюс обмеження за складом. Дозволений склад обирається у звичайній формі. Перевівся — міняється одне поле.

Що дає: нічого зайвого перед очима, менше плутанини й зловживань, а налаштування — 5 хвилин силами самої компанії.

Касир і старший касир — право на закритий місяць

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

Зазвичай: «редагувати закритий період» — це часто право рівня адміністратора. Щоб дати його касиру, доводиться робити його майже адміном.

У Customera: це окреме, точкове право на документах. Даєте його одному старшому касиру, не роздаючи інших повноважень.

Що дає: одна людина отримує рівно те, що треба, без зайвих прав.

Бухгалтер на два ФОП, менеджер — на один

Типова структура: ФОП плюс ТОВ. Бухгалтер веде обидві юрособи, менеджер із продажів працює лише в одній.

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

У Customera: одна база. Бухгалтеру — група з доступом до обох організацій, менеджеру — до однієї. Список організацій обирається у формі.

Що дає: спільний облік для кількох юросіб, але кожен бачить лише своє.

Зовнішній аудитор — лише на місяць

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

Зазвичай: створюють роль «Аудитор_перегляд». Попрацював — а роль лишилась назавжди. За два роки таких неактивних ролей десятки, і вже ніхто не знає, хто що бачить.

У Customera: додали людину в групу «Лише перегляд» → попрацювала → прибрали зі списку. А на картці кожного видно його діючий доступ.

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

Одні дані — різні екрани під різні посади

Директор, менеджер і комірник працюють з однією системою. Але кожному треба своє: комусь зведення, комусь документи продажу, комусь лише прийом товару.

Зазвичай: меню приклеєне до ролі. Усі отримують один перевантажений список і самі шукають у ньому потрібне.

У Customera: робоче місце — окрема вісь від прав. Під ту саму роль збирається різний екран: людина заходить і бачить тільки те, з чим працює.

Що дає: менше навчання, менше помилок «натиснув не туди», відчуття системи, зробленої під себе.

Коли доступ стає частиною правил документа

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

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

Комірник рухає товар лише через свій склад

У комірника є доступ до свого складу. І це впливає не лише на видимість: переміщення він може оформити тільки зі свого складу, а прибуткові ордери прийняти — тільки на свій.

Зазвичай: доступ — це максимум фільтр «що видно». Самому документу байдуже: вкаже комірник чужий склад-відправник — система спокійно проведе. Помилку знаходять постфактум, коли звіряють.

У Customera документ сам не пропускає операцію. Обрав чужий склад-відправник — бачить зрозуміле «немає доступу до складу-відправника» і не зберігає. Прибутковий ордер — тільки на свій склад.

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

І головне: це не однакова для всіх поведінка, зашита в платформу. Вона налаштовується під конкретне рішення — саме тому, що межі доступу людини доступні логіці документа як звичайні дані. Одному бізнесу комірник рухає товар лише зі свого складу, іншому — з будь-якого зі свого списку, третьому такого правила немає взагалі. Система не диктує сценарій — вона дає інструмент, щоб його зібрати.

Коли ролі починають розмножуватися

У системі з жорсткими ролями кожна дрібна відмінність між людьми породжує нову роль. Ролі майже ніколи не видаляють. За рік-два їх сотні, і вже ніхто не пам'ятає, чим «Менеджер 3» відрізняється від «Менеджер новий».

Ось наслідок: на просте питання «хто має доступ до грошей?» відповісти вже неможливо. У цієї проблеми навіть є назва — «розмноження ролей».

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

Доступ як частина продукту

У звичайній системі майже будь-яка нестандартна потреба впирається або в підрядника, або в ще одну клон-роль. У Customera це або вибір у формі, або складання набору з готових шматків — руками самого бізнесу, за хвилини, без релізу.

Більшість шаблонних ERP такого, швидше за все, просто не має — щоб доступ збирався настільки точно під конкретну людину й посаду. Там він приходить готовим незмінним набором: підходить — добре, ні — живіть із цим або платіть за доробку.

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

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