Scenarii end-to-end

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

Notă despre „raportul de tură" invocat în scenariile de mai jos: toate mențiunile se referă la snapshotul retrospectiv creat atunci când role_horeca_manager_tura apasă Închide tura din tab-ul HoReCa → Reports (o singură dată la sfârșitul zilei, per POS). Nu există o „tură deschisă" automat; până la închidere activitatea trăiește în Comenzi + Bonuri, iar apăsarea butonului agregă retroactiv datele zilei (calendar-date × POS). Snapshotul este imuabil odată scris; re-închiderea aceleiași perechi date+POS creează un folder duplicat, nu îl suprascrie. HoReCa shift ≠ MCR Z-shift (rapoartele Z ale casei de marcat sunt artefacte separate). Pentru mecanica completă a rapoartelor (Închidere tură, Roll-up lunar, Împărțire bacșiș chelneri, Detectare anomalii pierderi) → Rapoarte tură. Permisiunea necesară: HORECA_REPORT__SHIFT_CLOSE (opțional scoped :POS:<pos-id>).

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" păstrat pe linie
           (ruta pe cont SNC 714 dedicat = ⚙️ planificată pentru faza 2)
         → 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 închidere (când managerul apasă Închide tura):
         subtypeTotals.writeoff: rows +1, cost ~95 MDL
         topLosses: Pizza Quattro Stagioni (dacă intră în top 10 pe qty)
         (Nota: v1 raportează pe subtipuri agregate — cod SNC + motiv per linie
          sunt ⚙️ planificate pentru faza 2.)

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"
           păstrat pe linie (atribuirea pe cont SNC 712 dedicat pentru
           gratuități = ⚙️ dezvoltabilă la cerere)
         → 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 raportul de închidere:
         subtypeTotals.sell.revenue: ~850 MDL (liniile „gift" cu preț 0
           nu apar ca sumă separată — reduc pur și simplu revenue-ul)
         bills.total_revenue reflectă doar sumele efectiv facturate
         (Ofertele casei se identifică din audit-ul liniei — separarea contabilă
          pe cont 712 este ⚙️ dezvoltabilă la cerere.)

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
           în subtypeTotals.writeoff cu motiv "respins_client" păstrat pe
           linie (ruta pe cont SNC 714 dedicat = ⚙️ planificată)
         → 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 raportul de închidere:
         subtypeTotals.writeoff cost +95 MDL (pizza inițială)
         Loss anomaly detection: dacă frecvența pizza-loss depășește media
           rulantă (pragul warn/alert configurabil, default 1.0σ warn /
           2.0σ alert, min 0.5σ) apare în Reports → Loss anomalies
         (Un tablou dedicat „re-fa" agregat pe săptămână nu există astăzi —
          analiza se face prin filtrarea folder:invoice writeoff pe MPN +
          comentariu. Separarea pe motiv per linie e ⚙️ planificată.)

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 subtotalul writeoff al raportului de închidere a turei și, dacă e relevant, în Reports → Loss anomaly detection pentru monitorizare (atribuirea pe cont SNC dedicat 714 este ⚙️ planificată pentru faza 2).

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 audit-ul bonurilor de bucătărie:
         Bonul Cabernet 2018 e marcat „anulat, motiv: out-of-stock"
           (accesibil în folder-ul bonului)
         (Raportul de închidere a turei nu are astăzi o secțiune „Refuzuri"
          agregată — bonurile anulate rămân filtrate din subtypeTotals
          prin filtrul de stage-uri finalizate. Sugestia de re-comandă
          automată nu e disponibilă.)

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 disponibilă la moment ca automatizare. Refuzurile se identifică prin audit-ul bonurilor de bucătărie anulate (fiecare bon anulat păstrează motiv + notă în folder-ul propriu); un „raport de refuzuri" agregat nu există astăzi.

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 standalone writeoff cu motiv „autoconsum_personal"
           (motivul se stochează pe fiecare linie și e disponibil în audit)
         → Decrementează stocul ingredientelor (BOM explodat)
         → Sub prag: fără aprobare suplimentară (limita configurabilă per POS)

23:31  Confirmat → în subtypeTotals.writeoff al raportului de închidere apare
       costul agregat (~60 MDL). Separarea „Autoconsum: 4 mese" pe motiv
       este ⚙️ planificată pentru faza 2.

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 writeoff în subtypeTotals al raportului de închidere; motivul (autoconsum_personal, spart, expirat, etc.) rămâne pe linie și e vizibil în audit. Ruta pe cont SNC per motiv (713 pentru autoconsum vs 714 pentru pierderi accidentale) este ⚙️ planificată pentru faza 2 — v1 raportează agregat pe subtip.

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:
         → Casierul identifică bonul greșit din audit-ul MCR și execută
           storno-ul pe casa de marcat fiscală conform procedurii SFS.
           Sistemul detectează bonul de storno la sincronizarea următoare
           cu MEV și îl loghează în auditul propriu (flux semi-asistat;
           un wizard UI ghidat pre-execuție este ⚙️ dezvoltabil la cerere).
         → 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ă

       Vizibilitate post-storno (două artefacte separate):
         Pe raportul Z al casei de marcat (MCR sau Z sintetic pt. driver
         virtual): paymentsByType arată cash/card corect după re-emitere
           (Cash: 5.510 MDL; Card: 6.250 MDL).
         Pe raportul de închidere HoReCa: bills.count + bills.total_revenue
           reflectă bonul reemis; audit-ul storno-ului trăiește pe folder-ul
           MCR (HoReCa shift ≠ MCR Z-shift — cele două rapoarte se citesc
           împreună).
         (Un contor „Storno-uri" agregat în raportul de închidere a turei
          HoReCa nu e implementat.)

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ă evenimentele fiscale de storno în panel (⚠️ numele exact al evenimentelor rămân de reverificat în modulul de notificări).
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 pe happy-path (comandă → trimitere → ready → livrare → pre-bill → pos-fiscal). Excepțiile — storno (Scenariu 7), re-fa (Scenariu 4) — rămân semi-asistate sau manuale în 2 pași; un flow UI complet ghidat este ⚙️ dezvoltabil la cerere pentru cazuri specifice.
• Contabilizare corectă pe subtipuri (fiecare pierdere → subtotalul writeoff al turei + topLosses; ruta pe cont SNC per motiv este ⚙️ planificată pentru faza următoare).
• Audit complet (cine, ce, când, de ce) — folder-ele folder:invoice și folder:plan:order păstrează motiv + notă + autor + timestamp pe fiecare linie / bon / snapshot.
• Aprobări la nivelul corect (manager pentru închiderea turei via HORECA_REPORT__SHIFT_CLOSE; aprobările la nivel de linie/gratuități/reactivare comandă sunt gate-uri operationale documentate separat).

Cele 4 cartonașe reale din tab-ul Reports — la care se raportează scenariile de mai sus — sunt:

• 📊 Închide tura — snapshot per calendar-date × POS (subtypeTotals + topLosses + bills).
• 🗓️ Roll-up lunar — agregare a snapshot-urilor deja închise pentru intervalul lunii.
• 💰 Împărțire bacșiș chelneri — calculator on-demand din order_count / gross_total / avg_total × procent parametrat (nu se persistă tip-ul).
• 🚨 Detectare anomalii pierderi — detector σ per MPN cu prag warn/alert configurabil, DataTable pentru tururi închise trecute + View journal.

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

Următorul pas

→ BOM & Producție sau Tarife.