Scenarii end-to-end

• Cui vorbim:* manager / proprietar care vrea să vadă cum se comportă sistemul în situațiile complicate.

Scenariu 1 — Masa progresivă (3 valuri)

• Context:* O familie la masa 5, comandă în 3 valuri pe parcursul a 1h.

19:42  Maria deschide Masa 5 — 4 persoane
19:44  Val 1:  2× Pizza Margherita, 1× Salată Greacă, 1× Apă
       → 3 bonuri (kitchen-hot ×2 pizza, kitchen-cold ×1 salată, bar ×1 apă)
       → Bonurile rulează în paralel (pizza ~14 min, salată ~5 min, apă rapid sincronizată)

19:50  Salata gata → Maria livrează
19:51  Apa livrată
19:58  Pizzas gata → Maria livrează ambele

20:15  Familia mai vrea: 2× Tiramisu, 1× Cafea, 1× Ceai
       → 2 bonuri (dessert ×2 tiramisu, coffee ×1 cafea, ×1 ceai)
       → Maria deschide Comanda 5 din meniul "active", adaugă rândurile, Trimite

20:22  Tiramisu gata, Maria livrează
20:23  Cafea + ceai livrate

20:35  Familia mai vrea: 2× Limoncello (tradițional la final)
       → 1 bon (bar)

20:39  Limoncello servit

20:50  Familia cere nota
       → Maria atinge "Cere nota" → Comanda → pending-bill

20:51  Tatiana (casier) deschide pos-fiscal → Încasează comandă → Masa 5
       → Coș pre-populat cu toate cele 11 linii
       → Total: 1.245 MDL
       → Familia plătește: 800 MDL cash + 445 MDL card
       → Bon fiscal emis, e-Factura nu (fără cerere)
       → Comanda 5 → plătită

20:51:03  Masa 5 devine liberă în harta sălii

• Rezultatul: Un singur bon fiscal pentru toată activitatea de la masă (conform legislației MD), cu separarea metodelor de plată. 5 bonuri de producție (3 + 2 din valul 2 + 1 din valul 3 — total 6 ridicate; bar a primit 3 — apă, băuturi calde, limoncello). Audit complet* al fiecărei acțiuni.

Pas cu pas — deschidere Comandă + adăugare produs

Ghid vizual pentru cele două acțiuni-cheie ale primului val (deschidere Comandă + adăugare prima linie). Restul fluxului (Send la bucătărie, marcare Ready, incasare fiscală) se comportă identic pentru fiecare val ulterior.

1. Deschiderea Comandei

• 1a. Chelnerul deschide tab-ul Orders* din HoReCa Dashboard.

• 1b. Formularul New order* e vizibil la vârful tab-ului — POS + Masă/Cameră + Zonă (opțional) + Divizie (opțional).

• 1c.* Chelnerul selectează POS-ul corect + tastează masa (ex: „Masa 5"). Zona (sala) și divizia rămân goale pentru un scenariu clasic.

• 1d. Click pe Open table / room*. Sistemul creează instant Comanda cu identificator scurt (K-N), o alocă chelnerului conectat + o adaugă în lista Orders.

• 1e. Confirmare vizuală (toast dreapta-sus) — Comanda deschisă. Rândul nou apare în tabelul Orders cu status open*.

2. Intrare pe Order View

• 2a. Chelnerul apasă 👁 View* pe rândul Comenzii pentru a intra pe fișa completă.

• 2b.* Order View încarcă — vezi antetul Comenzii (K-N, POS, chelner, stagiu) + secțiunile pentru linii, note, bonuri emise, pierderi și cicluri BOM.

3. Adăugare produs pe Comandă

• 3a. Secțiunea Add line* are un search rapid + rând cu cantitate, unit, preț, TVA, total și butonul Adaugă.

• 3b. Click pe câmpul Quick add product* pentru a activa search-ul.

• 3c.* Chelnerul tastează un cuvânt cheie (numele produsului, MPN sau SKU). Dropdown-ul filtrează instant rezultatele — fuzzy matching + tokenizat.

• 3d. Click pe produsul dorit (aici: Latte*, MPN 1000).

• 3e.* Preview card afișează foto + nume + MPN + stocul disponibil instant la POS-ul curent (color-code: verde OK, galben stoc scăzut, roșu 0).

• 3f.* Rândul de completare se populează automat cu prețul din catalog, TVA-ul configurat pentru POS (8% în acest exemplu — cota HoReCa), prețul cu TVA inclus (30.00) și totalul evidențiat verde.

• 3g. Click pe + Adaugă linie*.

• 3h. Linia apare în tabelul Order lines* cu toate câmpurile completate + acțiuni per-linie (modificare cantitate, modificare preț, gift, ștergere). Footer-ul afișează Subtotal fără TVA, TVA total, și TOTAL DE PLATĂ cu TVA.

4. Trimitere spre bucătărie

• 4a. Cu Comanda populată, chelnerul apasă 🍳 Trimite spre bucătărie*. Când toate liniile sunt sau full-produce sau all-stock, sistemul trimite direct (fără modal); dacă liniile necesită o decizie (split, unavailable) se deschide Split Modal.

• 4c.* Toast succes: numărul de bonuri create + fiecare linie primește statusul stagiu-bon (wip / awaiting-mpns / etc.).

• 4d. În Order lines, coloana Status* primește chip-ul de stagiu al bonului. Butonul 🗑 Șterge rămâne activ pentru linii pe bonuri neîncepute; devine indisponibil după ce bucătarul depășește wip/awaiting-mpns.

5. Bucătarul preia + marchează Ready

• 5a. Bucătarul deschide tab-ul Kitchen*. Vede queue-ul cu toate bonurile active pentru POS-ul lui.

• 5b.* Bonul nou apare în queue. Chip vizual distinge tipul: 🔨 Producție (albastru) vs 🍽️ Servire (verde). Fiecare rând are acțiuni: 👁 View, → next-stage (Accept/Start/Ready/Deliver sau Servește), +Loss (ascuns pe service), ↩ Anulează bon.

• 5c.* Cursor pe butonul next-stage. Butonul-label depinde de stagiul curent: → Accept (wip → awaiting-mpns), → Start (awaiting-mpns → validated-mpns, care explodează BOM-ul), → Ready, → Deliver. Service-bons folosesc un singur → Servește.

• 5d.* După ce bucătarul marchează ready, bonul dispare din queue (queue arată doar stagiile active). Audit-ul rămâne pe folder-ul propriu; poate fi accesat via View.

6. Emitere fiscală

• 6a. Chelnerul se întoarce în Order View. Butonul Pre-bill* deschide o fereastră pop-up cu bonul de plată (client vede totalul + TVA breakdown) — pre-fiscal, nu decrementează încă stoc, nu emite bon fiscal.

• 6b. Butonul Open in POS-Fiscal* trimite Comanda direct la terminalul cassierului. Când Comanda e în stagiul open, sistemul apelează automat request-bill (validează că toate bonurile de bucătărie sunt ready) apoi emit-fiscal (creează folder-ul fiscal + trece Comanda la paid).

• 6c.* POS-Fiscal se deschide cu coșul pre-populat din liniile Comandei. Casierul poate proces plata (numerar, card, MIA — o combinație), apoi emite bonul fiscal la casa de marcat certificată (Intelect-Soft MCR sau alt dispozitiv MEV). Decrementarea stocului cade prin fiscal-storage la sincronizarea receipt-ului.

Scenariu 2 — Cancel mid-prep cu pierdere

• Context:* Client comandă pizza, după 8 min anunță "scuze, am uitat că am întâlnire, nu mai vreau".

19:42  Masa 7 — Andrei (chelner) preia comanda: 1× Pizza Quattro Stagioni
19:43  Trimitere → bon kitchen-hot
19:44  Vlad (bucătar) — Acceptă
19:45  Vlad — Start (consumul ingredientelor: 250g blat, 80g sos, 120g topping mix)
19:53  Clientul anunță anularea — 8 minute după Start

       Andrei nu poate anula direct (post-prep) → cere manager_tură

19:54  Manager Andrei aprobă cancel post-prep (cu notă "client retras")
       Sistemul:
         → Marchează bonul kitchen-hot ca "anulat-cu-pierdere"
         → Generează automat bon de pierdere cu rândurile productive
           transferate ca pierdere, motiv "anulare_client", cont SNC 714
         → Vlad oprește prepararea, aruncă produsul
         → Stocul rămâne decrementat (consumul deja s-a întâmplat)

19:55  Comanda Masa 7 e închisă fără încasare (anulată complet)
       Masa 7 → liberă

       În raportul de tură:
         Pierderi: 95 MDL (Pizza Quattro — anulare client)
         Cont SNC 714: +95 MDL

• Cheia:* chelnerul nu poate anula post-prep singur — necesită aprobare manager. Sistemul nu permite "ștergerea" pierderii — ingredientele s-au consumat, contabil trebuie să apară pe 714.

Butonul 👁 View — navighează la Order View parent

Fiecare bon din Kitchen tab are un buton 👁 View care navighează la Order View-ul Comandei părinte (care a generat bonul). Util pentru bucătar când vrea să vadă contextul complet: alte linii ale mesei, chelnerul care a trimis, notele custom, etc.

Butonul ✚ Loss

• Referință vizuală — pas cu pas:*

Butonul ✚ Loss (Kitchen tab, per bon production) deschide dialogul Production-tied loss care înregistrează un writeoff row în folder-ul de bon:

Scenariu 3 — On-the-house / oferit clienților VIP

• Context:* Restaurant primește invitați VIP — patronul decide să ofere o sticlă de vin gratuit + un platou de tapas.

21:00  Masa VIP-1 — Maria (chelner) deschide comanda

21:05  Patronul îi spune Mariei: "Oferă sticla de Cabernet și
       platoul de tapas, pe contul casei"

21:06  Maria adaugă în Comanda VIP-1:
         1× Cabernet 2018 (sticlă)   → marchează "gift" cu motiv "degustare_client"
         1× Platou tapas mediu       → marchează "gift" cu motiv "degustare_client"
       Sistemul:
         → Necesită aprobare manager_tură (sumă > 50 MDL prag gratuități)

21:06  Manager Andrei aprobă → marchează ca "casă oferă VIP-1"
       Sistemul:
         → Liniile rămân pe comandă cu preț 0 MDL
         → Generează rânduri pe bonul de consum cu motiv "degustare_client",
           cont SNC 712 (Cheltuieli comerciale)
         → Trimite la divizii (vinul → bar, tapas → kitchen-cold)

21:08  Vinul deschis și servit
21:14  Tapas livrat

21:30  Familia VIP comandă restul mesei normal (preparate plătite)
22:30  Cere nota

22:31  Tatiana încasează:
         Coș pre-populat:
           - Liniile gratuite apar cu mențiunea "ofertă casă", preț 0 MDL
           - Restul liniilor cu prețuri normale
         Total fiscal: 850 MDL (fără gratuități)
         Familia plătește 850 MDL card

       Bon fiscal afișează:
         "Cabernet 2018 ............ 0.00 MDL (ofertă casă)"
         "Platou tapas .............. 0.00 MDL (ofertă casă)"
         (alternativ, configurabil: liniile gratuite să fie filtrate complet)

       În raport de tură:
         Vânzări reale: 850 MDL
         Cont 712 (gratuități): 230 MDL (vin 180 + tapas 50)

• Cheia:* decizia patronului → prag → aprobare manager → contabilizare corectă. Patronul / managerul vede în raportul lunar valoarea gratuităților oferite (poate decide dacă strategia merită).

• Referință vizuală — pas cu pas:*

Toggle-ul gift se aplică per linie în Order View (chelner). Configurabilitatea globală (activare/dezactivare feature) se face prin SharedRef horeca-orders.gift.enabled (default ON) — vezi Configurări versionate.

Scenariu 4 — Dezbatere între ospătar și client (re-fa)

• Context:* Pizza vine la masă, clientul spune "am cerut fără ceapă, asta e cu".

20:18  Pizza Diavola gata (cu ceapă)
20:19  Maria livrează la masă
20:20  Clientul: "Eu am zis fără ceapă"

       Maria verifică în comandă: nu a notat "fără ceapă"
       → totuși, decide să o refacă (politică restaurant: client întotdeauna
         are dreptate dacă diferență < 100 MDL)

20:21  Maria atinge "Re-fa" pe bonul Pizza Diavola
       Sistemul:
         → Marchează bonul curent ca "respins client" → pierdere 95 MDL,
           cont SNC 714, motiv "respins_client"
         → Generează bon nou kitchen-hot: Pizza Diavola, observație "FĂRĂ CEAPĂ" (boldăt vizibil)

20:21  Vlad (bucătar) — Acceptă bonul nou, vede observația
20:21  Vlad — Start (consumul ingredientelor a doua oară)
20:32  Pizza nouă gata
20:33  Maria livrează — clientul mulțumit

22:00  La nota:
         Pizza Diavola pe bon: 95 MDL (1 buc., a doua)
         Restul comenzii normal

       În raport de tură:
         Pierdere "respins_client": 95 MDL
         (Patronul vede în rapoarte: săptămâna asta, 3 re-fa pizza —
          investighează: bucătar nou? meniu neclar?)

• Referință vizuală + Notă onestă:*

Nu există astăzi un buton dedicat "Re-fa" în UI. Fluxul de re-preparare cu pierdere se face manual în 2 pași:

1. Chelnerul (sau bucătarul) apasă ✚ Loss pe bonul curent din Kitchen tab, motiv = respins_client, comentariu cu detalii (ex: "cu ceapă, cerută fără").
2. Chelnerul revine în Order View + adaugă din nou linia cu produsul refuzat, ideal cu notă custom ("FĂRĂ CEAPĂ" bold) în câmpul de note al liniei (dacă activat), apoi apasă Trimite spre bucătărie.

Loss-ul intră automat în raportul de tură (contul SNC 714) și în Reports → Loss anomaly detection pentru monitorizare.

Notă: un buton one-click "Re-fa" care combină cei 2 pași într-un flow ghidat (cu transfer automat al notei custom) nu e accesibil în mod implicit la moment — ⚙️ dezvoltabil la cerere.

Scenariu 5 — Bucătar refuză bon (out-of-stock)

• Context:* Cineva comandă "vin Cabernet 2018" — la bar s-a terminat.

20:45  Comanda 8 trimisă → bon bar pentru "Cabernet 2018, 1 sticlă"
20:45  Mihai (barman) — vede că s-a terminat → atinge **Refuză**
       Alege motiv: out-of-stock
       Comentariu opțional: "ultima vândută acum 5 min"

20:45:30  Maria (chelner) primește alertă: "Bon refuzat: Cabernet 2018, motiv out-of-stock"
       Maria merge la masă: "Vinul Cabernet s-a terminat, vă recomand Merlot 2019 sau
       Cabernet 2019 (similar, 50 MDL diferență)"

20:48  Clientul alege Merlot 2019
       Maria modifică comanda: șterge linia anulată, adaugă Merlot 2019, Trimite
       → Bon nou bar pentru Merlot 2019

20:49  Mihai — Acceptă, Start, Gata, Livrat

       În raport de tură:
         Refuzuri: 1 (Cabernet 2018, out-of-stock)
         Acțiune sugerată: "Re-comandă Cabernet 2018 înainte de weekend"
         (sistem detectează automat din alertele de stoc)

• Referință vizuală — pas cu pas:*

Butonul ↩ Anulează bon (kitchen tab, action row per bon) deschide un dialog cu motiv + notă opțională. Alertele către chelner apar în Notifications Watcher în timp real. Sugestia "re-comandă X înainte de weekend" nu e accesibilă în mod implicit la moment ca automatizare — apare în raportul de refuzuri consultat manual.

Scenariu 6 — Personal mănâncă (masa de tură)

• Context:* La final de tură seara, bucătarii mănâncă rămășițe sau preparate ad-hoc.

23:30  Manager Andrei deschide ecranul **Înregistrează consum personal**
       Selectează:
         - Vlad: 1 pizza (mică, restantă)
         - Daria: 1 salată
         - Mihai: 1 sandwich
         - Tatiana: 1 platou tapas
       Motiv: autoconsum_personal
       Notă: "Masa de tură, 23/04 seară"

       Sistemul:
         → Generează bon de consum standalone
         → Decrementează stocul ingredientelor (BOM explodat)
         → Cont SNC 713 (Cheltuieli administrative)
         → NU necesită aprobare suplimentară (sub prag)

23:31  Confirmat → în raport de tură "Autoconsum: 4 mese, 60 MDL valoare"

• Referință vizuală — pas cu pas:*

Consumul personal + orice altă pierdere netă de bon de bucătărie (pahar spart, stoc expirat) se înregistrează prin card-ul ✚ Standalone loss / writeoff din tab-ul Orders:

• Câmpul LINKED COMANDA* este opțional — folosit când pierderea e scoped la o masă anume (ex: "pahar spart la masa 5"). Fără link, loss-ul apare ca standalone în raport (contul SNC 713 pentru autoconsum sau 714 pentru pierderi accidentale — configurabil per reason în POS settings).

Scenariu 7 — Storno bon emis greșit

• Context:* Casier emite bon greșit (a tastat greșit metoda plată — a marcat cash în loc de card).

22:15  Tatiana emite bon fiscal pentru Masa 12: 580 MDL cash
22:16  Realizează: "Am marcat cash, dar ei au plătit card"
       → cash-ul în casă nu va corespunde

22:16  Tatiana cheamă Andrei (manager) — necesar pentru storno
22:17  Andrei aprobă storno total
       Sistemul:
         → Sistemul ghidează generarea bonului de storno (selectare bon, motiv, sume); casierul execută pe casa de marcat fiscală conform procedurii SFS (flux semi-asistat)
         → Restituie cash în casă (logic, fără să dea efectiv bani — clientul a plecat)
         → Reactivează Comanda Masa 12 (din "plătită" în "pending-bill")

22:18  Tatiana re-emite bon: aceleași linii, dar metodă plată = card 580 MDL
22:18  Bon fiscal nou OK, comanda → plătită

       În raport de tură:
         Storno-uri: 1 (motiv: corecție casier)
         Cash: 5.510 MDL (corect, fără diferență)
         Card: 6.250 MDL

• Referință vizuală + Notă importantă:*

Nu există astăzi un buton "Storno" în UI-ul HoReCa sau POS-Fiscal — storno-ul e strict semi-asistat:

1. Bonul fiscal e emis pe casa de marcat fiscală certificată (Intelect-Soft MCR sau echivalent).
2. Storno-ul se execută manual pe casa de marcat conform procedurii SFS (buton fizic sau meniu pe MCR).
3. Sistemul detectează bonul de storno prin sincronizarea cu SFS (device sync / MEV push).
4. Notifications Watcher afișează evenimentul fiscal_storno_success sau fiscal_storno_failed în panel.
5. Comanda plătită se reactivează manual (necesită permisiune manager) pentru re-emitere corectă.

Comanda plătită apare în tab Billing. Reactivarea + re-emiterea sunt operațiuni distincte care necesită coordonare între manager (aprobare) și casier (execuție pe MCR).

Notă onestă: ghidarea UI vizuală (wizard pas cu pas pentru storno) nu e accesibilă în mod implicit la moment. Ce oferim: auto-detectare + logare a storno-ului efectuat pe MCR + notificare + audit inalterabil. Un flow UI ghidat pentru storno (înainte de execuție pe MCR) e ⚙️ dezvoltabil la cerere.

Concluzii

Toate aceste scenarii sunt gestionate nativ de sistem, cu:

• Workflow ghidat pentru operator (nu inventează ceva nou).
• Contabilizare automată corectă (fiecare pierdere → contul SNC potrivit).
• Audit complet (cine, ce, când, de ce).
• Aprobări la nivelul corect (manager pentru excepții, automat pentru cazurile clare).

Pentru scenarii foarte specifice afacerii tale → discutăm la onboarding și configurăm fluxurile speciale.

Următorul pas

→ BOM & Producție sau Tarife.