R-Keeper jungtis

R-Keeper yra tiesioginis Fooodo POS jungties sutarties etaloninis diegimas — vienintelė jungtis, šiandien veikianti gamyboje, ir forma, kurią turi atitikti kiekviena papildoma jungtis. Pati sutartis yra POS-agnostiška; naujos jungtys apimamos kiekvienam klientui atskirai ir kainodaroma pagal poreikį. Šiame puslapyje aprašoma, kaip R-Keeper pirmyn ir atgal kelionė iš tikrųjų veikia: kokie duomenys kerta ribą, kuria kryptimi, ir ko tikėtis, kai kažkas eina ne taip. Toliau pateikti POS-specifiniai metodų pavadinimai priklauso R-Keeper; atitikmenys kitose jungtys atitinka tas pačias jungties sutarties operacijas. POS sistemų tiekėjai, vertinantys, ar jų sistema gali būti prijungta, turėtų pradėti nuo POS integracijos reikalavimų — tai vertinimo lygio specifikacija, kurios tiesioginis etalonas yra šis puslapis.

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 apmokėjimo pažymėjimas yra du įrašai, esantys kritiniame kelyje; abu yra įtraukiami į eilę, kartojami su eksponentine atsitraukimo strategija ir detaliai registruojami žurnaluose. Kiti du yra papildomi.

Konfigūracija kiekvienam restoranui

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

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

Skirtingi restoranai toje pačioje Fooodo įmonėje 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 skirtoje programėlėje — ir kaip greitai klientui skirtas užsakymas pasirodo terminale.

Įrašai iš Fooodo į R-Keeper nėra suplanuoti — jie siunčiami iš karto, kai tik įvykis įvyksta (užsakymas sukurtas, užsakymas apmokėtas, žinutė išsiųsta), ir kartojami su atsitraukimo strategija, jei R-Keeper atmeta. Pakartotinių bandymų biudžetai dokumentuoti skyriuje Gedimų valdymas žemiau.

Lojalumo kainos kiekvienam stalui

Stalai gali pasirinkti lojalumo kainas dviem būdais, ir restoranas gali tuo pačiu metu naudoti abi formas:

• Kortelės taikymas 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 yra mažesnio delsimo kelias ir tas, kurį diegiame naujuose tinkluose.

Nepriklausomai nuo to, kurią formą naudoja stalas, kuponų kodų nuolaidos teisingai sluoksniuojamos 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 — senesniuose leidimuose kuponai buvo susieti su po fakto taikymo keliu ir praleisti URL nukreiptuose staluose — todėl partneriai, pereinantys nuo senesnio diegimo, turėtų patikrinti, ar jų R-Keeper pusė skaič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 susietas su kiekvienu užsakymu, kad administravimo ataskaitos galėtų suskirstyti aptarnavimą ir arbatpinigius pagal darbuotojus. 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; administravimo 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 administratoriams. Mokėjimo puslapyje padavėjas rodomas operatoriaus pusėje; svečiui skirtos padavėjo kortelės užsakymo patvirtinime 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 eksponentinės atsitraukimo strategijos 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

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

Apmokėjimo pažymėjimo pakartotiniai bandymai

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 ~15 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 skirtas 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.

Registravimas žurnaluose

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

Imitacinis režimas kūrimui

Kūrimo aplinkos gali veikti su R-Keeper srautu, imituojamu nuo galo iki galo — tai naudinga partnerių integruotojams, norintiems testuoti su Fooodo meniu programėle be tiesioginio R-Keeper egzemplioriaus. Išbandymo aplinka atitinka gamybą, jungiasi prie R-Keeper testavimo aplinkos; gamyboje imitacinis režimas niekada nenaudojamas.

Ką mato virtuvė

Sutartis yra tokia: užsakymas, sukurtas per Fooodo, pasiekia R-Keeper neatskiriamai nuo užsakymo, sukurto terminale. 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.