Roluri & permisiuni

• Cui vorbim:* proprietar / manager / decident IT care vrea să înțeleagă cum controlează cine ce face în ERP.

Ideea de bază

Fiecare utilizator ERP are un cont personal (username + parolă) și primește unul sau mai multe roluri. Un rol e o listă de permisiuni — atomice, verificate individual la fiecare acțiune sensibilă. Când un utilizator încearcă o acțiune, sistemul verifică dacă are cel puțin o permisiune care o acoperă; altfel primește 403.

• Consecință practică:*
• Adăugarea unui angajat nou = duplicare rol existent, cu ajustări dacă e nevoie.
• Restricționarea unei acțiuni pentru un rol = scoate permisiunea specifică; nu trebuie rescris tot rolul.
• Auditul e complet: fiecare acțiune scrie în jurnalul inalterabil cine a făcut-o (utilizator + rol activ).

Convenția de nume

Permisiunile respectă o gramatică consistentă care le face ușor de citit și de căutat:

MODULE__ACTION                    → permisiune de bază, pentru toate scope-urile
MODULE__ACTION:SCOPE:value        → variantă restrânsă la un scope specific

Exemple concrete:

• Convenția MODULE__ACTION (cu dublu-underscore)* separă clar prefixul de modul de restul. Face ușor de identificat familia de permisiuni printr-un grep simplu în audit.

Rolurile pregătite din start

La onboarding activăm câteva roluri pre-configurate, pe care le poți duplica și ajusta după nevoile tale reale. Numele din paranteze sunt cele din sistem.

Administrator (role_administrator)

• Cine:* proprietar / director / responsabil IT principal.

• Ce poate:*
• Tot ce ține de configurare (catalog, prețuri, roluri, permisiuni, integrări).
• Toate rapoartele + toate acțiunile fiscale (inclusiv ștergere entrii cash-register).
• Framework fiscal-modules complet (scanare QR MEV, formular manual, aplicare stoc retroactiv).
• Administrare sesiuni MCP (asistent AI).

• Ce nu:* nu are "super-putere" ascunsă — logurile sunt inalterabile prin design, iar acțiunile lui rămân în jurnal exact ca orice alt utilizator. Vezi și T&C — Admin responsability.

Manager de tură HoReCa (role_horeca_manager_tura)

• Cine:* manager sală / responsabil schimb într-un restaurant.

• Ce poate:*
• Ciclul complet Comandă (creare, adăugare linii, trimitere către divizii, factură, deblocare).
• Override preț per linie (excepții cu autorizare).
• Toate stagiile folder:invoice (supervizează bonurile de producție).
• Vede kitchen-display + tab-ul Rapoarte al webapp-ului HoReCa (HORECA_DASHBOARD__VIEW:PANEL:reports).
• Rulează "Închide tura" (HORECA_REPORT__SHIFT_CLOSE) și generează rapoartele din tab-ul Rapoarte: (1) raportul de închidere v1 — subtype-aggregated (production / sell / writeoff / transfer / supply / transform / ecommerce) + top 10 pierderi (mpn / events / qty) + total bonuri; (2) roll-up lună de tură (agregare pe calendaristic × POS); (3) split tips ospătari (calc pe cerere — % configurabil în FE, nu se persistează); (4) ⚙️ detecție anomalii pierderi (activabil, cu prag configurabil σ). Este singurul rol pre-configurat care poate rula "Închide tura" implicit (peste role_administrator prin wildcard HORECA_*); pentru limitare la un POS anume se folosește sintaxa HORECA_REPORT__SHIFT_CLOSE:POS:<pos-id>.

• Ce nu: nu poate șterge entrii din cash-register (ștergerea = admin senior only) și nu poate aplica stoc retroactiv. De asemenea, "Închide tura" este un snapshot retrospectiv* al zilei calendaristice alese pe un POS — nu emite / nu așteaptă Z-ul de la casa de marcat (MCR Z-shift e operațiune fizică separată), nu blochează operațional casa de marcat, nu verifică "curățenia" (Comenzi deschise / bonuri ne-emise sunt pur și simplu excluse din agregare, nu blocante) și nu se poate "redeschide". Re-execuția pe aceeași dată × POS creează un al doilea snapshot alături de primul (fără dedup) — responsabilitatea de gestiune înainte de close rămâne a managerului.

Casier HoReCa (role_horeca_casier)

• Cine:* casier la POS fiscal — emite bonurile clienților.

• Ce poate:*
• Vedere Comenzi în lucru + panoul fiscal.
• Emitere bonuri fiscale (HORECA_FISCAL__EMIT, FISCAL_PUSH_CASH_REGISTER).
• Nou: scanare QR bon fiscal / introducere manuală bon prin fiscal-modules framework (FISCAL_MODULES__USE).
• Tranziții rapide "✅ Ready" / "✖ Aborted" pe bonurile emise.

• Ce nu:* nu editează Comenzi (doar le vede), nu modifică prețuri, nu vede rapoarte financiare.

Chelner (role_horeca_chelner)

• Cine:* ospătar care ia comenzi la masă.

• Ce poate:*
• Creare + editare Comenzi (înainte de trimitere divizie).
• Adăugare linii (prețurile snap-uiesc la catalog — nu poate deriva).
• Cerere pre-bill.

Bucătar (role_horeca_bucatar)

• Cine:* operator kitchen / bar / cafenea — vede kitchen-display + marchează pregătit.

• Ce poate:*
• Vedere kitchen-display pentru diviziunile alocate.
• Marcare status linie (pregătit / servit).

Roluri MCP (asistent AI conectat)

Patru template-uri specializate pentru accesul AI:

• role_mcp_reader_catalog — doar consultare catalog (produse, categorii).
• role_mcp_reader_analyst — read complet (catalog + comenzi + stoc + facturi + roll-up lună de tură HoReCa + e-Factura).
• role_mcp_efactura_only — acces la funcțiile e-Factura (draft, semnare, listare).
• role_mcp_editor_manager — read + acțiuni asistate limitate (prețuri, stoc, notificări operator; include și MCP_TOOL:horeca_shift_month — roll-up lună tură HoReCa read-only).

Notă: tool-ul MCP horeca_shift_month are un domain fallback pe HORECA_REPORT__SHIFT_CLOSE — dacă utilizatorului îi lipsește această permisiune de domeniu (chiar dacă are MCP_TOOL:horeca_shift_month), apelul MCP eșuează. Nu există tool MCP pentru "Închide tura" — închiderea unei ture (crearea snapshot-ului) e strict UI-only în webapp HoReCa; MCP-ul poate doar citi rezultatele.

Vezi Asistent AI conectat (MCP) pentru detalii de activare + cost.

Permisiunile fiscal-modules nou introduse

Framework-ul de capture bon fiscal (scanare QR, formular manual, sync provider extern) folosește două grants dedicate:

FISCAL_MODULES__USE

• Cine primește:* cashier + manager de tură + administrator (deja incluse implicit în rolurile de mai sus).

• Ce activează:*
• Scanare cod QR de pe bon fiscal MEV (mev-qr-scan) — utilizatorul apucă scanner-ul, scanează codul de pe bonul furnizorului sau al operatorului fiscal, iar sistemul aduce automat detaliile și le înregistrează în stoc.
• Introducere manuală bon (manual-form) — pentru bonuri fără QR (bonuri istorice, chitanțe non-fiscale, furnizori care nu emit MEV).
• Manualul de refresh config fiscal-modules.

• Nu activează:* aplicare retroactivă stoc pentru bonuri istorice — aceasta e un grant separat, deliberat mai restrâns.

FISCAL_MODULES__APPLY_STOCK_MANUAL

• Cine primește: administrator + eventual operations lead — nu casierul de zi cu zi*.

• Ce activează:*
• Aplicare stoc retroactivă pe bonuri care au fost capturate cu verdict skip:autosync_inactive sau skip:pre_boundary (bonuri istorice care nu au fost decrementate la ingestion).
• Recovery-scan (retry sweep pentru bonuri blocate într-o stare tranzientă de eroare).

• De ce e restricționat:* fiecare apply modifică stocul real. Ștergerile / corecțiile trebuie să fie decizii conștiente ale unei persoane cu vedere de ansamblu, nu ale casierului aglomerat la ora de vârf. Fiecare acțiune scrie un rând audit audit_apply[] cu username + timestamp + verdictele înainte/după.

Cum ajustezi rolurile

• Creezi utilizator nou cu rol pre-existent → din Setări → Utilizatori.
• Duplici un rol și îi modifici permisiunile → duplicare + ștergere / adăugare grants.
• Adaugi permisiune scoped (ex. FISCAL_MODULES__USE doar pe un POS specific) → sintaxa PERM:SCOPE:value (vezi tabelul de convenție de mai sus).
• Vezi cine ce a făcut → jurnalul inalterabil păstrează fiecare acțiune cu username + rol activ + timestamp.

Rolurile default pot fi rescrise oricând conform nevoilor tale. Cerere de personalizare la onboarding = inclus în pachetul Start+; ajustări ulterioare = suport standard.

Câteva reguli de bun-simț

• Cel mai puțin privilegiu, nu cel mai mult — un casier nu are nevoie să vadă marja per produs sau costurile intrări. Rolul pre-configurat casier reflectă asta.
• Un cont per persoană, nu un cont partajat pe schimburi — asta rupe auditul. Rotația de personal pe același cont funcțional (schimbul dimineață / seara pe același login casier1) este acceptată și nu contează separat la licențiere.
• Admin ≠ operațional zilnic — folosește un cont de zi cu zi cu rol de manager, nu cu rol de admin. Rezervă contul admin pentru configurări reale (evită expunerea inutilă a permisiunilor de blast-radius mare).
• Revizuiește periodic — cel puțin o dată pe an, uită-te la lista de utilizatori și scoate cei care au plecat. La cerere, îți oferim un raport auditabil al accesului fiecărui cont.

Următorul pas

→ Onboarding — proces și termene sau Migrare date.