R-Keeper jungtis

R-Keeper yra gyva Fooodo POS jungties sutarties etaloninė implementacija — vienintelė jungtis, šiandien veikianti gamyboje, ir forma, kurią turi atitikti kiekviena papildoma jungtis. Pati sutartis yra POS-agnostiška; naujos jungtys apimamos pagal klientą ir kainodaroma pagal poreikį. Šiame puslapyje dokumentuojama, kaip R-Keeper apytaka iš tikrųjų veikia: kokie duomenys kerta ribą, kuria kryptimi, ir ko tikėtis, kai kažkas nueina ne taip. Toliau pateikti POS-specifiniai metodų pavadinimai priklauso R-Keeper; atitikmenys kitose jungtyse atitinka tas pačias jungties sutarties operacijas.

Ko Fooodo prašo iš R-Keeper

Tai tik skaitymo užklausos — Fooodo niekada nekeičia R-Keeper meniu, kainų, modifikatorių ar etaloninių duomenų.

Ką Fooodo rašo į R-Keeper

Užsakymo sukūrimas ir pažymėjimas kaip apmokėto yra du rašymo veiksmai, esantys kritiniame kelyje; abu yra įtraukiami į eilę, kartojami eksponentinio atsitraukimo principu ir detaliai registruojami žurnaluose. Kiti du yra papildomi.

Konfigūracija pagal restoraną

R-Keeper kredencialai saugomi restorano konfigūracijoje. Kiekvienas Fooodo restoranas turi:

• API galinio taško URL
• Restorano ID R-Keeper sistemoje
• Neprivalomą lojalumo kainų galinio taško adresą
• Neprivalomą lojalumo kortelių programos kodą
• Neprivalomą meniu elemento kodą arbatpinigių nukreipimui

Skirtingi tos pačios Fooodo įmonės restoranai gali nurodyti skirtingus R-Keeper egzempliorius. Taip šiandien veikia kelių vietų tinklai.

R-Keeper sinchronizavimo dažniai

Integracija apklausia ir siunčia duomenis pagal kelis skirtingus grafikus. Operatoriai ir partnerių palaikymo inžinieriai domisi šiais dažniais, nes jie nustato lūkesčius, kaip greitai biuro pakeitimas atsiranda klientui matomoje programėlėje — ir kaip greitai klientui matomas užsakymas pasirodo terminale.

Fooodo rašymo veiksmai į R-Keeper nėra suplanuoti — jie vykdomi iš karto, kai įvyksta įvykis (sukurtas užsakymas, apmokėtas užsakymas, išsiųsta žinutė), ir kartojami atsitraukimo principu, jei R-Keeper atmeta. Pakartotinių bandymų biudžetai dokumentuojami skyriuje Gedimų valdymas žemiau.

Lojalumo kainos pagal stalą

Stalai gali prisijungti prie lojalumo kainų dviem būdais, ir restoranas gali vienu metu naudoti abi formas:

• Kortelės pritaikymas po fakto. Kai stalas sukonfigūruotas su restorano lygio lojalumo kortelės kodu, Fooodo pritaiko kortelę po to, kai užsakymas eksportuojamas — R-Keeper perskaičiuoja eilutės elementus pagal kortelės nuolaidų logiką, o Fooodo atspindi pakoreguotas sumas svečiui. Užsakymas eksportuojamas vieną kartą, o tada pataisomas.
• URL nukreiptos alternatyvios kainos. Kai stalas sukonfigūruotas su lojalumo kainų jungties URL, Fooodo prašo R-Keeper lojalumo kainų meniu prieš tai, kai svečias mato kainas. Krepšelis, modifikatorių kainos, sumos — viskas, ką svečias mato, jau yra lojalumo kaina. Tai mažesnio delsimo kelias ir tas, kurį diegiame naujiems tinklams.

Nepriklausomai nuo to, kurią formą naudoja stalas, kuponų kodų nuolaidos teisingai pridedamos viršuje: svečias su lojalumo kortele vis tiek gali panaudoti kuponą, o kupono nuolaida pasiekia R-Keeper nepriklausomai nuo lojalumo kelio. Taip buvo ne visada — senesnėse versijose kuponai buvo susieti su po fakto taikomu keliu ir praleisti URL nukreiptuose staluose — todėl partneriai, pereinantys nuo senesnio diegimo, turėtų patikrinti, ar jų R-Keeper pusė apskaičiuoja abu efektus.

Lojalumo kainos gaunamos iš R-Keeper. Fooodo nepalaiko lygiagrečios nuolaidų lentelės.

Personalo ir užsakymų priskyrimas

Fooodo registruoja, kuris padavėjas yra susijęs su kiekvienu užsakymu, kad administravimo ataskaitos galėtų suskirstyti aptarnavimą ir arbatpinigius pagal darbuotoją. Srautas susideda iš dviejų dalių:

• Personalo katalogo sinchronizavimas vykdomas naktį 08:45 ir atnaujina padavėjų sąrašą iš tinklo personalo sistemos — vardus, pareigų pavadinimus ir išorinius personalo ID, kurie atitinka R-Keeper. Padavėjai Fooodo nekuriami rankiniu būdu; administratoriaus sąrašas yra tik skaitymui.
• Užsakymo priskyrimas vyksta, kai užsakymas gaunamas arba atnaujinamas iš R-Keeper. R-Keeper užsakymo būsenos atsakyme yra priskirto padavėjo ID; Fooodo jį suderina su sinchronizuotu personalo katalogu ir įrašo priskyrimą į užsakymą. Sąskaitos padalijimo vaikai paveldi tėvinio užsakymo padavėją.

Šiandien šis priskyrimas matomas tik administratoriui. Mokėjimo puslapyje padavėjas rodomas operatoriaus pusėje; užsakymo patvirtinime svečiui matomo padavėjo kortelės dar nėra. Tas paviršius yra planuojamas.

Gedimų valdymas

Integracija sukurta taip, kad toleruotų trumpalaikį R-Keeper neprieinamumą. Trys gedimų scenarijai, su kuriais susidursite praktikoje:

Užrakinti užsakymai

R-Keeper grąžina konkrečius klaidų kodus (2219 arba 13), kai padavėjas turi užsakymą atidarytą biuro terminale. Fooodo atsakas:

• Pažymėti užsakymą kaip Locked
• Kartoti eksportą pagal eksponentinio atsitraukimo grafiką (5 s → 10 s → 20 s → 40 s → 80 s — penki bandymai, iš viso ~155 sekundės)
• Jei visi pakartotiniai bandymai nepavyksta, eskaluoti į Error

Įprastai veikiant, užrakinimas trunka sekundes. Nuolatinis užrakinimas paprastai reiškia, kad padavėjas nuėjo palikęs užsakymą atidarytą terminale, o sprendimas yra uždaryti jį tiesiogiai R-Keeper sistemoje.

Pakartotiniai bandymai pažymėti kaip apmokėtą

Kai R-Keeper atmeta PostPayOrder užklausą (dažniausiai todėl, kad užsakymas užrakintas terminale), Fooodo kartoja pagal lėtesnį grafiką: 60 s → 120 s → 180 s → 240 s → 300 s — penki bandymai per ~17 minučių. Lėtesnis dažnis yra tyčinis: apmokėtas užsakymas yra derinamas, o ne blokuoja aptarnavimą, todėl suteikiame R-Keeper laiko atlaisvėti.

Jei visi penki bandymai išsenka, užsakymas baigiasi Error būsena. Fooodo mokėjimas vis tiek užregistruojamas; R-Keeper reikia greito rankinio suderinimo padavėjo.

Restoranas nepasiekiamas

Jei pats R-Keeper neveikia arba restoranas atsijungė, Fooodo automatiškai perjungia restoraną į tik skaitymo režimą (kas minutę vykdoma prieinamumo patikra tai aptinka):

• Klientui matomas meniu vis tiek įkeliamas iš talpyklos — svečiai nemato sugedusio puslapio
• Nauji užsakymai blokuojami atsiskaitymo metu su aiškiu pranešimu
• Esamų užsakymų atnaujinimai įtraukiami į eilę, o ne prarandami

Kai R-Keeper grįžta, eilėje esančios operacijos ištuštinamos ir restoranas grįžta į normalų veikimą — operatoriaus įsikišimo nereikia.

Žurnalai

Integracija rašo struktūrizuotus žurnalus keturiais pjūviais: pilnas užklausų / atsakymų pėdsakas, tik gedimų srautas, užsakymo apimties srautas ir būsenos perėjimų srautas. Partnerių palaikymo atvejais užklausų žurnalas yra pirmoji vieta, kur reikia žiūrėti — dažniausia priežastis, kodėl „užsakymas nepasiekė virtuvės", yra trumpalaikis R-Keeper gedimas, kurio nepadengė pakartotinių bandymų biudžetas, o gedimų srautas tai iš karto parodo.

Imitacinis režimas kūrimui

Kūrimo aplinkos gali veikti su visiškai imituojamu R-Keeper srautu — naudinga partnerių integruotojams, norintiems testuoti Fooodo meniu programėlę be gyvo R-Keeper egzemplioriaus. Išbandymo aplinka atitinka gamybą, naudodama R-Keeper testavimo aplinką; gamyboje imitacinis režimas niekada nenaudojamas.

Ką mato virtuvė

Sutartis yra tokia: per Fooodo sukurtas užsakymas R-Keeper sistemoje pasirodo neatskiriamai nuo terminale sukurto užsakymo. Tas pats spausdintuvo nukreipimas, tas pats KDS elgesys, tos pačios ataskaitos. Virtuvės darbuotojams nereikia žinoti, kad Fooodo egzistuoja, o padavėjai toliau naudoja R-Keeper lygiai taip pat, kaip darė anksčiau.

Tai yra tyčinis sprendimas. Integracija yra nematoma pagal dizainą; operacinė sistema išplečia R-Keeper, o ne jį pakeičia.