Raportul de închidere a turei

Ce este "raportul de închidere"

La sfârșitul unei zile de lucru (per calendar-date × POS), manager_tură atinge Închide tura și sistemul persistă un snapshot agregat imutabil cu:

Rapoartele complementare — tipping split per chelner, detecție anomalii pierderi, agregare lunară — se rulează separat, on-demand, din același Reports tab (vezi mai jos). Jurnalul contabil SNC (defalcare pe conturi 611/711/etc.) nu e generat de sistem la moment; vezi secțiunea "Format export" și pagina Raport de schimb.

Notă terminologică: în cod, o "tură" este un snapshot retrospectiv per calendar-date × POS, nu o entitate live cu stare "deschisă". În timpul zilei, activitatea trăiește în Comandas + folder:invoice; snapshot-ul se cristalizează doar la Close.

Cum se închide o tură

  1. Manager_tură atinge Închide tura (butonul apare doar cu permisiunea corespunzătoare pe POS — vezi Permisiuni).
  2. Alege data (default: azi) și POS-ul (default: toate).
  3. Sistemul scanează activitatea zilei (bonuri de producție, vânzare, pierderi, transferuri, aprovizionări, transformări) filtrată pe stage-uri finalizate (updated-stock / ready / done) și calculează totalurile.
  4. Creează un folder de arhivă imutabil <date>-<pos|all>-<uid> sub archive/HoReCaShifts/<an>/<lună>/ conținând snapshot-ul journal.
  5. Rezultatul se afișează inline și rămâne consultabil oricând din lista Past closed shifts.

Ce interval acoperă o tură

Raportul acoperă intervalul dintre închiderea precedentă și momentul curent, nu ziua calendaristică. Consecințele practice, pentru localurile care lucrează în două ture:

Când închiderea se face pentru toate POS-urile deodată, fiecare POS repornește de la propria lui ultimă închidere. Dacă managerul de la terasă a închis deja la 14:00, iar la 22:00 se face o închidere generală, terasa contribuie doar cu ce a vândut după 14:00, în timp ce sălile neînchise contribuie cu toată ziua. Nicio vânzare nu se numără de două ori și niciuna nu rămâne pe dinafară, indiferent de ordinea în care se fac închiderile.

Conținut raport Important — filtrare, nu blocaj: operațiile din ziua respectivă care nu sunt finalizate (comenzi încă deschise, bonuri de producție în pregătire, receipts care încă nu au ajuns la Z) nu sunt incluse în snapshot — dar nici nu blochează închiderea. Butonul nu verifică starea comenzilor, a bonurilor de producție sau a Z-ului MCR și nu refuză niciodată operațiunea. Responsabilitatea de a face un close pe activitate "curată" (comenzi plătite, bonuri livrate, Z-ul MCR emis pentru ziua respectivă) rămâne integral la manager_tură.

Snapshot imutabil — ce trebuie să știi

Permisiuni

Butonul Închide tura și cardurile din tab-ul Reports apar doar cu:

Rolul standard care le agregă este role_horeca_manager_tura.

Conținut snapshot

Secțiunea 1 — Vânzări și subtypuri

╔═══════════════════════════════════════════════════╗
║  TURA  23 aprilie 2026 · POS-sala  (all)          ║
╠═══════════════════════════════════════════════════╣
║  Bonuri fiscale:                   42              ║
║  Total revenue încasat:       12.450 MDL           ║
║                                                    ║
║  Agregat pe subtype bon (rows / qty / cost):       ║
║    sell         38 rows   qty 187   cost  6.240    ║
║    ecommerce     4 rows   qty  12   cost    380    ║
║    production   22 rows   qty  47   cost  2.150    ║
║    writeoff      6 rows   qty   9   cost    285    ║
║    transfer      2 rows   qty   6   cost    120    ║
║    supply        3 rows   qty  15   cost    980    ║
║    transform     1 row    qty   2   cost     40    ║
╚═══════════════════════════════════════════════════╝

Secțiunea 2 — Productivitate stații (⚙️ activabil la cerere)

Analiza per stație de bucătărie (kitchen-hot / cold / bar / dessert) — timp mediu preparat per bon, cel mai rapid / cel mai lent, refuzuri out-of-stock, re-preparate — nu este disponibilă în snapshot-ul curent. Journal-ul agregă pe subtype de bon și pe MPN, dar nu pe stație și nu captează prep-time.
Această vedere se poate dezvolta la cerere, cu definirea împreună cu clientul a: (a) sursei de tagging stație pe bon, (b) evenimentului de start/stop preparat, (c) taxonomiei de refuzuri/re-preparate.

Secțiunea 3 — Pierderi

╔═══════════════════════════════════════════════════╗
║  PIERDERI  (agregat writeoff)                     ║
╠═══════════════════════════════════════════════════╣
║  Total pierderi:  cost 285 MDL   qty 9 unități    ║
║                                                    ║
║  Top MPN-uri cu cele mai multe evenimente:        ║
║    Tiramisu           4 evenimente   qty 4        ║
║    Vin Cabernet       2 evenimente   qty 2        ║
║    Pahar Bordeaux     3 evenimente   qty 3        ║
║    ...                                            ║
║  (max 10 rânduri, sortat descrescător după qty)   ║
╚═══════════════════════════════════════════════════╝

Analiza contextuală (ex. "MPN X are astăzi de 4× mai multe pierderi decât media") se face rulând separat cardul 🚨 Detecție anomalii pierderi (vezi Secțiunea 4).

Secțiunea 4 — Anomalii detectate (best-effort)

Detecția automată este best-effort — nu garantăm că va identifica orice tip de anomalie (furt subtil, fraudă coordonată, pattern-uri rare). Rămâne responsabilitatea managerului / proprietarului să facă audit final independent.
Detectorul de pierderi (raport dedicat "🚨 Detecție anomalii pierderi" în panoul HoReCa) compară pierderile zilei curente cu media + deviația standard a ultimelor N zile (configurabil 3–30):

Exemplu real de output al detectorului de pierderi:

╔═══════════════════════════════════════════════════╗
║  ANOMALII PIERDERI  (window 7d · threshold 1× σ)  ║
╠═══════════════════════════════════════════════════╣
║  🔴 alert  Tiramisu                                ║
║      azi: 4 pierderi   media 7z: 0.5   σ: 0.9     ║
║      → depășește media + 2× stddev                ║
║                                                    ║
║  🟠 warn   Vin Cabernet                            ║
║      azi: 2 pierderi   media 7z: 0.4   σ: 0.7     ║
║      → între media + 1× și + 2× stddev            ║
╚═══════════════════════════════════════════════════╝

Secțiunea 5 — Tip / bacșiș per chelner

╔═══════════════════════════════════════════════════╗
║  TIPS  20-26 apr 2026 · POS-sala · tip 10%        ║
╠═══════════════════════════════════════════════════╣
║  WAITER          ORDERS   GROSS      AVG    TIP@10%║
║  Maria Cojocaru      12   2.850    237.5     285   ║
║  Ion Petrov          18   4.200    233.3     420   ║
║  Andrei               5   1.100    220.0     110   ║
║  ─────────────────────────────────────────────    ║
║  TOTAL               35   8.150               815   ║
╚═══════════════════════════════════════════════════╝

Cardul e strict un helper de calcul on-demand, nu un ledger — tip%-ul e parametru de raportare (10% default, ajustabil pe loc), nu se stochează pe comandă. Splitarea între chelneri și bucătărie / distribuția fizică efectivă rămâne responsabilitatea manager_tură — sistemul oferă baza de calcul, nu operațiunea de payout.
Raportul de distribuție tipping se generează interactiv din panoul HoReCa: managerul alege intervalul — cu dată și oră, astfel încât o tură de noapte care trece de miezul nopții (de exemplu 18:00 → 02:00) se cere ca un singur interval — POS-ul (opțional), și procentul țintă (default 10%) — sistemul agregă comenzile plătite din interval, le grupează pe chelner și afișează:

Comenzile intră în interval după momentul deschiderii lor. Tabelul include un footer cu totalul echipei. Procentul nu se stochează pe comandă — e parametru de raportare, ajustabil pe loc dacă politica locală variază (10% pentru week-end, 12% pentru petreceri private etc.).

Secțiunea 6 — Reconciliere cash (⚙️ dezvoltare custom la cerere)

Reconcilierea automată a numerarului fizic (cash-așteptat calculat din opening float + colectări + tip cash, comparat cu numărat fizic, alertă la diferență peste prag) nu este disponibilă în v1 curent.
Fluxul actual: casierul face colectările din pos-cash-register (define / collect / bank-collect / refund) în mod manual, iar reconcilierea cu Z-ul MCR se face vizual, nu automat. Snapshot-ul de tură nu include un card de cash reconciliation.
Acest modul poate fi activat custom la cerere, cu definirea împreună cu clientul a: (a) formulei de calcul cash-așteptat, (b) pragului de alertă, (c) fluxului de aprobare / motiv diferență.

Tur vizual — Reports tab (live)

Tab-ul 📊 Reports din HoReCa Dashboard oferă mai multe carduri operaționale, toate rulate on-demand cu output vizibil imediat în UI.
Reports tab overview

Shift close + accounting journal

Închiderea unei ture generează raportul turei și îl păstrează ca document reidentificabil oricând. Antetul arată cine a închis, când, și ce interval acoperă; sub el, o linie de sumar cu bonurile fiscale, venitul, costul și marja.
Datele se citesc în patru moduri de grupare, comutabile dintr-un click, fără regenerarea raportului:

Mod Răspunde la întrebarea
Per tip de document Cât a intrat, cât a ieșit, cât s-a produs, cât s-a pierdut
Per produs Ce s-a mișcat efectiv — cantitate, cost, venit, pierderi, pe fiecare articol
Per utilizator Cine a emis documentele turei și cât reprezintă fiecare
Pierderi Articolele cu pierderi, ordonate după cantitate

Fiecare mod afișează implicit coloanele esențiale și ține restul ascunse — marjă, marjă procentuală, cotă din venit, preț mediu, cost mediu, cost pe rând. Se activează din setările tabelului, per utilizator, și rămân așa la următoarea deschidere. Tabelele au căutare, sortare și paginare, iar codurile de produs sunt clicabile direct spre fișa articolului.
Modul ales rămâne selectat și când se deschide o altă tură — managerul care lucrează „per produs" nu trebuie să comute de fiecare dată.
Pas 1 — Cursor pe butonul Close shift
Pas 2 — Tura închisă: antet cu momentul închiderii și intervalul acoperit, urmat de tabelul de agregare

Ture închise — istoricul

Lista turelor închise stă sub rapoarte și se reîncarcă la cerere, fără reîmprospătarea paginii. Afișează implicit data, momentul închiderii, POS-ul, numărul de bonuri, venitul și cine a închis; ascunse, dar disponibile din setările tabelului: intervalul acoperit, costul, marja, numărul de rânduri, tipurile de documente și pierderile. Din fiecare rând se redeschide raportul salvat, exact cum a fost generat.
Ștergerea unei ture închise este posibilă doar pentru rolurile cărora li s-a acordat explicit acest drept — nu e inclus în dreptul de a închide ture. Motivul e simplu: raportul turei e singura sursă a agregării lunare, iar o tură ștearsă schimbă totalul lunii și nu poate fi refăcută identic. Butonul apare doar acolo unde dreptul există, iar pentru drepturile limitate la un POS apare doar pe turele acelui POS.

Waiter tipping split

Calculează split-ul de tip între chelneri într-un interval, cu procent tip% configurabil. Contorizează comenzi în stage paid + pending-bill grupate pe chelner.
Pas 3 — Cursor pe butonul Compute split (Tip 10% default)
Pas 4 — Rezultat live: tabel WAITER / ORDERS / GROSS / AVG per order / TIP @ 10%. Real data: admin — 5 comenzi, gross 170.56 MDL, tip 17.06 MDL

Loss anomaly detection

Detector rolling-window pentru pierderi anormale. Compară pierderea zilei curente vs. media ultimelor N zile (stddev-based threshold, threshold multiplier configurabil — default 1.0σ warn / 2.0σ alert, minimum 0.5σ). MPN-urile cu < 3 zile istoric sunt sărite.
Pas 5 — Cursor pe butonul 🚨 Scan (window 7d, threshold 1× stddev, all POSes)
Pas 6 — Rezultat: "Loss anomalies — window 7d · threshold 1× · scanned 0 folder(s)" + mesaj verde "✅ No anomalies — every MPN's today losses are within the historical envelope"

Month-end aggregation

Cardul 🗓 Month-end rulează un roll-up peste toate turele închise ale unei luni (sau doar cele ale unui POS ales). Nu re-scanează bonurile — citește direct blob-urile journal salvate la Close, deci e rapid și consistent cu snapshot-urile persistate. Output-ul păstrează aceeași structură (subtypeTotals, topLosses merge-uite pe MPN) plus date meta: număr shifts, listă date, interval start/end.
Acest card este expus și ca MCP tool horeca_shift_month pentru integrări (agenti / rapoarte externe).

Past closed shifts

Tabelul 📚 Past closed shifts listează toate folder-ele folder:horeca:shift create vreodată — Name / POS / Data close / Labels + acțiune 👁 View journal care re-hidratează snapshot-ul din blob-ul stocat (nu recalculează). Util pentru: audit, comparație vizuală, redeschidere raport de care e nevoie ulterior.

Format export — ⚙️ la cerere

Raportul de închidere se vizualizează astăzi în UI la momentul Close Shift sau prin re-View din Past closed shifts. Formatele de export:

Notă onestă: generarea jurnalului contabil în format SNC (conturi 611, 5344, 221, 711, 712, 713, 714, 211, 216) + export pentru softuri contabile (1C, SAGA, BAS, InfoCont, WizCount) nu este accesibilă în mod implicit — snapshot-ul actual e agregat pe subtype de bon, fără split per-linie pe cont contabil. Vezi Raport de schimb (agregat operațional) pentru context complet.

Comparare cu turele anterioare (⚙️ dezvoltare la cerere)

Vederile de comparație (azi vs. ieri, aceeași zi săptămâna trecută, trend săptămânal/lunar) nu sunt implementate în v1. Ca punct de plecare există agregarea lunară Month-end (roll-up plat peste toate turele lunii) — util pentru volumul lunii, dar fără delta-uri sau grafice de trend.
Vederi comparative dedicate (delta zi-de-zi, ranking, trending) sunt dezvoltare custom, activabilă la cerere după validarea metricelor cheie cu manager_tură. Util în principal pentru:

Rapoarte agregate multi-locație (⚙️ dezvoltare la cerere)

Curent, cardul Month-end poate rula fie pe un POS specific, fie pe toate POS-urile la nivel de lanț (roll-up plat). Vederile dedicate manager regional — comparație per-locație vs. media lanțului, cross-locație per-categorie produse, ranking locații — sunt dezvoltare custom, dimensionată împreună cu clientul în funcție de numărul de locații și metricele cheie.

Următorul pas

→ Scenarii end-to-end sau SNC Moldova.

sgapps.io