Rezerwacje

Aby zaplanować wydarzenia w restauracji, użytkownicy mogą korzystać z funkcji rezerwacji stolików. Syrve może służyć do ustalania czasu i miejsca, tworzenia listy gości oraz planowania menu. Wydarzenia dzielimy na rezerwacje stolików oraz bankiety.

Korzystając z API, stoliki można rezerwować na stronie internetowej lub w aplikacji mobilnej, w takim przypadku klienci mogą wybrać stolik w sali jadalnej (np. przy oknie, z dala od sceny lub obok gniazdka elektrycznego).

Rezerwacja stolika

Ten typ rezerwacji jest przede wszystkim przeznaczony do zapewnienia małej grupie klientów, że stolik będzie dostępny o określonej porze dnia. W API rezerwacje są reprezentowane jako typ IReserve, który zawiera następujące informacje:

• Klient (IClient) — element bazy danych klienta przechowujący imię i nazwisko oraz dane kontaktowe osoby. Te ostatnie mogą być użyte do wyjaśnienia szczegółów zamówienia.
• Oczekiwany czas rozpoczęcia i czas trwania wydarzenia (EstimatedStartTime, Duration). Takie dane pozwalają zarządzać zajętością miejsc, unikając sytuacji, gdy goście przychodzą na czas, aby dowiedzieć się, że ich stolik jest jeszcze zajęty lub odwrotnie, gdy goście się nie pojawiają, a stolik pozostaje nieużywany, a także pomagają usadzić gości przybyłych na krótką chwilę. System może również przypominać obsłudze, aby przygotowała stolik dla gości z wyprzedzeniem (ShouldRemind).
• Stolik (ITable) — definiuje stolik, który ma zostać zarezerwowany. W interfejsie Syrve POS stolik zostanie oznaczony jako zajęty. Można także wydrukować znak rezerwacji i umieścić go na stoliku (sprawdź PrintTableReservedCheque). Nie jest obsługiwane wybieranie kilku stolików naraz (dla dużej grupy gości). Proszę wybrać jeden stolik.
• Oczekiwana liczba gości (GuestsCount) odpowiada właściwości EstimatedGuestsCount zamówienia. Dane te pokazują, dla ilu osób stolik powinien być przygotowany, ile krzeseł użyć itd. Nie należy mylić tego z liczbą wirtualnych gości (OrderItemGuest) określonych według uznania kelnera.
• Własny komentarz (Comment). Tutaj można podać specjalne życzenia klienta, na przykład.
• Czas przybycia (GuestsComingTime) — rzeczywisty czas pojawienia się gości; jest ustawiany podczas zamykania rezerwacji lub rozpoczęcia bankietu.

Cykl życia rezerwacji jest prosty: jest ona zamykana albo w momencie przyjęcia zamówienia na dany stolik (ActivateReserve), jeśli klient się pojawi i wydarzenie się rozpocznie, albo w momencie anulowania rezerwacji wraz z podaniem powodu (CancelReserve), jeśli klient się nie pojawił lub poprosił o anulowanie rezerwacji. Ponadto rezerwacja może zostać przekształcona w bankiet przez powiązanie jej z zamówieniem (BindReserveToOrder).

Bankiety

Bankiet to rezerwacja i zamówienie powiązane ze sobą (IReserve oraz IOrder). Razem umożliwiają rozszerzenie opcji rezerwacji — wcześniejsze uzgodnienie menu z klientem oraz pobranie zaliczki. Zazwyczaj funkcjonalność ta jest potrzebna przy organizacji dużych wydarzeń, aby restauracja mogła nie tylko dokonać rezerwacji (stolik lub całą salę), ale także zapewnić kuchni niezbędne produkty spożywcze, odpowiednio udekorować salę itd.

Bankiet można utworzyć na nowo na podstawie istniejącego zamówienia (CreateBanquet) lub przez powiązanie istniejącego zamówienia i rezerwacji (BindReserveToOrder), w takim przypadku zarówno zamówienie, jak i rezerwacja powinny być przypisane do tego samego stolika, a oczekiwana liczba gości w obu powinna się zgadzać.

Ponieważ bankiet reprezentuje rezerwację powiązaną z zamówieniem, jest on zamykany w momencie zamknięcia zamówienia, a nie wtedy, gdy pojawią się klienci, dlatego jego cykl życia wraz ze statusami New i Closed zawiera dodatkowy status pośredni — Started.

Usuwanie

Zamknięte rezerwacje, podobnie jak zamówienia, są usuwane po zamknięciu odpowiadającej zmiany kasowej.

Otwarte rezerwacje i powiązane zamówienia bankietowe teoretycznie powinny istnieć do momentu zamknięcia, jednak ze względu na pewne specyfiki przechowywania danych nie zawsze tak jest. Poniższe dotyczy nie API, lecz pewnych szczegółów implementacyjnych, które mogą zostać zmienione w dowolnym momencie, ale mogą pomóc uniknąć nieprzyjemnych nieprawidłowości. Rezerwacje i zamówienia są przechowywane oddzielnie, więc przy instalacji nowych wersji Syrve POS są aktualizowane inaczej: kopie rezerwacji są przechowywane na serwerze Syrve Office, skąd Syrve POS importuje je przy pierwszym uruchomieniu nowej wersji, natomiast zamówienia są przechowywane i aktualizowane bezpośrednio na terminalach Syrve POS. Może to powodować niespójność danych:

• Syrve POS jest aktualizowany. Na początku (zazwyczaj zaraz po pierwszym uruchomieniu nowej wersji) mogą brakować rezerwacji (IReserve), w związku z czym w tym momencie może nie być żadnych informacji o zarezerwowanych stolikach, podczas gdy bankiety mogą mieć dostępne tylko zamówienia. Brakujące rezerwacje pojawiają się wkrótce (zazwyczaj w ciągu kilku sekund lub minut), w takim przypadku wysyłane są domyślne powiadomienia (ReserveChanged); identyfikatory rezerwacji pozostają niezmienione. Ograniczenie to nie dotyczy nowych rezerwacji.
• Dane Syrve POS (np. z powodu awarii dysku twardego) zostają utracone. W przeciwieństwie do poprzedniego punktu, gdzie dane są niespójne przez krótki czas i stają się dostępne automatycznie, ten przypadek jest nieprawidłowy i może wymagać wsparcia technicznego w celu odzyskania danych. Masz szczęście, jeśli przedstawiciele wsparcia będą mogli uratować dane (wyciągnąć je z uszkodzonego dysku lub zebrać z innych terminali Syrve POS), w przeciwnym razie terminal Syrve POS zaimportuje rezerwacje z serwera Syrve Office, ale nie będzie powiązanych zamówień. Rezerwacja, której zamówienie zostało utracone, jest uznawana za uszkodzoną. Można ją przywrócić za pomocą RecoverCorruptedReserve, jednak należy zauważyć, że w takim przypadku zostanie utworzone nowe, puste zamówienie.