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-neatkarīgs; 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. Zemā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. POS piegādātājiem, kas vērtē, vai viņu sistēmu var pievienot, jāsāk ar POS integrācijas prasībām — tā ir novērtēšanas līmeņa specifikācija, kuras tiešraides atsauce ir šī lapa.

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 ieraksta R-Keeper

Pasūtījuma izveide un apmaksas atzīmēšana ir divi ieraksti, kas atrodas kritiskajā ceļā; abi tiek ievietoti rindā, atkārtoti mēģināti ar eksponenciālu atkāpšanos un detalizēti reģistrēti žurnālā. Pārējie divi ir papildinoši.

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 iekšienē
• 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ī.

Ieraksti no Fooodo uz R-Keeper nav ieplānoti — tie tiek nosūtīti tiklīdz notiek notikums (pasūtījums izveidots, pasūtījums apmaksāts, ziņojums nosūtīts) un tiek atkārtoti mēģināti 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 galds ir konfigurēts ar restorāna līmeņa lojalitātes kartes kodu, 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 galds ir konfigurēts ar 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 galds izmanto, kupona kodu atlaides tiek pareizi uzliktas virsū: viesis ar lojalitātes karti joprojām var izmantot kuponu, un kupona atlaide nonāk 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ētajos galdos — tāpēc partneriem, kas pāriet no vecākas izvietošanas, 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 direktorija sinhronizācija darbojas katru nakti plkst. 08:45 un atjauno viesmīļu sarakstu no ķēdes personāla sistēmas — vārdi, amatu nosaukumi un ārējie 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 veidi, 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ālās 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ārtotie mēģinājumi 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āja, atstājot pasūtījumu atvērtu terminālī, un labojums ir aizvērt to tieši R-Keeper.

Apmaksas atzīmēšanas atkārtotie mēģinājumi

Kad R-Keeper noraida PostPayOrder izsaukumu (visbiežāk tāpēc, ka pasūtījums ir bloķēts terminālī), Fooodo atkārto mēģinājumus pēc lēnāka grafika: 60 s → 120 s → 180 s → 240 s → 300 s — pieci mēģinājumi ~15 minūšu laikā. Lēnāks biežums 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 mēģinājumi izsmeļas, pasūtījums beidzas ar Error. 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 ir neaktīvs 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 operācijas 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 pēdas ceļš, 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 "pasūtījums nesasniedza virtuvi" cēlonis ir īslaicīgs R-Keeper pārtraukums, ko atkārtošanas budžets nepārklāja, un kļūmju plūsma to nekavējoties atklāj.

Imitācijas režīms izstrādei

Izstrādes vides var darboties ar R-Keeper trafiku imitētu no gala līdz galam — noderīgi partneru integrētājiem, kas vēlas testēt pret Fooodo ēdienkartes lietotni bez tiešraides 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šķirams 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ētājsistēma paplašina R-Keeper, tā to neaizstāj.