Bonuri de consum + pierderi

• Cui vorbim:* bucătar-șef / manager / contabil care vor să vadă unde se duc ingredientele.

Ce este un bon de consum

Un bon de consum înregistrează decrementarea efectivă a ingredientelor dintr-o stație. Este partenerul firesc al bonului de producție — pentru fiecare bon de producție generat, sistemul produce automat un bon de consum care explodează rețeta (BOM) în ingrediente.

Cum funcționează în practică

• Pizza Margherita* are rețeta (BOM) definită ca:
• 250 g blat (din semipreparat / aluat propriu)
• 80 g sos roșii
• 100 g mozzarella
• 5 g busuioc proaspăt
• 10 ml ulei de măsline

Când bucătarul atinge Start pe bonul de producție Pizza:

1. Sistemul citește rețeta.
2. Generează automat bon de consum cu 5 rânduri (ingredientele de mai sus, cu cantitățile per pizza).
3. Decrementează stocurile (250g blat, 80g sos, etc.).
4. Logează totul ca consum productiv (mapabil contabil la contul SNC 711 — Costul vânzărilor; split per-cont SNC în raportul de tură este ⚙️ activabil la cerere).

• Bucătarul nu introduce nimic manual.* Rețeta + actul "Start" = consumul e contabilizat.

Pierderi în-flux

Pierderile sunt parte integrantă a bucătăriei. Sistemul le tratează ca rânduri suplimentare pe același bon de consum:

Cazul 1 — Bucătarul scapă o cantitate de mozzarella

În timp ce prepară Pizza Margherita, bucătarul scapă 60g mozzarella pe jos. Pe tableta lui apăsă + Adaugă pierdere:

• Produs: Mozzarella (selectat din picker cu căutare după nume / cod)
• Cantitate: −0.060 kg (cantitate negativă = scoatere din stoc — pozitivul e rezervat corecțiilor de inventar)
• Motiv: alegere dintr-o listă configurată la nivel de POS (ex: cazut_spart, expirat, ars_preparat, furt_constatat...)
• Notă rețetă: text liber pentru context (ex: "Picat la împachetare", "Batch 2026-05 expirat")
• Comentariu: text liber adițional (opțional)

Operatorul poate bifa "Aplică imediat scoaterea din stoc" — atunci pierderea decrementează direct stocul. Dacă nu bifează, pierderea rămâne în starea "așteaptă confirmare" și manager_tura o aprobă (legacy two-step). Default: nebifat — protejează stocul împotriva fat-finger-ului în momente aglomerate.
Sistemul:

• Adaugă rândul pe bonul de consum existent (același folder).
• Validează că motivul aparține listei configurate la POS (vezi Pierderi & motive). Dacă lista e goală la POS, sistemul acceptă text liber.
• Pre-calculează impactul: "Va scoate 0.060 kg din stocul de Mozzarella la POS-ul X" (live preview lângă input).
• Avertizează vizibil dacă scoaterea ar lăsa stocul în minus.
• Motiv neutilizabil (mapabil contabil la contul SNC 714 — Alte cheltuieli operaționale; ⚙️ split SNC în raport = activabil la cerere).

Caz special — cantitate pozitivă (corecție inventar)

În cazul rar când inventarul descoperă mai mult decât arată sistemul (e.g. recount găsește 3 unități extra), managerul poate înregistra o "pierdere" cu cantitate pozitivă — sistemul o tratează ca adăugare la stoc (corecție de inventar).

• Cantitatea pozitivă declanșează automat un avertisment galben pe formular: "Cantitate pozitivă = stocul va crește. Pierderile sunt cu cantitate negativă."
• Necesită permisiunea explicită HORECA_STOCK__INVERSE_ADJUSTMENT (admin) — operatorii obișnuiți nu pot face acest tip de ajustare accidental.
• Necesită un checkbox suplimentar "Confirm că vreau să ADAUG la stoc (corecție rară)" înainte de salvare.

Cazul 2 — Pizza arsă

Bucătarul a uitat pizza în cuptor → arsă. Trebuie refăcută.

• Re-fa declanșează un bon nou (vezi Bonuri de producție).
• Pierderea (pizza arsă) e un rând cu motiv ars_preparat (mapabil contabil la SNC 714, ⚙️ activabil), necesită aprobare manager (peste prag).

Cazul 3 — Anulare client mid-prep

Vezi Bonuri de producție — Cancel post-prep. Sistemul generează automat rândurile de pierdere cu motiv anulare_client.

Pierderi în afara bucătăriei

Pierderile se pot înregistra și fără bon de producție asociat:

Caz: Client sparge un pahar la masă - Chelnerul deschide ecranul Înregistrează pierdere. - Alege produsul (Pahar standard ×1). - Motiv: cazut_spart. - Comentariu: "Client a scăpat la masa 3". - Sistemul:

- Generează un bon de pierdere standalone (nu legat de o comandă specifică).
- Tag-uiește chelnerul ca responsabil (`invoice:request:by`).
- Bon writeoff (mapabil contabil la SNC **714**, ⚙️ split per-cont activabil la cerere).

Caz: Inventar descoperă produse expirate - Manager_tură deschide Inventar > Înregistrează corecție. - Liniile cu motiv expirat. - Comentariu obligatoriu. - Sistemul: bon de pierdere (mapabil contabil la SNC 714, ⚙️ activabil), manager logat ca autor.

Caz: Personal mănâncă (masa angajaților) - Manager_tură deschide Înregistrează consum personal. - Lista produselor + cantități. - Motiv: autoconsum_personal (mapabil contabil la SNC 713 — Cheltuieli administrative; ⚙️ split per-cont activabil la cerere).

Caz: On-the-house / oferit clienților - Chelnerul a oferit clientului un shot de digestiv (gratis). - Pe ecran: Marchează ca ofertat. - Motiv: degustare_client (mapabil contabil la SNC 712 — Cheltuieli comerciale; ⚙️ split per-cont activabil la cerere). - Necesită aprobare manager (sumă peste prag).

Aprobare pierderi peste prag

Anumite pierderi necesită aprobare manager_tură înainte de a fi finalizate:

Pierderi peste 100 MDL valoare → necesită aprobare
Pierderi cu motiv "furt_frauda" → întotdeauna aprobare
Pierderi marketing/oferit > 50 MDL → aprobare

Pragurile sunt configurabile per tip motiv. Workflow:

1. Bucătarul / chelnerul înregistrează pierderea.
2. Bonul intră în starea "așteaptă-aprobare".
3. Manager_tură primește notificare.
4. Aprobă (cu un click, opțional cu comentariu) → bonul devine final.
5. Sau respinge cu motiv → operatorul ajustează / re-trimite.

Nomenclator coduri motiv

Vezi Pierderi & motive pentru lista completă. Exemple frecvent folosite:

ℹ️ Coloana „Cont SNC (mapabil)" = corespondența contabilă tipică pentru fiecare cod motiv. NU este atribuită automat de sistem în v1 — motivul se persistă pe linia bonului, iar mapping-ul motiv → cont rămâne responsabilitatea contabilului (sau ⚙️ activabil la cerere ca split automat în raportul de tură).

Beneficii directe

Pentru bucătar-șef - Vezi unde se pierde efectiv per POS și per produs (top-10 MPN-uri cu pierderi în raportul de închidere al turii). Comparație între stații de bucătărie (kitchen-hot vs kitchen-cold) e ⚙️ activabilă la cerere pe locații cu mai multe stații fizice — v1 agregă la nivel de POS. - Identifici pattern-uri per-MPN prin raportul de anomalii (vezi mai jos). Segmentarea per zi/oră sau per motiv rămâne ⚙️ activabilă la cerere.

Pentru contabil - Totaluri per subtip în raportul de închidere al turii (production / sell / writeoff / transfer / supply / transform), plus top-10 MPN-uri cu pierderi. Împărțirea pe conturi SNC (611/711/712/713/714) la nivel de linie e ⚙️ activabilă la cerere — v1 livrează agregatele, mapările per motiv → cont rămân la contabil pentru pasul manual (vezi SNC Moldova). - Fiecare pierdere are motiv persistat pe linia bonului → poți argumenta în fața auditului chiar și fără roll-up automat per cont.

Pentru proprietar - Vezi marja per tură (vânzări – cost productiv – cost pierderi din raportul de închidere) și top-10 MPN-uri cu pierderi. Analiza marjă per-produs pe intervale mari se face din raportul sales_aggregate (dashboard-first). - Decizii informate despre meniu (Tiramisu pierde 15% — modifică rețeta sau scoate-l).

Anularea unei pierderi după ce a fost aplicată

Dacă o pierdere a fost aplicată în stoc dar trebuie anulată (ex. operatorul a greșit produsul sau cantitatea), bonul de pierdere se poate anula:

• Pe ecranul bonului, apăsă 🚫 Anulează.
• Alege motivul anulării din lista de coduri configurată la POS (ex: eroare_introducere, motiv_anulat_de_manager).
• Sistemul inversează automat efectul în stoc — folosind exact valoarea înregistrată la aplicare (citită din jurnalul intern al bonului), nu o re-calculare. Asta garantează că anularea readuce stocul la valoarea exactă de dinaintea pierderii, fără over- sau under-correction.

Bonul rămâne în arhive cu starea "anulat", vizibil pentru audit, dar nu mai afectează stocul.

Lista standalone de pierderi cu căutare + filtrare

Lista "Pierderi standalone" din panoul HoReCa folosește un tabel cu:

• Căutare globală după nume, POS, stadiu, tip
• Paginare (15 rânduri / pagină default)
• Sortare pe orice coloană (click pe header)
• Filtre per-coloană prin popover

Scalează la mii de înregistrări fără să încetinească interfața.

Raport de anomalii la pierderi

Panoul HoReCa include o secțiune dedicată "🚨 Detecție anomalii pierderi" care:

• Compară pierderile de azi cu media + deviația standard a ultimelor N zile (configurabil 3–30, default 7) și cu un prag configurabil de sensibilitate (default 1× stddev pentru "warn", 2× pentru "alert"; se poate coborî la 0.5× pentru locații mici cu volum scăzut).
• Marchează cu galben (warn) MPN-urile peste pragul de warn configurat.
• Marchează cu roșu (alert) MPN-urile peste pragul de alert configurat.
• Sare peste MPN-urile cu istoric prea scurt (< 3 zile) — deviația standard nu e fiabilă.

Util pentru:

• Identificare anomalii reale per MPN (ex. Mozzarella are 4× mai multe pierderi decât media săptămânii — verifică frigiderul, verifică lotul).
• Segmentare suplimentară per motiv, per zi sau per oră e ⚙️ activabilă la cerere — v1 lucrează per-MPN, fără cross-motive / temporal pattern mining.

Rezultatele sunt clickabile — operatorul navighează direct de la lista de anomalii la cardul produsului în depozit.

Performanță

Bonurile de consum se generează automat la fiecare Start de preparare, fără efort uman suplimentar. Pierderile se adaugă în câteva secunde pe tabletă.
Identificatorul fiecărui bon de pierdere are formatul S-IDNO-YYYYMMDDhhmmss-NNNNN (S = Storno), unic și sortabil cronologic. Toate listele afișează data + ora cu precizie de secundă, ca să nu existe confuzie când se înregistrează mai multe pierderi în aceeași minut.

Următorul pas

→ Încasare fiscală sau Roluri HoReCa.