Sihot PMS - SmartHOTEL Helpguide

General.

(see below for * information)

General details
Office address: Bahnhofstrasse 26-28
Postal code: D66578
City: Schiffweiler
Country: Germany

Website: www.sihot.com

* this can be a combination of letters & numbers. The hotelcode has to be unique for all clouds

** The hotel can open several room categories for SmartHOTEL and can set how many % of each opened room category is sent to SmartHOTEL.

*** Restrictions can only be applied for all rate codes under a specific room code or for all room codes belonging to a specific rate code. So not for a separate room/ rate combination. It is recommended to hotel to use only 1 of the 2 options per day

**** Close restrictions are always sent together with a CTA & CTD from Sihot. Please note that when a close is set this way for a longer period than 6 days it will not be accepted by HRS.

Connection.

Connection directly with SmartHOTEL extranet

The hotel requests an order for the interface between SIHOT and SmartHOTEL. If Sihot gets a signed offer from the hotel, the installation process starts. Sihot follows a checklist for the installation.

Once the installation is done the connection between SmartHOTEL & Sihot can be made.

Credentials

Hotelcode needs to be unique for all clouds

The code can be determined by Sihot as well as the hotel, just as long as they match. Same goes for the room codes & rate codes.

Before Sihot can push the R&A to SmartHOTEL, the PMS partner has to be set to SIHOT and the correct URL has to be set within the field production PMS. This URL will be provided by Sihot

Connection via SmartCONNECT

Once the installation is done the connection between SmartHOTEL & Sihot can be made.

Credentials

Hotelcode needs to be unique for all clouds

The code can be determined by Sihot as well as the hotel, just as long as they match. Same goes for the room codes & rate codes.

Setup via SmartCONNECT.

Settings

In case the hotel is connected with Sihot via SmartCONNECT first ensure that the business service is activated. This is required because Sihot is sending multi-level restrictions. This means that restrictions can be set on house level, rate level & room level. Also don’t forgot to sync ARI when activating the business service.

Double check with Sihot for what period they will send R&A. In most cases this is 18 months ahead which means the allotment window size has to be adjusted to 546 days.

Room types

Only the fields: roomcode, name, PMS default occupancy, PMS max occupancy & CM max occupancy have to be filled. Roomplans are not required with Sihot.

Rate types

Required rate types can be default & no R&A.

Mapping

Under mapping you have to fill the original Sihot endpoint for reservation delivery. This is unique for every hotel and will be provided by Sihot.

IATA’s

IATA codes have to be loaded in SmartCONNECT because otherwise the booking source will not become visible in Sihot.

Useful Information.

Sending R&A

A-Sync Connection

The connection with Sihot is A-Sync. This means that we first return an ACK to Sihot to confirm we received the message.
Afterwards we will return the response with either a success or an error. When an error is returned this is visible for the hotelier in their Sihot account via a notification which pops up.
The hotelier & Sihot will not get notified when SmartHOTEL only returns an ACK but no response (either success or error) afterwards

Rate structure when connected with external system (e.g.. IDEAS)

The external system will load a base rate towards Sihot
Afterwards Sihot will calculate the derived prices. These can be, for example, a room upgrade or city tax.
When an upload from an RMS comes in all rates in Sihot will be deleted and will be replaced by the new message. When, for a certain date, no price from IDEAS comes in only the calculations will be sent to the channel manager. These price updates with only the calculations will cause warnings being returned by Booking.com & Expedia that the price might be the low. As long as no availability is loaded on those days and/ or a closed restriction is loaded this is no harm. It only should happen during closed period of a hotel.

Behaviour with multi level restrictions

As already mentioned Sihot works with restrictions on house level / rate level or room level.

When a restriction is set on room level this counts for all the rate types under that room.
When a restriction is set on rate level it counts for all the rooms that rate is connected to.

The golden rule is that the most restrictive restriction always counts no matter on what level. Hereby 2 examples.

On room level DBL a minstay of 2 is loaded and on ratelevel NRF a minstay of 3 is loaded. All rates under the DBL will have a minstay of 2 except for the NRF which will have a minstay of 3. That minstay for the NRF can only be changed on rate level since it is also set on ratelevel.
There is a close on house level and also a close on room level for DBL. When the close on house level will be removed the DBL will stay closed since there is still a close on room level. That closed can only be removed on room level since the close is set on room level.

A closed restrictions and minstay / maxstay restrictions will be visible in the ARI grid in SmartCONNECT

A restriction on house level is visible on place A
A restriction on room level is visible on place B
A restriction on rate level is visible on place C

CTD / CTD restrictions are only visible on rate level in the ARI grid and not on room level or house level, but they will be processed.

Other remarks

An incoming message can be a full load, which means it is a full refresh for all rooms & rates for an entire year. Delta load means only the modified dates are sent.
Every night Sihot updates the rates for 365 days from now and sends that to SmartHOTEL. Availability & restrictions are only updated when the interface is restarted, or when a reservation, modification or cancellation is done.
Sihot is only able to send an open by default when the interface is restarted. There is no other option to trigger the open message towards the channel manager.
When Sihot sends the adjusted availability after they picked up a reservation they also send the availability for the check-out date. This does not mean Sihot also changes the availability for the check-out date. The logic is built that way on their side because other channel managers need it.

Reservation delivery

The connection with Sihot is A-sync. This implies the following applied for the reservation process

Reservation request sent by SmartHOTEL to Sihot. In SmartCONNECT this is the IFC request
Sihot responds immediately with an ACK message indicating that they received the reservation. At this moment the reservation is NOT yet processed in Sihot and could either be successful or error. SmartHOTEL is able to see those ACK responses in the logs, however those logs are only kept for a certain amount of time.
When the reservation is processed by Sihot, SmartHOTEL receives a response back which contains the reservation ID from Sihot. In SmartCONNECT this is the PMS request.
SmartHOTEL replies to this response with an ACK message that the response was received properly.
When we don’t receive the initial ACK from Sihot the reservation will go on empty XML response in SmartHOTEL. This happens a couple of minutes after offering the reservation to Sihot. We only try to offer the reservation once to Sihot. There is no retry mechanism in case of no response. When a reservation went on empty XML response the it will be sent by failover e-mail towards the hotel
In case we do receive an ACK message but followed by an error response instead of success the reservation will also go on failover e-mail

Processing a reservation within Sihot can have 3 results

Accepted
Not accepted
Accepted but with res type = error. This is the case with incorrect room id and/or rate id. In that case a default roomtype from Sihot will be added to the reservation

Other remarks:

Modifications & cancellations are automatically processed. Therefore, no manual handling from the hotel is required.
- When within a modification part of the roomstays is cancelled those roomstays will not be delivered within the modification. Sihot is not able to handle a status=cancel / modify etc on roomstaylevel.
Sihot looks at the Unique ID when picking up reservations:

In case of modifications & cancellations this unique id always has to be the same. Within SmartCONNECT always the SHO internal id of the original reservation is delivered as Unique id within each modification & cancellation of a reservation.

When Sihot is connected directly to the extranet the external OTA id is delivered as Unique id towards Sihot.

Sihot requires an expiredate within the XML. Otherwise a reservation will fail, see below example:

Other information

Sihot is able to connect with IDEAS & Duetto as RMS