XML-Format

Definition of the Structure

All the attributes are embedded in the following tags:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<SIHOT-Document>
</SIHOT-Document>

The XML-structure is marked at the end with the ASCII character EOT (hex 04). Therefore, the software engineers have a simple and powerful possibility to scan the end of the XML–structure. The EOT is added to all records from both sides. See FAQ Why does the interface not receive the data sent?.

Updates and continuous integration

This interface ensures backwards compatibility in general. Existing fields will not be changed or removed. Under very rare and special circumstances when such changes will be performed, we will state such a change in particular through this interface specification. New requests, fields and blocks can be added at any time. Each third party interface, which connects to this interface, needs to ensure that such enhancements do not affect the function of the interface in a negative way.

ISO-8601

The Date, Time and Date Time-attributes are coded according to the IS08601 definition of the ISO-Committee

Date

The international standard date notation is: YYYY-MM-DD

where YYYY is the year in the usual Gregorian calendar, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31.

For example, the fourth day of February in the year 1995 is written in the standard notation as 1995-02-04

Time

The international standard notation for the time of day is: hh:mm:ss

where hh is the number of complete hours that have passed since midnight (00-24), mm is the number of complete minutes that have passed since the start of the hour (00-59), and ss is the number of complete seconds since the start of the minute (00-60). If the hour value is 24, the minute and second values must be zero. [The value 60 for ss might sometimes be needed during an inserted leap second in an atomic time scale like Coordinated Universal Time (UTC). A single leap second 23:59:60 is inserted into the UTC time scale every few years as announced by the International Earth Rotation Service in Paris to keep UTC from wandering away more than 0.9 s from the less constant astronomical time scale UT1 that is defined by the actual rotation of the earth.]

An example time is: 23:59:59

which represents the time one second before midnight.

Combined Date/Time Formats

The symbol T is used to separate the date and time parts of the combined representation. The complete representation is as follows: 1993-02-14T13:10:30

The date and/or time components independently obey the rules already given in the sections above, with the restrictions:

The date format should not be truncated on the right (i.e., represented with lower precision) and the time format should not be truncated on the left (i.e., no leading hyphens).
When the date format is truncated on the left, the leading hyphens may be omitted.

ISO 3166

Normally, a hotel should be configured with the 2 character ISO 3166 country codes. Nevertheless, we offer the possibility to send and receive also the 3 character codes.

Definition of XML-Attributes

For all interfaces, which are provided by in XML notation, there is a minimum set of given attributes allowed in all operations, if nothing different is indicated.

These attributes are generally accepted and can occur during all operations (OC).

Attribute	Denotation	Type
RN	Room Number, see What is the difference between RN and PH?	String
ORN	Old Room Number, if room move	String
ARR	Arrival	Date Time
DEP	Departure	Date Time
LN	Language of the Guest (ISO-Code 639-1, 2 characters)	String
SALUTATION	Salutation of the Guest	String
TITLE	Title of the Guest	String
VIP	VIP	String
RNO	Reservation Number	uns. Long
RSNO	Reservation Sub number	uns. Int
SN	Surname / Last name of the guest	String
SN2	Second surname / last name of the guest	String
PCIID	Pre Check-In ID. This is a unique ID of the stay of the client in the hotel.	uns. Long
GID	Unique id of this guest	uns. Long
CN	Christian Name / First Name of the guest	String
TG	Type of guest of the clients, defined in the SIHOT-Installation , e.g. 1A = Adult 2A = Toddler…	String
AN	Account Number	Uns. Long
ORG	Origin. This is the identifier of the SIHOT workstation or the workstation of the other system that executed this operation.	String
TN	Transaction number. This is a sequential number to identify univocally a data record sent between the two parts. This tag is mandatory for all records. See FAQ Who keeps track of the Transaction Number TN?.	Uns. Long
SRC	The SRC-Attribute indicates where this operation is coming from.	String
PASSWD	Guest-Password	String
PAY-TV	Pay-TV-permission	char
PH	Phone number to be charged or phone number where the wakeup request / room status was entered, see FAQ What is the difference between RN and PH?.	uns. Long
PH0 – PH4	Phone numbers of the Room Notes: 5 digits, right justified, leading 0 With suites, PH can get beyond PH4	uns. Long
AP	Definition of the access points. The access point are defined in a key card system	String
CS	Coding Station	String
NC	Number of cards	uns. Byte
CA	Card action	String
PPU	Price per unit (including taxes, vat, …) in hotel currency	BCD
UN	Units	Long
AMOUNT	Total amount = PPU * UN	BCD
HN	Number of the hotel – each hotel has a `<HN>`	uns. Long
MC	Market code (type) of the guest. Please keep into account that in SIHOT a guest can have different market codes during the stay. In the IF always the market code of the arrival date of the guest is transferred.	String
SF	Share flag.	Char
GTD	Type of the guest	String
GNR	Number of the guest	String
GMD	Number of the hotel where the guest data is stored	String
GDB	Debtor number of the guest	String
HQGID	Central ID of the guest	String
CREQ	Credit request of the guest	String
CREQSTATE	State of the credit request of the guest	String
ROOMSIMPLIED	Adds a list of rooms that are implied in a suite if a record is sent for a suite and not for a single room	String
BEDSIMPLIED	Adds a list of beds that are implied in a room if there are beds defined in a room	String
BED	Contains the data of a bed in a room, currently consisting of `<BEDNO>` and `<BEDKCID>`
BEDNO	Bed number	String
BEDKCID	Using the keycard ID of the bed instead of the bed number, if available.	String
OBED	Old bed number if room move	String
ENTIREROOM	The flag indicates if the checkout (CO) should be done only for certain person in the CO operation or the whole room.
CARD	Contains the data of a card from a guest.
NR_FOR_THIS	The number of the bed, room or suite that triggered this record. An external system can rely on this number e.g. to create a keycard so that it does not need to find out if the room number or the bed number should be used.	String
KCID_FOR_THIS	The key card ID associated to the NR_FOR_THIS	String

Extensions specific to one interface can be indicated at any time in the interface directly.

Note: There are additional OCs and tags that are only for internal use, see FAQ How do I handle unknown tags or records?.

PCIID (Pre Check In ID)

The PCIID is a unique ID that identifies a guest during one stay in a hotel. It is already available when the reservation is made and so it can be used in the forecast. The important thing is that it remains the same during the complete stay of the guest so if the guest moves or checks out or even if his name is changed to a completely different guest with a different GID, the PCIID will not change. When the same guest returns, he will have a different PCIID for his next stay. To be more precise, it does not directly identify a guest but an entry in the list of persons assigned to a reservation.

To clarify this, here an example: When you enter a reservation in SIHOT, there is created an entry in the list of persons for each person that is part of this reservation.

E.g. 3 PAX from 01/03/2005 to 05/03/2005. So this reservation contains a list of 3 PAX:

Person A with PCIID 4711
Person B with PCIID 4712
Person C with PCIID 4713

You can assign names to these persons at any time before or after the check in. E.g. when the reservation is made, just one name is known, so PCIID 4711 is assigned the name “Smith” with GID 37623. This results in a GC with GID 37623 and PCIID 4711.

At check in, you change the name of the guest from “Smith” to “Black” with GID 92866 so you get a GC with GID 92866 and PCIID 4711. So this just means that the name of the person was changed, not that the person itself moved from one room to another or was checked out. You will also receive a CI for the PCIID 4711 with the GID 92866 and the room number. If the guest moves to another room, e.g. 302, you will receive a RM from 101 to 302 with the PCIID 4711 and at the checkout you will receive a CO with the same PCIID.

So to keep track of a guest, it is in general better to use the PCIID since this remains the same all the time while the GID might change.

Note: If the guest “Black” with the GID 92866 comes again from 06/03/2005 to 07/03/2005, he will get a different PCIID but if he prolongs his stay to the 07/03/2005, he will keep the PCIID 4711 until he checks out.

Important

Unknown attributes (tags) or records with unknown OCs have to be ignored by the interface! This means that these records are not evaluated but acknowledged with a return code of “99”. If configured properly, the interface will only receive records with OCs that are evaluated by this interface. The tag <HN> is only needed in an environment with several properties. It is used to assign identical room numbers to the correct hotel. If the tag <HN> is not sent, the currently active environment (defined in the database of SIHOT) is used.

Directions of OCs

OC	Description	From	To
TS	Time Sync	SIHOT	Interface
LA	Link Alive	SIHOT	Interface
LA	Link Alive	Interface	SIHOT
CO	Check Out	SIHOT	Interface
CO	Check Out	Interface	SIHOT
PCO	Pre Check Out	SIHOT	Interface
RM	Room Move	SIHOT	Interface
ACK	Acknowledge	SIHOT	Interface
ACK	Acknowledge	Interface	SIHOT
PS	Posting simple	Interface	SIHOT
PE	Posting extended	Interface	SIHOT
PP	Posting payment	Interface	SIHOT
COS	Class of Service	SIHOT	Interface
GI	Guest Information	SIHOT	Interface
GC	Guest Change	SIHOT	Interface
SM	Send Message	Interface	SIHOT
WU	Wake Up Message	SIHOT	Interface
WU	Wake Up Message	Interface	SIHOT
WA	Wake Up Answer	Interface	SIHOT
RST	Room Status	Interface	SIHOT
DR	Document reader	Interface	SIHOT
RS	Restart	Interface	SIHOT
PAR	Payment request	SIHOT	Interface
PAA	Payment answer	Interface	SIHOT
EXMSG	Extended message	SIHOT	Interface
MS	Message status	Interface	SIHOT
RO	Room occupancy	SIHOT	Interface
TR	Transaction	Interface	SIHOT
RF	Request Forecast	Interface	SIHOT
RR	Room Request	Interface	SIHOT
FC	Forecast	SIHOT	Interface
CR	Change reservation	SIHOT	Interface
FSOA	Request of a Statement of Account	Interface	SIHOT
SOA	Statement of Account	SIHOT	Interface
PRECHECKIN	Pre Check In	SIHOT	Interface
KEYDETAIL	Details of the key	Interface	SIHOT
AC	Assign / delete card	SIHOT	Interface

Error Handling (ACK)

All exchanged operations (OC) return a feedback to the sender. See Acknowledge.

Important Hint

The external system needs to wait until it receives the <ACK> or until the socket is disconnected. Should the socket be disconnected, the external system can assume a crash of the interface and handle this as an <ACK> with an error code.

If the external system nonetheless needs to use a timeout how long it waits for the <ACK>, this timeout should at least be one minute. Our system is a server where many processes interact and not a real time server just for this interface. Normally, the <ACK> will be sent within a second but it might even take longer than a minute depending on system load and database access by other services or users.

Should the external system deny a service since its timeout ended before the <ACK> on the posting record was received, it still needs to process the <ACK> when it comes later.

E.g. if a Pay-TV system sends a posting and its timeout ended before it receives the <ACK>, it may decide not to show the movie. If it receives the <ACK> later and the RC is 0, this means that the posting was done correctly in SIHOT.PMS. Since the movie was not shown, the Pay-TV system should send a cancellation of the posting immediately. Alternatively, it needs at least to show and log this problem.

Night Audit

There are no messages to send a “start of night audit” and “end of night audit”, because SIHOT can process postings also during the night audit.