Reserves

For event planning, there is functionality for table reservations in the restaurant halls. Depending on the event, it is possible to plan the time and place of its holding, the guest list, and the menu in advance. Based on the level of event preparation, reserves are divided into two categories: table reservations and banquets.

Using the API, table reservations can be implemented through the website or mobile application, allowing the client to independently choose their preferred location in the hall (for example, by the window, away from the stage, or near a power outlet).

Table Reservations

This type of reserve is mainly used to guarantee the availability of a free table for the evening for a small group of guests. In the API, reserves are represented by the IReserve type, which includes the following information:

• Client (IClient) — an element of the client directory, stores the name of the person and their contact details. Allows for communication if clarification of details is necessary.
• Expected start time and duration of the event (EstimatedStartTime, Duration). This information allows for effective management of the restaurant halls, avoiding situations where guests arrive at the scheduled time and their table is occupied, or conversely, guests do not arrive and their table is idle, helping to seat guests who arrive without notice. The system can also remind waiters in advance to prepare the table for the arrival of guests (ShouldRemind).
• Table (ITable) — defines the reserved table. In the SyrveFront interface, the table will be marked as occupied, and it is additionally possible to print and place a special sign about the reservation on the table (see PrintTableReservedCheque). Reserving multiple tables at once (for a large group of guests) is not supported; one table must be selected.
• Expected number of guests (GuestsCount), corresponds to the EstimatedGuestsCount property of the order. This information indicates how many settings to prepare for the table, how many chairs to place, etc. Do not confuse with the number of virtual guests (OrderItemGuest), which the waiter determines at their discretion.
• Arbitrary comment (Comment). Here, special requests from the client can be specified, for example.
• Arrival time (GuestsComingTime) — the actual time of guest arrival, set at the moment of closing the reservation or at the start of the banquet.

The lifecycle of a reserve is simple — it is closed either with the creation of an order at the corresponding table (ActivateReserve), if the client has arrived and the planned event has started, or with the indication of a cancellation reason (CancelReserve), if the client requested to cancel the reservation or did not arrive at the scheduled time. Additionally, a reserve can be converted into a banquet by attaching an order to it (BindReserveToOrder).

Banquets

A banquet is a combination of a reserve and an order (IReserve and IOrder). Their joint use allows for additional capabilities of the reserve to agree on the menu with the client in advance and make a prepayment. This is usually used for large events so that the restaurant can not only reserve a table (or more often an entire banquet hall) but also purchase products for the kitchen for the upcoming event, decorate the premises properly, and more.

A banquet can be created from scratch, based on an existing order (CreateBanquet), or by connecting a previously created order and reserve (BindReserveToOrder), provided that the order and reserve are at the same table and the expected number of guests matches.

Since a banquet represents a reserve linked to an order, it is closed not at the moment of guest arrival, but upon closing the order; accordingly, its lifecycle, in addition to the statuses New and Closed, contains an additional intermediate status — Started.

Deletion

Like orders, closed reserves are deleted when the corresponding cash shift is closed.

Open reserves and their associated banquet orders theoretically should exist until they are closed, but due to the peculiarities of the storage mechanism, this is not always the case. The information presented below does not relate to the API; it is an implementation detail that may change at any time, but knowing it can help avoid unpleasant surprises. Reserves and orders are stored separately, and when new versions of SyrveFront are installed, they are updated differently: reserve data is stored on the SyrveRms server, from which SyrveFront loads them at the first launch of the new version, while orders are stored and updated directly on the SyrveFront terminals. This can lead to inconsistencies:

• SyrveFront has been updated. For a while (usually immediately after the first launch of the new version), reserves (IReserve) may be absent, and thus there will be no information on reserved tables at that moment, while only orders for banquets will be available. Missing reserves will become available within a short time (usually a few seconds or minutes), during which standard notifications (ReserveChanged) will be sent, and the reserve identifiers will remain unchanged. This limitation does not affect the creation of new reserves.
• Lost data stored on the SyrveFront terminal (for example, the hard drive failed). Unlike the previous case, where data is in an inconsistent state for a short time and is restored automatically, this case is an emergency and may require contacting technical support to recover lost data. It is good if specialists can recover the data (extract it from the damaged disk, gather it from other SyrveFront terminals); otherwise, the SyrveFront terminal will load reserves from the SyrveRms server, but there will be no associated orders. A reserve with a lost order is considered corrupted. It can be restored using RecoverCorruptedReserve, but it should be understood that this will only create a new empty order instead of the lost one.