LINKoms — Order Management System pentru restaurante, baruri și fast-food

Cele mai multe softuri de restaurant sunt de fapt două produse: unul „de POS", care rulează pe stația din tejghea, și un „add-on de comandă la masă", mult mai sărac, pentru tabletă. Sunt scrise separat, se actualizează separat și au funcții diferite — de aceea ospătarul întreabă mereu „asta se poate și de pe tabletă?".

LINKoms nu e împărțit așa. Este un singur program, livrat în trei forme: aplicație de Windows pentru stațiile de la tejghea și de la bar, aplicație de Android pentru tablete și telefoane, și pagină web instalabilă direct din browser. Toate trei încarcă aceeași aplicație și vorbesc cu același server, deci un ospătar care trece de pe tabletă pe stația de la bar găsește exact aceleași butoane, în aceeași ordine.

Consecința practică se vede la actualizare: interfața se publică o dată și ajunge singură pe toate terminalele, fără să treacă cineva pe la fiecare aparat. Aplicațiile de Windows și de Android se actualizează și ele singure — verifică periodic dacă a apărut o versiune nouă și o anunță în bara laterală, cu descărcare și instalare la o apăsare, niciodată în mijlocul unei comenzi.

Ecranul de pornire e planul sălii: zonele ca butoane pe un rând (salon, terasă, bar, saloane de evenimente) și, sub ele, mesele așezate pe coordonatele desenate în nomenclator — nu o listă de numere. Planul se scalează singur după ecran, deci aceeași sală se recunoaște și pe stația de la bar, și pe telefonul din buzunar.

Culoarea spune totul dintr-o privire: verde — masă liberă; albastru — masă deschisă chiar de ospătarul logat; roșu — masa altui ospătar, pe care nu se poate intra (consumația se mută prin transfer, nu forțând ușa); gri — propria masă, rămasă blocată pe alt dispozitiv. Pe cartonaș scriu numărul mesei, valoarea consumației și ospătarul.

Ultimul caz e cel care se întâmplă în realitate: o tabletă rămasă fără baterie sau o aplicație închisă brusc lasă masa blocată pe un aparat care nu mai există. LINKoms are ieșirea chiar în sală — dialogul spune ce dispozitiv o ține, cere parola unui șef de sală și eliberează masa. Nu e o forțare a intrării, ci exact apelul pe care nu l-a mai apucat terminalul căzut.

Sala se reîmprospătează singură la 20 de secunde și ori de câte ori aplicația e adusă în față. Când bucătăria marchează un preparat gata pe o masă a ospătarului logat, terminalul vibrează și scoate un clinchet scurt, repetat cât timp comanda nu e ridicată — bucătarul îl cheamă pe el, chiar dacă nu se uită la ecran.

Apăsarea lungă pe o masă deschide, chiar peste plan, consumația ei: liniile grupate pe felurile bonurilor de secție, fiecare cu starea lui din bucătărie, în aceleași culori pe care le vede bucătarul. De acolo se poate da și lansarea (FIRE) — comanda ospătarului către secție să înceapă prepararea — fără să se intre pe masă.

Ecranul are trei zone — grupele meniului, articolele grupei și comanda/nota mesei. Pe un ecran lat stau una lângă alta, în trei coloane. Pe telefon nu încap toate, așa că utilizatorul alege dintr-un comutator cu schițe: „Taburi" (o zonă pe ecran, cu trei file deasupra), „Split 2" (comanda sus, meniul într-o bandă jos) sau „Split 3" (comanda sus, iar jos articolele împreună cu banda de grupe). Cât la sută din înălțime ia comanda e un parametru al firmei.

Alegerea rămâne a TERMINALULUI: o tabletă ținută pe orizontală lucrează pe trei coloane, telefonul aceluiași ospătar rămâne pe taburi, fără ca vreunul să-l deranjeze pe celălalt. Nimic din logică nu se dublează — sunt aceleași ecrane, doar așezate altfel.

Adăugarea unui articol e un singur tap. Acolo unde comanda e permanent pe ecran, linia apare imediat sub ochi, cu „−/+" pe ea; acolo unde comanda e într-un alt tab și tapul ar rămâne fără confirmare, se deschide un dialog scurt cu cantitatea, felul și specificațiile — o despăgubire pentru ecranul mic, nu o apăsare în plus pentru toată lumea.

Meniul se filtrează după sală și după agent, deci terasa care vinde și din bar, sau standul de la un eveniment, pot avea alt sortiment și alte prețuri fără un al doilea nomenclator. Căutarea după denumire e mereu în bara de sus, cu tastatură proprie pentru terminalele fără tastatură fizică.

Comanda pleacă pe SECȚII, nu „la bucătărie": pentru fiecare secție atinsă de comandă — bucătărie caldă, bar, cuptor de pizza, cofetărie — se compune un bon separat și se tipărește la imprimanta ei. Abia după ce hârtia a ieșit, liniile trec din comandă în notă.

Imprimanta de secție e piesa care cade cel mai des într-un restaurant: rămâne fără hârtie, e scoasă din priză la curățenie, pierde rețeaua. De aceea eșecul nu e tăcut și nu e definitiv — ospătarul primește trei ieșiri explicite: „Reîncearcă" (bonul se compune din nou și se încearcă din nou, fiindcă între timp imprimanta a fost pornită), „Continuă fără tipărire" (comanda ajunge la bucătărie, hârtia se rezolvă altfel) sau „Renunță" (liniile rămân în comandă și se trimit mai târziu). Nimic nu se decide în locul lui.

Acolo unde secția are ecran de bucătărie — LINKkds — bonul nu e de-ajuns: comanda ajunge pe board în așteptare, iar ospătarul o LANSEAZĂ (FIRE) când e momentul. Popup-ul de după trimitere îl oprește exact pentru asta, cu felurile fiecărei secții în față; lansarea se poate da și pe fiecare fel în parte, mai târziu, din vizualizarea rapidă a mesei. În modul casier, unde clientul a plătit deja, felurile se lansează singure — bucătăria trebuie să pornească pe loc.

Anularea unei comenzi deja trimise se face pe BONUL ei, nu pe „nota mesei": bucătăria are hârtia aceea. Ecranul „Comenzi trimise" arată bonurile grupate pe secție și comandă, cu liniile fiecăruia, și permite retipărirea unui bon, anularea lui întreagă sau anularea unui singur articol. Ordinea e fixă: întâi iese bonul de anulare la bucătărie, abia apoi liniile ies din notă — bucătăria are deja marfa, deci nimic nu dispare din notă până nu are cu ce corecta.

Dialogul de plată arată totalul notei și modurile de plată într-o listă unică, ca să se vadă toate dintr-o privire. Cele de pe BONUL FISCAL se cumulează: card, tichete, credit, voucher și un mod „alte" care poartă chiar denumirea folosită de firmă (de pildă numele platformei de livrare). NUMERARUL nu se tastează — e restul calculat automat, deci defalcarea acoperă întotdeauna exact totalul, fără diferențe de un ban.

Modurile EXCLUSIVE sunt separate, fiindcă se exclud între ele: PROTOCOL (cu tip și explicație alese dintr-un nomenclator — cine și de ce), TRANSFER pe camera de hotel (cu rezervarea aleasă din lista camerelor ocupate, consumul intrând pe cameră) și ORDIN DE PLATĂ, care cere factură obligatoriu. Care moduri se văd pe terminal e o setare a firmei: o locație care nu lucrează cu tichete nu are de ce să le vadă în ecran.

Bonul fiscal se compune din liniile notei și pleacă la casa de marcat prin driverul stației; confirmarea tipăririi se scrie înapoi pe document (numărul de bon și numărul de Z), astfel încât raportul de tură să corespundă cu casa. Plata cu CARDUL trece prin POS-ul bancar conectat la aceeași stație, cu reîncercare și cu decizia explicită a operatorului atunci când tranzacția nu reușește.

FACTURA se alege ÎNAINTE de închiderea notei și se completează într-un ecran propriu: blocul de facturi, numărul (propus automat, editabil, verificat pe plajă și unicitate), partenerul — căutat în nomenclator după CUI sau denumire, sau adus direct de la ANAF dacă nu există încă și salvat pe loc — și delegatul cu seria de buletin. Ce s-a ales se vede într-un card, iar nota nu se închide cât timp factura e cerută și necompletată.

Pentru firmele care nu vor factură, dar au nevoie de cheltuială deductibilă, există „CUI PE BON": se tastează CUI-ul, ENTER îl caută la ANAF, denumirea găsită se citește clientului cu voce tare pentru confirmare, iar pe bonul fiscal se tipărește CUI-ul. Nu se creează niciun partener și nu se atinge nomenclatorul.

Nu orice unitate are sală cu mese. O rulotă de mâncare, o tejghea de fast-food, un bufet cu împinge-tava lucrează altfel: clientul comandă, plătește și pleacă, iar operatorul nu are ce căuta într-un plan de sală.

Pentru ele, LINKoms comută dintr-un singur parametru în modul CASIER. Planul de sală dispare cu totul, terminalul intră direct în ecranul de comandă, iar după fiecare bon se deschide automat o comandă nouă — casierul rămâne în același ecran toată tura. Trimiterea la bucătărie nu mai e un pas separat: se face în drum spre plată, când comanda e chiar încasată, ca o renunțare a clientului să nu lase bucătăria pornită degeaba.

Funcțiile casei de marcat pe care în sală le găsești în bara planului — raport X, raport Z, deschidere sertar, depunere, retragere — coboară în panoul de funcții al comenzii, ca să rămână la îndemână. Restul aplicației nu se schimbă: aceleași articole, aceleași combo-meniuri, aceleași moduri de plată, aceeași facturare.

LINKoms nu are nomenclator propriu. Meniul, prețurile, sălile cu zonele și mesele lor, secțiile, imprimantele, rețetele, partenerii, blocurile de facturi — toate sunt cele din LINKerp, citite din aceeași bază de date. Ce modifici în meniu se vede pe terminale fără sincronizări, fără import-export și fără „a doua introducere".

Vânzarea se scade din stoc și intră în contabilitate ca orice altă vânzare din LINKerp, cu documentele ei; nu există o punte de reconciliat la sfârșit de lună. Consumația transferată pe o cameră ajunge pe rezervarea din LINKbooking, iar facturile emise aici sunt facturi ale firmei, în blocurile ei.

Către bucătărie, LINKoms e sursa comenzilor pentru LINKkds: bonurile trimise de aici apar pe ecranul din bucătărie, lansarea (FIRE) pleacă de la ospătar, iar starea preparatelor se întoarce în sală — pe cartonașul mesei, în vizualizarea rapidă a consumației și ca semnal sonor pe terminalul celui care trebuie să ridice.

Configurarea aplicației se face tot din parametrii LINKerp, iar cei care descriu APARATUL — casa de marcat, POS-ul bancar, display-ul de client, cântarul — se citesc pe numele terminalului, nu pe firmă. Două stații ale aceleiași firme pot fi programate diferit, iar instalarea unui terminal nou înseamnă un cont și un set de parametri.

Platforme

Windows, Android (tabletă și telefon), browser / PWA — aceeași aplicație, aceleași funcții

Limitări în browser

Impuse de securitatea browserului: fără tipărire pe imprimante de rețea sau partajate, fără port serial (cântar), fără fișiere pentru driverele de casă pe fișier

Moduri de operare

Ospătari (plan de sală, mese) sau Casier (fără mese — fast-food, rulotă, împinge-tava)

Sală

Zone și mese pe coordonate reale, culoare de stare, reîmprospătare automată la 20 s

Terminal partajat

Mai mulți ospătari pe aceeași sesiune, identificați cu PIN înainte de fiecare comandă

Aranjamente ecran comandă

Trei coloane, Taburi, Split 2, Split 3 — alese pe terminal, cu schiță

Comandă

Combo-meniuri, extra legate de linie, specificații libere, feluri de servire F1..F5, locuri la masă, cântar serial

Secții

Bon separat per secție, cu reîncercare la imprimantă căzută; lansare (FIRE) către LINKkds, pe comandă sau pe fel

Notă

Împărțire pe cantități, transfer pe altă masă/ospătar, discount pe notă sau pe articol, blocare după tipărire

Moduri de plată

Numerar, card, tichete, credit, voucher, „alte" cu denumire proprie, protocol, transfer pe cameră, ordin de plată

Fiscal

Bon fiscal la casa de marcat, cu confirmare scrisă pe document; POS bancar pe aceeași stație

Documente

Factură cu partener din nomenclator sau de la ANAF, delegat, bloc și număr verificat; CUI pe bon

Livrare

Client după telefon, adrese, platformă (Glovo, Tazz, …) și șofer, completate la preluarea comenzii

Rapoarte

Tipizatele firmei pe ziua de gestiune; istoric al notelor închise, cu totaluri pe moduri de plată

Autorizări

Șef de sală pentru discount, preț, deblocare și anulări; administrator pentru configurări

Integrare

Nomenclator, stoc și contabilitate din LINKerp; comenzi către LINKkds; consumații către LINKbooking

Interfață

Limba română, temă luminoasă și întunecată, mărime de text reglabilă, ghid interactiv inclus

Actualizare

Interfața, automat de pe server; aplicațiile de Windows și Android, cu anunț și instalare la cerere