Scenarii end-to-end

Scenariu 1 — Masa progresivă (3 valuri)

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

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

Tab Orders

New order form gol

Formular completat

Cursor pe butonul Open

Comandă creată — toast confirmă

2. Intrare pe Order View

Cursor pe View

Order View deschis

3. Adăugare produs pe Comandă

Add-line gol

Focus pe search

Rezultate filtrate

Cursor pe rezultat

Preview produs

Info TVA populat

Cursor pe Adaugă

Linie adăugată

4. Trimitere spre bucătărie

Cursor pe Trimite spre bucătărie

Bonuri create — toast succes

Status wip pe linie

5. Bucătarul preia + marchează Ready

Tab Kitchen

Bon în queue Kitchen

Cursor pe next-stage

Kitchen queue după avansare

6. Emitere fiscală

Cursor pe Pre-bill

Cursor pe Open in POS-Fiscal

POS-Fiscal cu coș pre-populat

Scenariu 2 — Cancel mid-prep cu pierdere

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

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.
Pas 1 — Kitchen tab overview
Pas 2 — Cursor pe butonul 👁 View
Pas 3 — Navigat la Order View (K-11) — Comanda details, Order lines, Add line — bonul original e implicit acolo (linie cu status PENDING)

Butonul ✚ Loss

Butonul ✚ Loss (Kitchen tab, per bon production) deschide dialogul Production-tied loss care înregistrează un writeoff row în folder-ul de bon:
Pas 1 — Kitchen tab cu bon production
Pas 2 — Cursor pe butonul ✚ Loss
Pas 3 — Dialog Production-tied loss cu PRODUCT / QTY (SIGNED) / COMMENT / REASON (dropdown cu motivele configurate în POS) / APPLY STOCK DELTA NOW checkbox / SAVE LOSS button

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

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)

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.
Pas 1 — Order View cu 2 linii (Latte + Cappuccino), buton "⃝ gift" gri pe fiecare
Pas 2 — Cursor pe butonul gift al liniei Latte
Pas 3 — Linie Latte marcată gift (buton "🎁 gift" purple, preț 0.00, toast "Linie marcată gift 🎁")
Pas 4 — Order lines după toggle: Latte 0.00 (gift), Cappuccino 35.00, TOTAL DE PLATĂ 35.00

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

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?)

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)

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)

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.
Pas 1 — Kitchen tab cu bon în validated-mpns
Pas 2 — Cursor pe butonul ↩ Anulează bon
Pas 3 — Dialog "Anulează bon de bucătărie" cu Motiv + Notă opțional + butoane NU ANULA / CONFIRMĂ ANULAREA

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

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"

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:
Pas 1 — Cursor pe butonul ✚ Add standalone loss
Pas 2 — Dialog Standalone loss cu PRODUCT search, QTY SIGNED (default -1), COMMENT, REASON (dropdown cu motivele configurate: anulare_client, autoconsum_personal, spart, expirat, etc.), APPLY STOCK DELTA NOW checkbox, POS selector, LINKED COMANDA optional

Scenariu 7 — Storno bon emis greșit

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

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:

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

Următorul pas

→ BOM & Producție sau Tarife.