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 such change will performed, we will state out such a change in particular through this interface specification. New request, fields, blocks can be added anytime. Each third party interface, which connects to this interface, needs to ensure that such enhancement does not affect the function of the interface in a negative way.
The Date, Time and Date Time-attributes are coded according to the IS08601 definition of the ISO-Committee
The international standard date notation is:
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
The international standard notation for the time of day is:
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, then 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:
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:
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
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).
|RN||Room Number, see What is the difference between RN and PH?||String|
|ORN||Old Room Number, if room move||String|
|LN||Language of the Guest (ISO-Code 639-1, 2 characters)||String|
|SALUTATION||Salutation of the Guest||String|
|TITLE||Title of the Guest||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…
|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?.
|SRC||The SRC-Attribute indicates where this operation is coming from.||String|
|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
|AP||Definition of the access points. The access point are defined in a key card system||String|
|NC||Number of cards||uns. Byte|
|PPU||Price per unit (including taxes, vat, …) in hotel currency||BCD|
|AMOUNT||Total amount = PPU * UN||BCD|
|HN||Number of the hotel – each hotel has a
|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|
|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
|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.
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
<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
|PCO||Pre Check Out||SIHOT||Interface|
|COS||Class of Service||SIHOT||Interface|
|WU||Wake Up Message||SIHOT||Interface|
|WU||Wake Up Message||Interface||SIHOT|
|WA||Wake Up Answer||Interface||SIHOT|
|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|
|DMS-DOC-STORED||DMS stored document successfully||SIHOT||Interface|
|DMS-NEW-DOC||DMS scanned new document||SIHOT||Interface|
Error Handling (ACK)
All exchanged operations (OC) return a feedback to the sender. See Acknowledge.
There are no messages to send a “start of night audit” and “end of night audit”, because SIHOT can process posting also during the night audit.