Divizii bucătărie & bar

Cui vorbim:* manager / bucătar-șef care vrea să separe fluxurile pe tipuri de preparate.

Terminologie importantă — POS vs. divizie

POS = punct de vânzare logic (ex.: "Sala 1", "Terasa", "Magazin Centru", "Atelier") — entitate distinctă, cu casă fiscală, stoc separat, raport tură propriu. > Divizie = stație internă a unui POS (ex.: kitchen-hot, kitchen-cold, bar, dessert, coffee) — mai multe per POS, fără raport tură separat, fără casă fiscală proprie. > Un POS poate avea oricâte divizii — diviziile se configurează la onboarding conform fluxului tău (scope convenit), unde sunt incluse în pachet (Extra HoReCa, Extra Producție, Enterprise). Re-configurări ulterioare = la cerere, evaluate individual. Costul real de licențiere e dat de numărul de POS-uri (puncte de vânzare distincte), NU de granularitatea internă a diviziilor. > Configurarea diviziilor la onboarding (de către echipa noastră, cu definire rutare automată produs → divizie) e parte din pachetul Extra HoReCa. La Standard / Extra simple, diviziile NU sunt incluse — pentru ele alegi Extra HoReCa.

Ce este o "divizie"

O divizie este o sub-zonă a localului tău unde se preparează un anumit tip de produse, cu o tabletă dedicată (kitchen-display) și operatori dedicați. Exemple tipice:

Restaurant tipic, 1 POS (sala principală):
    Divizii:
        - kitchen-hot      → pizzas, paste, fripturi
        - kitchen-cold     → salate, antreuri reci
        - dessert          → prăjituri, înghețată
        - bar              → bere, vin, cocktailuri, băuturi tari
        - coffee           → cafea, ceai, băuturi calde

Restaurant cu terasă (2 POS):
    POS-sala:
        - kitchen-hot, kitchen-cold, bar, coffee
    POS-terasa:
        - bar (terasă are bar separat)
        - coffee (idem)
        - "produse sala" → trimit la POS-sala

De ce divizii (și nu doar "bucătărie")

În realitate, bucătăria nu e un singur loc — e mai multe stații (cuptor, plită, prepararea rece, deserturi). Un bucătar de la kitchen-cold nu poate face o pizza, și invers. Diviziile asigură că:

Bonurile ajung la persoana potrivită (pizza la pizza-bucătar, salata la salata-bucătar).
Tabletele afișează doar ce contează (bucătarul de la kitchen-cold nu e bombardat cu toate comenzile localului).
Pierderile / pregătirile se contabilizează per stație (la final de tură vezi care stație are cel mai mult overhead).

Configurare

La onboarding sau ulterior din setări:

Definești diviziile per POS (ex.: POS-sala are 5 divizii) — configurate de echipa noastră la setup-ul Extra HoReCa; alternativ, pe Standard / Extra simple se configurează prin editare directă a storage_settings/website.json (manual sau prin asistență la cerere).
Atribui produsele la divizii — fiecare produs din meniu are un tag "divizie default" (ex. Pizza Margherita → kitchen-hot). Self-service disponibil pe orice pachet HoReCa-capable: - Deschizi ERP Storage Groups → Products - Coloana "HoReCa Division" (vizibilă în view-ul "Product"; revealabilă din column-picker) - Click pe celulă → prompt cu lista diviziilor configurate per POS - Tastezi identifier-ul (ex. kitchen-hot) → salvat instant pe meta.params.horeca_division - Override per POS disponibil: cu un filtru POS activ în grid, editarea scrie meta.params_pos[<pos>].horeca_division — un produs poate ruta la dessert la Sala-1 și la coffee la Terasa.
Configurezi rolurile — utilizatorul "Maria bucătar" are rolul bucatar cu scoping :DIVISION:kitchen-hot (vede doar bonurile pizzas).

Configurarea diviziilor durează ~30 minute la onboarding pentru un restaurant tipic (Extra HoReCa); self-service la ulterior necesită câteva minute per produs nou adăugat în meniu.

Cum funcționează rutarea automată

Când chelnerul apăsă Trimite pe o comandă cu mai multe rânduri:

Sistemul iterează liniile.
Pentru fiecare linie, citește diviziunea produsului (horeca_division) + POS-ul comenzii.
Grupează liniile după (POS, divizie).
Generează un bon de producție per grup.

Exemplu — comanda M3-1942 are: Pizza, Salată, Apă, Tiramisu, Cafea, Mojito.

POS-sala / kitchen-hot   → bon #1: Pizza
POS-sala / kitchen-cold  → bon #2: Salată
POS-sala / bar           → bon #3: Apă, Mojito (2 rânduri într-un bon)
POS-sala / dessert       → bon #4: Tiramisu
POS-sala / coffee        → bon #5: Cafea

5 bonuri, fiecare merge la tableta diviziei lui. Bucătarul de la pizza vede DOAR Pizza, nu se distrage cu rândurile celorlalți.

Ce vede bucătarul pe tabletă

Tableta din kitchen-hot afișează:

┌─────────────────────────────────────────────┐
│  KITCHEN-HOT — POS-sala                     │
│  Bonuri active: 4                           │
├─────────────────────────────────────────────┤
│  📋 Comanda #M3-1942 (Masa 3)              │
│      Pizza Margherita ×1                    │
│      • fără ceapă                           │
│      Vechime: 2 min   [Acceptă] [Refuză]    │
├─────────────────────────────────────────────┤
│  📋 Comanda #M5-1947 (Masa 5)              │
│      Pizza Quattro Stagioni ×1              │
│      Pizza Capricciosa ×1                   │
│      Vechime: 4 min   [Acceptă]             │
├─────────────────────────────────────────────┤
│  🍳 Comanda #M3-1942 (Masa 3) - ÎN PREP    │
│      Pizza Margherita ×1                    │
│      Vechime: 8 min   [Gata]                │
├─────────────────────────────────────────────┤
│  ✅ Comanda #M2-1932 (Masa 2) - GATA       │
│      Pizza Diavola ×1                       │
│      Așteaptă chelner: 2 min                │
└─────────────────────────────────────────────┘

Coloane vizuale (sau tab-uri pe tabletă mică): De acceptat | În preparare | Gata | Livrate (recent).

Workflow bucătar (per bon)

Acceptă — confirmă că poate prepara (rezervează ingredientele în BOM, vezi Bonuri consum).
Start — atinge când începe efectiv preparare (decrementează stocul efectiv, pornește timer).
Gata — atinge când e gata pe pas → notificare automată chelner.
Livrat — chelnerul confirmă că a luat de la pasă.

Fiecare tranziție e logată cu timestamp, ca să poți măsura timpii medii pe stație (vezi Rapoarte tură).

Multi-tabletă pe aceeași divizie

În bucătării mari, poți avea 2-3 tablete pe aceeași divizie (ex.: 2 pizza-bucătari, fiecare cu tableta lui). Bonurile se afișează pe ambele, oricine poate Acceptă (devine al lui), restul tabletelor îl ascund.

Refuz cu motiv

Dacă bucătarul nu poate prepara (s-a terminat ingredientul, defecțiune cuptor), apăsă Refuză + alege motiv (out-of-stock, defect-utilaj, volum-prea-mare). Bonul revine la chelner cu mesaj → chelnerul informează clientul, oferă alternativă.

Reorder priorități

Manager_tură poate reorder bonurile dintr-o divizie (ex.: prioritate la masa VIP, sau la bonurile vechi). Pe ecran, bucătarul vede ordinea.

Anexă tehnică — cum se configurează lista de divizii a unui POS

Această anexă e destinată integratorilor SGApps și clienților tehnici. Operatorul tipic vede deja diviziile configurate la onboarding; această procedură intervine doar atunci când vrei să adaugi / elimini divizii pe un POS existent fără să soliciți suport.

Lista de divizii a fiecărui POS trăiește în fișierul de configurare website (storage_settings/website.json la deployment-ul tău). Schema e moștenită automat din models/website.template.json — fiecare POS din hasPOS[] poate avea un array divisions[] cu obiecte de forma:

{
    "identifier": "kitchen-hot",
    "name": "Bucătărie caldă",
    "description": "Pizza, paste, fripturi, supe calde",
    "active": true
}

Procedura pas-cu-pas* (10-15 minute pentru un POS cu 5 divizii):

Acces — autentificare ca admin la serverul tău (SSH / panou administrare).
Editare fișier — deschizi storage_settings/website.json cu un editor JSON-aware (validează sintaxa la salvare).
Găsești POS-ul — în array-ul hasPOS[], identifică POS-ul după identifier (ex. "main-pos", "terrace-pos").
Adaugi divizii — în obiectul POS, găsești cheia divisions (un array gol [] la deployment-uri noi din template). Adaugi câte un obiect pentru fiecare stație:

```json "divisions": [

   { "identifier": "kitchen-hot",  "name": "Bucătărie caldă",      "description": "Pizza, paste, fripturi",                "active": true },
   { "identifier": "kitchen-cold", "name": "Bucătărie rece",       "description": "Salate, antreuri, deserturi reci",       "active": true },
   { "identifier": "bar",          "name": "Bar băuturi",          "description": "Cocktailuri, bere, vin, băuturi tari",   "active": true },
   { "identifier": "dessert",      "name": "Cofetărie",            "description": "Prăjituri, înghețată, deserturi calde",  "active": true },
   { "identifier": "coffee",       "name": "Espressor",            "description": "Cafele, ceai, băuturi calde",            "active": true }

] ```

Reguli identifier — caractere mici, cifre, cratimă (a-z0-9-), maxim 32 caractere; unice per POS (poți reutiliza bar pe alt POS); rezervă __default (nu folosi).
Salvare + reload — salvezi fișierul, reîncarci aplicația HoReCa în browser. Configurarea se vede instant în "Configurare → Configured POSes → Details" (panel 🍳 Divisions configured at this POS).
Verificare — taggezi un produs cu unul din noile identifier-i (din grid-ul ERP Storage Groups, coloana "HoReCa Division"), trimiți o Comandă de test, observi că bonul de producție aterizează pe divizia corectă.

Mutare divizie (rename identifier):* dacă schimbi un identifier (ex. bar → bar-principal), produsele deja taggate cu valoarea veche rămân orfane — folosește P3.2b bulk backfill (când va fi disponibil) sau editezi inline din ERP. Recomandat: marchează vechea valoare cu active: false în loc să o ștergi, ca să păstrezi compatibilitatea cu istoricul.

Dezactivare divizie:* setezi "active": false în loc să elimini obiectul — produsele istorice rămân corect taggate, iar prompt-ul de editare nu mai oferă identifier-ul ca opțiune.

Următorul pas

→ Bonuri de producție în detaliu sau Bonuri de consum + pierderi.