R-Keeper savienotājs

R-Keeper ir Fooodo POS savienotāja līguma tiešraides atsauces implementācija — vienīgais savienotājs, kas šodien darbojas ražošanā, un forma, uz kuru balstās katrs papildu savienotājs. Pats līgums ir POS-neitrāls; jauni savienotāji tiek definēti katram klientam atsevišķi un piedāvāti pēc pieprasījuma. Šī lapa dokumentē, kā R-Keeper aprites cikls faktiski darbojas: kādi dati šķērso robežu, kādā virzienā, un ko sagaidīt, kad kaut kas noiet greizi. Tālāk norādītie POS-specifiskie metožu nosaukumi pieder R-Keeper; ekvivalenti citos savienotājos atbilst tām pašām savienotāja līguma operācijām.

Ko Fooodo pieprasa no R-Keeper

Šie ir tikai lasīšanas izsaukumi — Fooodo nekad nemaina R-Keeper ēdienkarti, cenas, modifikatorus vai atsauces datus.

Ko Fooodo raksta R-Keeper

Pasūtījuma izveide un apmaksas atzīmēšana ir divas rakstīšanas darbības, kas atrodas kritiskajā ceļā; abas tiek ievietotas rindā, atkārtotas ar eksponenciālu atkāpšanos un detalizēti reģistrētas žurnālā. Pārējās divas ir papildinošas.

Konfigurācija katram restorānam

R-Keeper akreditācijas dati glabājas restorāna konfigurācijā. Katrs restorāns Fooodo sistēmā satur:

• API galapunkta URL
• Restorāna ID R-Keeper sistēmā
• Neobligātu lojalitātes cenu galapunktu
• Neobligātu lojalitātes karšu programmas kodu
• Neobligātu ēdienkartes vienuma kodu dzeramnaudas maršrutēšanai

Dažādi restorāni vienā Fooodo uzņēmumā var norādīt uz dažādiem R-Keeper gadījumiem. Tā šodien darbojas vairāku atrašanās vietu ķēdes.

R-Keeper sinhronizācijas biežums

Integrācija aptaujā un nosūta datus pēc vairākiem dažādiem grafikiem. Operatori un partneru atbalsta inženieri rūpējas par šiem grafikiem, jo tie nosaka cerības attiecībā uz to, cik ātri izmaiņas biroja sistēmā parādās klientam redzamajā lietotnē — un cik ātri klientam redzamais pasūtījums parādās terminālī.

Rakstīšana no Fooodo uz R-Keeper nav ieplānota — tā notiek tūlīt, kad notiek notikums (pasūtījums izveidots, pasūtījums apmaksāts, ziņojums nosūtīts), un atkārtojas ar atkāpšanos, ja R-Keeper noraida. Atkārtošanas budžeti ir dokumentēti sadaļā Kļūmju apstrāde zemāk.

Lojalitātes cenas katram galdam

Galdi var izmantot lojalitātes cenas divos veidos, un restorāns var vienlaikus izmantot abas formas:

• Kartes pielietošana pēc fakta. Ja galdam ir konfigurēts restorāna līmeņa lojalitātes kartes kods, Fooodo pielieto karti pēc pasūtījuma eksportēšanas — R-Keeper pārrēķina rindas vienības ar kartes atlaides loģiku, un Fooodo atspoguļo koriģētās kopsummas viesim. Pasūtījums tiek eksportēts vienu reizi un pēc tam labots.
• URL-maršrutētas alternatīvas cenas. Ja galdam ir konfigurēts lojalitātes cenu savienotāja URL, Fooodo pieprasa R-Keeper lojalitātes cenu ēdienkarti pirms viesis redz cenas. Grozs, modifikatoru cenas, kopsummas — viss, ko viesis redz, jau ir lojalitātes cena. Šis ir mazākas latentuma ceļš, un tas ir tas, ko mēs izvietojam jaunās ķēdēs.

Neatkarīgi no tā, kuru formu galdam izmanto, kuponu kodu atlaides tiek pareizi uzliktas virsū: viesis ar lojalitātes karti joprojām var izmantot kuponu, un kupona atlaide sasniedz R-Keeper neatkarīgi no lojalitātes ceļa. Tas ne vienmēr tā bija — vecākās versijās kuponi bija atkarīgi no pēcfakta ceļa un tika izlaisti URL-maršrutētiem galdiem — tāpēc partneriem, kas pāriet no vecāka izvietojuma, jāpārbauda, vai viņu R-Keeper puse ņem vērā abas ietekmes.

Lojalitātes cenas nāk no R-Keeper. Fooodo neuztur paralēlu atlaižu tabulu.

Personāls un pasūtījumu attiecinājums

Fooodo reģistrē, kurš viesmīlis ir saistīts ar katru pasūtījumu, lai administratīvie pārskati varētu sadalīt apkalpošanu un dzeramnaudu pēc personāla. Plūsmai ir divas daļas:

• Personāla direktorijas sinhronizācija darbojas katru nakti plkst. 08:45 un atjauno viesmīļu sarakstu no ķēdes personāla sistēmas — vārdus, amatus un ārējos personāla ID, kas atbilst R-Keeper. Viesmīļi Fooodo netiek izveidoti manuāli; administratora saraksts ir tikai lasāms.
• Pasūtījuma attiecinājums notiek, kad pasūtījums tiek iegūts vai atjaunināts no R-Keeper. R-Keeper pasūtījuma statusa atbilde satur piešķirtā viesmīļa ID; Fooodo to saskaņo ar sinhronizēto personāla direktoriju un ieraksta attiecinājumu pasūtījumā. Rēķina sadalīšanas bērni manto vecāka viesmīli.

Šodien šis attiecinājums ir redzams tikai administratoriem. Maksājumu lapa atklāj viesmīli operatora pusē; viesim redzama viesmīļa kartīte pasūtījuma apstiprinājumā vēl nav pieejama. Šī virsma ir ceļvedī.

Kļūmju apstrāde

Integrācija ir izstrādāta tā, lai tolerētu īslaicīgu R-Keeper nepieejamību. Trīs kļūmju scenāriji, ko redzēsiet praksē:

Bloķēti pasūtījumi

R-Keeper atgriež specifiskus kļūdu kodus (2219 vai 13), kad viesmīlis ir atvēris pasūtījumu biroja terminālī. Fooodo reakcija:

• Atzīmēt pasūtījumu kā Locked
• Atkārtot eksportēšanu pēc eksponenciālas atkāpšanās grafika (5 s → 10 s → 20 s → 40 s → 80 s — pieci mēģinājumi, kopā ~155 sekundes)
• Ja visi atkārtojumi neizdodas, eskalēt uz Error

Normālā darbībā bloķēšana ilgst sekundes. Pastāvīga bloķēšana parasti nozīmē, ka viesmīlis aizgājis, atstājot pasūtījumu atvērtu terminālī, un risinājums ir aizvērt to tieši R-Keeper sistēmā.

Apmaksas atzīmēšanas atkārtojumi

Kad R-Keeper noraida PostPayOrder izsaukumu (visbiežāk tāpēc, ka pasūtījums ir bloķēts terminālī), Fooodo atkārtojas pēc lēnāka grafika: 60 s → 120 s → 180 s → 240 s → 300 s — pieci mēģinājumi ~17 minūšu laikā. Lēnāks ritms ir apzināts: apmaksāts pasūtījums tiek saskaņots, nevis bloķē apkalpošanu, tāpēc mēs dodam R-Keeper laiku atbrīvoties.

Ja visi pieci atkārtojumi izsmeļas, pasūtījums nonāk Error stāvoklī. Fooodo maksājums joprojām ir reģistrēts; R-Keeper ir nepieciešama ātra manuāla saskaņošana no viesmīļa puses.

Restorāns nesasniedzams

Ja R-Keeper pats nav pieejams vai restorāns ir pārgājis bezsaistē, Fooodo automātiski pārslēdz restorānu uz tikai lasīšanas režīmu (katru minūti veiktā pieejamības pārbaude to uztver):

• Klientam redzamā ēdienkarte joprojām tiek ielādēta no kešatmiņas — viesi neredz bojātu lapu
• Jauni pasūtījumi tiek bloķēti norēķināšanās brīdī ar skaidru ziņojumu
• Esošo pasūtījumu atjauninājumi tiek ievietoti rindā, nevis nomesti

Kad R-Keeper atgriežas, rindā esošās darbības tiek apstrādātas un restorāns atgriežas normālā darbībā — operatora iejaukšanās nav nepieciešama.

Reģistrēšana

Integrācija raksta strukturētus žurnālus četros griezumos: pilns pieprasījumu/atbilžu pieraksts, tikai kļūmju plūsma, pasūtījumam piesaistīta plūsma un stāvokļa pāreju plūsma. Partneru atbalsta gadījumiem pieprasījumu žurnāls ir pirmā vieta, kur meklēt — visbiežākais iemesls "pasūtījums nesasniedza virtuvi" ir īslaicīgs R-Keeper darbības pārtraukums, ko atkārtošanas budžets nepārklāja, un kļūmju plūsma to uzrāda nekavējoties.

Imitācijas režīms izstrādei

Izstrādes vides var darboties ar pilnībā imitētu R-Keeper trafiku — noderīgi partneru integrētājiem, kas vēlas testēt pret Fooodo ēdienkartes lietotni bez dzīva R-Keeper gadījuma. Testēšanas vide atspoguļo ražošanu, savienojoties ar R-Keeper testa vidi; ražošana nekad nedarbojas imitācijas režīmā.

Ko virtuve redz

Līgums ir šāds: pasūtījums, kas izveidots caur Fooodo, nonāk R-Keeper neatšķirami no pasūtījuma, kas izveidots terminālī. Tāda pati printera maršrutēšana, tāda pati KDS uzvedība, tādi paši pārskati. Virtuves personālam nav jāzina, ka Fooodo pastāv, un viesmīļi turpina izmantot R-Keeper tieši tāpat kā iepriekš.

Tas ir apzināti. Integrācija pēc dizaina ir neredzama; operāciju sistēma paplašina R-Keeper, tā to neaizstāj.