Common Concepts
Walk-ins vs reservations
In ResDiary, there are two types of bookings:
Walk-ins.
Reservations.
The only difference between the two is that walk-ins do not have a customer record attached to them, whereas reservations do. To create either of these types of booking, use the Add Booking request. When creating a walk-in, simply do not include the "Customer" property with the request, or send it with a value of null.
The term "booking" may be used to indicate both walk-ins and reservations in this documentation.
VisitDateTime vs BookingDateTime
Each booking in ResDiary has a VisitDateTime and a BookingDateTime associated with it. The VisitDateTime is the time that the customer is due to arrive at the restaurant, whereas the BookingDateTime is a timestamp that records when the booking was created. The BookingDateTime is readonly and does not need to be supplied when creating bookings.
Segments
A segment is a period in time that certain restaurant settings are valid for. Restaurants can use this to alter details like their opening hours, tables, services and various other bits of configuration for special occasions such as Christmas, Valentine's day, etc.
The segments for a particular restaurant can be found by making a Get Restaurant request. This includes all the segments for the restaurant (including ones that are no-longer valid).
Each segment has a TimeScopes collection which can be used to determine when it it valid. Each time scope has a start date (inclusive) and an end date (exclusive) which specifies the range of dates during which the segment is valid.
For example, a Christmas segment might be defined as follows:
{
"Name": "Christmas",
"TimeScopes": [
{
"FromDate": "\/Date(1480896000000)\/",
"ToDate": "\/Date(1482451200000)\/"
},
{
"FromDate": "\/Date(1512345600000)\/",
"ToDate": "\/Date(1513900800000)\/"
}
],
"Areas": [...],
"Services": [...],
"Tables": [...]
}Services
A service is a range of time that a restaurant is available for walk-ins and reservations. Restaurants can have one or more services in a day. Example services include Breakfast, Lunch and Dinner, although restaurants are free to create whatever services they want.
Each service has the following pieces of information:
StartTime
The first available time for a booking within the service.
EndTime
The end of the service.
LastBookingTime
The last available time for booking in this service. VisitDateTimes after this point and before the end of the service are not valid.
TimeSlotInterval
The number of minutes in each timeslot in the service.
If a service crosses midnight then visit times after midnight are still considered to be part of the current restaurant day. So, for example, in a restaurant where the dinner service runs from 19:00 to 02:00 then a booking made for Monday at 01:00 will appear in the diary as a Monday booking but will actually have a visit time of 01:00 on Tuesday.
Transferring tables
If a table is moved on the EPOS system it should also be moved within ResDiary. You can do this either by using the Update Booking method, or by using the Update Booking Tables method. In both cases you'll need to use the ids of the tables from the ResDiary system. Once the table is transferred ResDiary will return an updated booking object. If the target table is not suitable due to constraints, you'll get an exception back with a short description for the reason why the move couldn't be completed.
Joined tables
ResDiary supports the concept of joined tables; that is, a booking can be created across multiple tables. We allow the EPOS Service access to this in two ways:
When you select Next Free Tables, the list of next free tables may include tables which are joined. You can create a booking up to the maximum number of covers on that table or join. You may wish to offer a list of these to your users rather than get them to create a booking as a walk-in. Joined tables will be displayed when there are no more single tables available.
Where you are finding a pre-existing booking, that booking may be using a join already. You may wish to offer your users a selection of the current bookings so that they use the pre-existing bookings rather than trying to force a walk-in onto a table which does not have the capacity. You can get a list of pre-existing bookings for the day using the "Get Diary Data" method.
Closing tables (bookings)
When closing a booking, you should use Update Meal Status to update the booking's meal status to Closed. You should note that, closing the booking does not extend its duration when the leave time is in the past, but will shrink it if the leave time is in the future.
If you want to achieve this, you'll need to use the "Update Booking" method and explicitly set the new duration of the booking. However depending on the setup of the restaurant, you may notice that you won't be able to extend the duration if that causes a clash with an upcoming booking and the restaurant has not given permission for EPOS systems to unallocate bookings automatically. When this happens please contact the person responsible for managing the restaurant setup and ask them to allow the EPOS system to automatically unallocate and reallocate bookings.
A list of valid meal statuses can be found in the documentation for each method where you can set it. You will need to match each meal status that your system uses to the relevant status in the ResDiary system.
Adding a receipt to a booking
When a table is paid/closed on the POS, the contents of the receipt can be transferred to ResDiary using the Add Receipt request.
The contents of the receipt must be valid XML and must conform to the format supported by the ResDiary application. The receipt must be defined as follows:
Where the Description is a free text field, the Quantity is the number of items purchased, and the Price is the total price (i.e. in the example above, a single coffee would cost 5.00 whereas both together costs 10.00).
Last updated
Was this helpful?