Užsakymų srautai — Mokėjimas iš anksto ir Mokėjimas vėliau
Kada naudoti mokėjimą iš anksto ir mokėjimą vėliau, kaip kiekvienas srautas veikia nuo pradžios iki pabaigos, kokias užsakymų būsenas operatoriai mato administravimo skydelyje ir kokie foniniai procesai sinchronizuoja užsakymus su POS.
Fooodo palaiko du atskirus užsakymų srautus. Jie skiriasi tuo, kada virtuvė mato užsakymą ir kada vyksta mokėjimas. Pasirinkimas priklauso nuo aptarnavimo stiliaus, o ne nuo restorano — vienas restoranas gali naudoti skirtingus srautus skirtinguose staluose.
- Guest scans QR, builds cart
- Guest pays
- Order is exported to R-Keeper
- Kitchen prepares
- Guest receives or collects
- Guest scans QR, builds cart
- Items go to R-Keeper kitchen immediately
- Guest adds more rounds (each one syncs)
- Guest asks to pay
- Order locked → marked paid in R-Keeper
Fooodo užsakymų srautai bendrauja su jūsų POS per jungties sutartį. R-Keeper šiandien yra veikianti etaloninė jungtis — toliau aprašyta mechanika nurodo, ką turi tenkinti kiekviena jungties implementacija.
Mokėjimas iš anksto
Naudokite mokėjimą iš anksto, kai svečiai turėtų sumokėti prieš pradedant aptarnavimą: išsinešimui, greito aptarnavimo vietose, maisto aikštelėse. Virtuvė niekada nemato neapmokėto užsakymo; POS gauna vieną užsakymo eksportą vienam krepšeliui; jei svečias palieka krepšelį, niekas nepasiekia linijos.
Mokėjimas vėliau
Naudokite mokėjimą vėliau pietaujant vietoje ir daugiaeilio aptarnavimo atveju. Pirmasis raundas siunčiamas į POS iš karto, kai tik pateikiamas; vėlesni raundai pridedami prie to paties POS užsakymo po vieną. Užsakymas POS lieka atviras nuo pirmojo raundo iki tol, kol mokėjimas jį uždaro. Viduje Fooodo seka, kurie elementai jau buvo išsiųsti, todėl kiekvienas raundas sinchronizuojamas tik vieną kartą.
Kodėl srautai skiriasi
Mechaninis skirtumas yra nedidelis — mokėjimas iš anksto sukuria vieną POS eksportą, mokėjimas vėliau — daugelį. Operacinis skirtumas yra svarbesnis:
- Mokėjimo iš anksto atveju virtuvė neatlieka jokio papildomo darbo, jei svečias palieka krepšelį. Tačiau svečio patirtis neatitinka pietavimo vietoje: žmonės tikisi mokėti pabaigoje; prašymas sumokėti iš anksto atrodo kaip sandoris, o ne svetingumas.
- Mokėjimo vėliau atveju svečio patirtis atitinka įprastą restoraną. Operatorius prisiima nedidelę riziką, kad užsakymas gali būti neapmokėtas (svečias išeina, kortelė atmetama) — ta pati rizika, kuri šiandien egzistuoja su bet kokiu aptarnavimu pagal popierinę sąskaitą.
Daugelis tinklų pradeda nuo mokėjimo iš anksto išsinešimo langeliuose, o vėliau prideda mokėjimą vėliau prie pietavimo stalų, kai darbuotojai susipažįsta su administravimo skydeliu.
Srauto konfigūravimas
Srautas nustatomas kiekvienam stalui arba kaip restorano numatytasis parametras administravimo skydelyje. Restoranas gali derinti srautus — pavyzdžiui, pietavimo stalai naudoja mokėjimą vėliau, išsinešimo langelis — mokėjimą iš anksto, abu veikia per tą pačią Fooodo instaliaciją.
Būsenos praktikoje
Užsakymai juda per būsenų mašiną. Toliau pateikti pavadinimai yra tiksliai tokie, kokie rodomi administravimo skydelyje — naudingi tiek operatoriams, skaitantiems savo užsakymus, tiek integratoriams, vartojantiems užsakymų įvykius.
Būsenos, kurios labiausiai rūpi operatoriams:
| Būsena | Ką reiškia |
|---|---|
Created | Krepšelis sukurtas, dar nepateikta jokių elementų |
InProgress | Elementai pateikti į POS, laukiama daugiau arba mokėjimo |
ReadyToBePaid | Svečias baigė užsakinėti, mokėjimas laukiamas |
Paid | Mokėjimas sėkmingas, POS pažymėjo kaip apmokėtą |
Finished | Užsakymas uždarytas, galutinė sėkmės būsena |
Su nesėkme susijusios būsenos:
| Būsena | Ką reiškia |
|---|---|
Locked | POS turi atvirą užsakymą (padavėjas jį redaguoja). Automatiškai kartojama su atidėjimu. |
Error | Eksportas į POS nepavyko po visų bandymų. Reikalinga rankinė intervencija. |
Cancelled | Užsakymas atšauktas arba baigėsi laikas neapmokėjus |
Dauguma Locked būsenų išsisprendžia per kelias sekundes. Nuolatinė Locked būsena paprastai reiškia, kad padavėjas turi atvirą užsakymą POS ir pamiršo jį uždaryti.
Error yra vienintelė būsena, kuriai reikalingas žmogaus dėmesys. Jungties gedimų žurnaluose užfiksuota, kas nutiko; įprastas sprendimas yra iš naujo sukurti užsakymą POS terminale.
Kas veikia fone
Nedidelis skaičius suplanuotų užduočių palaiko užsakymų sluoksnio sinchronizavimą — operatoriams nereikia jų įsiminti, tačiau integratoriams, vartojantiems Fooodo duomenis, reikėtų žinoti periodiškumą:
| Periodiškumas | Užduotis |
|---|---|
| Kas minutę | Restorano pasiekiamumo patikrinimas |
| Kas minutę | Atšaukti užsakymus, kurių laikas baigėsi be mokėjimo |
| Kas 2 min | Gauti užsakymų atnaujinimus iš POS |
| Kas 4 min | Gauti stalo būseną iš POS |
| Kas 5 min | Sinchronizuoti elementų pasiekiamumą |
| Kasdien 09:00 | Pilnas meniu sinchronizavimas |
Jei POS nepasiekiamas, užduotys kartojamos eksponentiškai didėjančiu atidėjimu; užsakymai laukia esamoje būsenoje ir suderinami, kai jungtis atsistato.
Fooodo architektūra
Kaip sukurtas Fooodo — dviejų paslaugų padalijimas į meniu programą ir mokėjimo paslaugą, įmonės/restorano/stalo kelių nuomininkų modelis, POS-agnostinė jungties sutartis ir kur yra UVS.
R-Keeper jungtis
Gyva Fooodo POS jungties sutarties etaloninė implementacija — kokie duomenys kerta ribą, sinchronizavimo dažniai, lojalumo kainos ir kaip gedimų atveju vykdomi pakartotiniai bandymai gamyboje.