Reservations

To schedule events at a restaurant, users can use table reservations functionality. Syrve can be used to schedule the time and place, make up a list of guests, and plan the menu. We divide events into table reservations and banquets.

Using the API, tables can be booked on a website or mobile app, in which case, customers may choose a table in the dining room (e.g. by the window, far from the stage, or next to a power socket).

Table Reservation

This type of reservation is primarily designed to make a small group of customers sure that a table is available at a particular time of the day. In the API, reservations are given as the IReserve type which includes the following information:

• Customer (IClient) — a customer database item that stores the person’s name and contact details. The latter can be used to clarify order details.
• Expected start time and duration of the event (EstimatedStartTime, Duration). Such details allow managing seat occupancy avoiding situations when guests show up just in time to find out that their table is still seated or, vice versa, guests do not show, while their table is kept idle, and also help seat guests that come at short notice. The system may also remind the waitstaff to make a table ready for guests in advance (ShouldRemind).
• Table (ITable) — defines the table to be reserved. In the Syrve POS UI, the table will be marked as seated. A reservation sign can also be printed out and placed on the table (check PrintTableReservedCheque). Selecting several tables at a time (for a large group of guests) is not supported. Please select one table.
• The expected number of guests (GuestsCount) corresponds to the EstimatedGuestsCount property of the order. Such details show the number of persons a table should be set for, how many chairs to be used, etc. Not to be confused with the number of virtual guests (OrderItemGuest) specified by the waiter at his or her discretion.
• Custom comment (Comment). Here you can specify special customer requests, for example.
• Start time (GuestsComingTime) — actual time when guests show up; it is set when closing the reservation or when starting a banquet.

The reservation life cycle is simple: it is closed whether at the time the order is taken on the table in question (ActivateReserve) if the customer shows up and the event begins or at the time the reservation is canceled and the reason is specified (CancelReserve) if the customer didn’t show or asked to cancel the reservation. Besides, the reservation can be converted into a banquet by linking it to an order (BindReserveToOrder).

Banquets

Banquet is a reservation and an order linked together (IReserve and IOrder). Together they make it possible to expand the reservation options — agree upon the menu with the customer in advance and take an upfront payment. Usually, this functionality is required when hosting large events so that a restaurant could not only make a reservation (table or an entire dining room), but also provide the kitchen with the necessary food products, decorate the room properly, and so on.

A banquet can be created anew based on the existing order (CreateBanquet) or by linking existing order and a reservation (BindReserveToOrder), in which case, both the order and the reservation should be attached to one and the same table and the expected number of guests in both match.

Since a banquet represents a reservation linked to an order, it is closed at the time the order is closed rather than when customers show up, therefore, its life cycle along with the New and Closed statuses includes an additional intermediate status — Started.

Deletion

Closed reservations, as orders, are removed when a corresponding till shift is closed.

Open reservations and linked banquet orders should theoretically exist until closed, but due to certain data retention specifics, it is not always so. The following does not refer to the API but rather to some implementation specifics that can be changed at any time though can help avoid unpleasant irregularities. Reservations and orders are stored separately and so when new Syrve POS versions are installed, they are updated differently: reservation copies are stored on the Syrve Office server, where Syrve POS import them from at the first new version startup, whereas orders are stored and updated directly on Syrve POS terminals. This may cause data inconsistency:

• Syrve POS is updated. At the beginning (usually right after the new version first startup), reservations may be missing (IReserve), therefore, there might be no information about reserved tables at this moment whatsoever, whereas banquets may have only orders available. Missing reservations become available shortly (usually within several seconds or minutes), in which case, default notifications are sent out (ReserveChanged); reservation IDs remain unchanged. The limitation does not affect new reservations.
• Syrve POS data (e.g. due to hard drive failure) is lost. Unlike the previous paragraph where data is inconsistent for a short time and becomes available automatically, this case is abnormal and may require technical support in order to restore the data. You’re lucky if support representatives could save the data (extract it from the damaged hard drive or collect from other Syrve POS terminals), otherwise, the Syrve POS terminal would import reservations from the Syrve Office server but there would be no linked orders. A reservation, an order of which is lost, is deemed damaged. It can be restored using RecoverCorruptedReserve, but it should be noted that in this case, a new and empty order will be created instead.