Vânzări total
Numărul de bonuri fiscale emise în interval și venitul total încasat în MDL. E prima linie pe care managerul o vede la Close — dacă cifra „arată bine", detaliile de sub ea confirmă.
Un snapshot imutabil per zi × POS — bonuri fiscale, venit total, apoi agregare pe șapte subtipuri de bon (vânzare, e-commerce, producție consumată, pierderi, transferuri, aprovizionări, transformări) și un top al articolelor cu pierderi. Managerul îl citește în patru moduri de grupare comutabile dintr-un click. Snapshot-ul rămâne consultabil oricând, iar la sfârșit de lună se face roll-up peste toate turele închise.
Raportul agregă activitatea finalizată a zilei într-o formă contabilă compactă. Nu e o listă lungă de bonuri — e o vedere sintetică pe care patronul o poate citi în 2 minute.
Numărul de bonuri fiscale emise în interval și venitul total încasat în MDL. E prima linie pe care managerul o vede la Close — dacă cifra „arată bine", detaliile de sub ea confirmă.
Agregat cost + cantitate pentru bonurile de producție finalizate (preparatele care au ieșit din bucătărie și au fost consumate în vânzări). Baza pentru marjă și pentru randamentul rețetelor.
Cost și cantitate totală a pierderilor înregistrate în zi (căzut, ars, expirat, degustare) plus top articole cu cele mai multe evenimente de pierdere, ordonate descrescător după cantitate.
Agregat rânduri, cantitate, cost pe fiecare subtip de bon de stoc: intrări noi de la furnizori, transferuri între depozite / unități, transformări (materie primă în semipreparat).
Notă onestă: defalcarea pe metodă de plată (numerar / card / transfer), pe categorie de meniu (pizza / paste), calculul TVA net vs. inclus, numărul estimat de clienți și cec-ul mediu nu sunt în snapshot-ul standard — v1 se concentrează pe agregarea pe subtip de bon. Aceste vederi sunt ⚙️ activabile la cerere, cu prioritizare după impactul real pentru tine.
Datele se citesc în patru vederi comutabile fără regenerarea raportului. 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ă.
Răspunde la „cât a intrat, cât a ieșit, cât s-a produs, cât s-a pierdut". Vederea contabilă naturală, cu o linie per subtip de bon. Bună pentru raportul de sfârșit de zi transmis către proprietar.
Răspunde la „ce s-a mișcat efectiv" — cantitate, cost, venit, pierderi, pe fiecare articol. Vederea operațională pentru responsabilul de stoc: ce a rulat, ce a stagnat, ce s-a irosit.
Răspunde la „cine a emis documentele turei și cât reprezintă fiecare". Baza pentru analiza productivității echipei fără să expună chelnerilor rapoarte financiare — vederea rămâne la manager.
Articolele cu pierderi, ordonate după cantitate. Managerul vede imediat unde s-a irosit cel mai mult în zi și poate cere motivul, fără să deschidă bonurile unul câte unul.
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). Vizibilitatea coloanelor se activează din setările tabelului, per utilizator, și se ține minte data următoare. Tabelele au căutare, sortare, paginare, iar codurile de produs sunt clicabile spre fișa articolului.
Managerul de tură atinge Închide tura, alege ziua (implicit azi) și POS-ul (implicit toate). Sistemul scanează activitatea zilei filtrată pe stagiile finalizate și persistă snapshot-ul într-un folder de arhivă imutabil. Rezultatul apare inline și rămâne consultabil oricând.
Butonul nu verifică starea comenzilor, a bonurilor de producție sau a Z-ului casei de marcat, și nu refuză niciodată operațiunea. Comenzile încă deschise, bonurile în pregătire, receipts fără Z — rămân în afara snapshot-ului, dar nu împiedică managerul să închidă.
Blob-ul salvat este adevărul contabil de referință la momentul emiterii. Dacă un bon din ziua respectivă e rectificat ulterior, journal-ul salvat nu se auto-refresh — pentru a reflecta noua realitate se rulează Închide tura din nou pe aceeași zi + POS.
Fiecare rulare creează un folder nou cu identificator propriu, fără auto-deduplicare. Snapshot-ul cel mai recent e considerat curent, cele anterioare rămân în arhivă pentru audit trail. Recomandarea: un singur Close per zi × POS.
Raportul acoperă intervalul dintre închiderea precedentă și momentul curent, nu ziua calendaristică. Într-un local cu două ture, a doua închidere pornește de unde s-a oprit prima — nicio vânzare nu se numără de două ori.
Un bistro cu tură de zi și tură de seară închide de două ori. Iată cum se comportă sistemul, pas cu pas — și de ce nu apar duplicate.
08:00 — bistro-ul deschide. Chelnerii de zi încep să deservească.
16:00 — managerul de zi face Close. Snapshot generat pentru intervalul 00:00 → 16:00: bonuri fiscale, venit, producție, pierderi. Se arhivează. Chelnerii de seară intră în tură.
16:00 → 24:00 — activitatea continuă normal. Comenzi noi, bonuri fiscale noi. Snapshot-ul de dimineață nu se atinge — e frozen.
23:45 — managerul de seară face Close. Snapshot generat pentru intervalul 16:00 → 23:45, nu 00:00 → 23:45. Bonurile din tura de dimineață nu reapar.
Când Close-ul se face pentru toate POS-urile deodată (ex. o închidere generală la 22:00), fiecare POS repornește de la propria lui ultimă închidere. Dacă terasa a închis deja la 14:00, ea contribuie la închiderea generală doar cu vânzările de după 14:00, în timp ce sala care n-a închis contribuie cu toată ziua. Nicio vânzare pierdută, nicio dublă contorizare — indiferent de ordinea în care se fac Close-urile.
Snapshot-ul intră în două fluxuri operaționale: lista istorică Past closed shifts pentru redeschidere oricând, și Month-end pentru roll-up-ul de sfârșit de lună.
Toate turele închise vreodată apar într-un tabel: 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, pierderile. Din fiecare rând se redeschide raportul exact cum a fost generat — sistemul rehidratează snapshot-ul salvat, nu recalculează.
Cardul de sfârșit de lună agregă toate turele închise dintr-o lună (sau doar cele ale unui POS ales). Nu re-scanează bonurile — citește direct snapshot-urile persistate la Close, deci e rapid și consistent cu ce a văzut managerul în ziua respectivă. Output-ul păstrează aceeași structură (subtipuri, top pierderi merge-uite pe articol) plus meta: număr de ture, listă de date, interval start / end.
Ștergerea unei ture închise este un drept separat de dreptul de a închide ture — motivul: raportul turei e sursa agregării lunare, iar o tură ștearsă schimbă totalul lunii și nu poate fi refăcută identic. Butonul apare doar acolo unde acest drept e acordat explicit.
Închiderea turei HoReCa este un snapshot managerial per zi × POS. Nu emite Z-ul casei de marcat, nu așteaptă Z-ul, nu îl verifică. Z-ul rămâne operațiunea fizică zilnică a aparatului MCR, complet independentă.
Practic: managerul de tură face Close-ul HoReCa după ce casierul a rulat Z-ul fizic al zilei — dar butonul din ERP nu așteaptă și nu blochează. Cele două fluxuri se închid separat, fiecare pe responsabilitatea rolului lui. Curățenia zilei rămâne integral la managerul de tură.
Accesul e configurat conservator prin roluri — noi facem configurarea la onboarding, zero sarcină tehnică din partea ta.
Rolul standard care închide tura, vede raportul complet, comută între cele 4 moduri de grupare, deschide turele istorice și rulează roll-up-ul lunar. Se poate limita per POS — un manager de terasă vede și acționează doar pe terasă.
Vede tot, poate acorda dreptul separat de ștergere ture închise (utilizat rar, doar în cazuri de rectificare cu impact contabil). Preferăm ca acest drept să rămână la contul cu responsabilitate contabilă, nu pe managerul operațional zilnic.
Nu au acces la Închide tura și nu văd rapoartele financiare per default. Chelnerul își vede istoria proprie pe ziua curentă; bucătarul își vede kitchen-display-ul; casierul își vede operațiunile de casă. Rapoartele rămân la manager, prin design.
Da — datele tabelare se exportă în CSV, XLS și XLSX direct din UI (tabelul raportului sau din Past closed shifts la redeschidere). PDF, JSON pentru integrări și XML pentru jurnal SNC sunt dezvoltări custom (⚙️ activabile la cerere, cotate după discovery). Trimiterea automată pe e-mail / Telegram la închiderea turei — la fel, job programat adăugabil.
Nu, nu în mod implicit. Snapshot-ul curent e agregat pe subtip de bon, fără split per-linie pe conturi contabile moldovenești. Generarea jurnalului SNC + exportul pentru softuri contabile (1C, SAGA, BAS, InfoCont, WizCount) este dezvoltare ⚙️ la cerere, dimensionată în funcție de fluxul contabil concret al firmei tale.
⚙️ În pregătire. Vederile de comparație (delta zi-de-zi, trending săptămânal, ranking) sunt dezvoltare custom, activabilă după validarea metricelor cheie cu managerul tău. Ca punct de plecare există roll-up-ul lunar Month-end — util pentru volumul lunii, fără delta-uri sau grafice.
Da, la nivel lunar. Cardul Month-end poate rula pe toate POS-urile lanțului sau doar pe unul ales. Vederile dedicate manager regional (comparație per-locație vs. media lanțului, ranking, cross-locație per-categorie de produse) sunt dezvoltare custom, dimensionată împreună cu tine în funcție de numărul de locații și metricele care contează.
Rămân deschise și în afara snapshot-ului. Sistemul filtrează pe stagiile finalizate (livrat / gata / actualizat stoc). Comenzile neterminate continuă normal a doua zi (sau în tura următoare); când se finalizează, vor intra în snapshot-ul turei corespunzătoare. Nu se pierd, nu se blochează.
Snapshot-ul cel mai recent e considerat curent. Duplicatul rămâne în arhivă pentru audit trail. Ștergerea unei ture închise se face din UI, dar necesită autorizație separată (rezervată de obicei administratorului sau contului cu responsabilitate contabilă) — motivul e că raportul turei intră în agregarea lunară, iar o ștergere schimbă totalul lunii.
Raportul de închidere tură cu 4 moduri de grupare + roll-up lunar face parte din Pachet Extra HoReCa (nu din Micro / Start, care sunt orientate pe retail simplu). Configurarea rolurilor și accesul la Close le facem noi la onboarding — fără sarcină tehnică din partea ta. Comparație pachete + preț curent → vezi pagina de tarife.
Îți arătăm cum arată raportul turei pe un local demo și discutăm ce metrice contează pentru tine. Export CSV, XLS, XLSX pentru contabil e inclus în pachet. Pentru orice ⚙️ la cerere (PDF, jurnal SNC, integrări custom, comparație zi-de-zi, raport consolidat multi-locație), cotăm după discovery.
SGAPPS LABS SRL · Chișinău, Moldova · Producție continuă din 2018 · POS · ERP · Casă fiscală MEV · Android fleet