Interfaces

=1 Change Log=

=2 Zweck der Dokumentation= Ziel der Interface-Dokumentation ist es, Entwicklern im Bereich der Hotel-Software ein Standard an die Hand zugeben, welcher es Ihnen erlaubt die Kommunikation zwischen SIHOT.PMS und ihrem System aufzubauen.

Änderungen, die sich aus der technischen Entwicklung ergeben sind vorbehalten und bedürfen nicht der vorherigen Ankündigung.

GUBSE übernimmt keine Garantie für die Richtigkeit und Voll­ständigkeit diese Dokumentation. Zudem kann GUBSE nicht für Schäden haftbar gemacht werden, welche aufgrund dieser Dokumentation entstehen.

Für Fragen bezüglich der Interfaces wenden Sie sich bitte an folgende Adressen:

GUBSE AG

Bahnhofstr. 28

D-66578 Schiffweiler

Fon: +49 6821 9646 0

Fax: +49 6821 9646 110

Email:info.de@gubse.com

=3 Änderungshistory=

=4 Anbindung Com4Tel= Über das bei Com4Tel mitgelieferte Konfigurationsprogramm sind folgende Parameter einzustellen:
 * Communication to „User defined“
 * Type „DDE Poke“
 * User defined Application „...“
 * User defined Topic „...“
 * User defined Item „...“

Achtung: bitte konfigurieren Sie auch die entsprechenden Einträge in der SIHOT-Registry im Abschnitt Anrufidentifizierung über DDE.

Bei der Konfiguration von Com4Tel muss unter \Telefonie\Formulare: Formular öffnen bei Anruf angegeben sein.

Achtung: Com4Tel legt diese Informationen in der Windowsregistry benutzer­abhängig ab.

=5 Anbindung Kartenleser für Fidelity-Cards=

5.1 Aufbau der Kartendaten
Alle Felder sind durch ein „;“ voneinander getrennt.

Name

Vorname

Straße

Land

Nation

PLZ

Stadt

Preiscode (char 3)

Marktsegment (char 3)

VIP 1 (char 3)

VIP 2 (char 3)

Matchcode

Matchcode Mutterfirma

Karten-Nummer

Gültigkeit der Karte von-Datum (Format: YYYYMMDD)

Gültigkeit der Karte bis-Datum (Format: YYYYMMDD)

Anrede Kürzel (char 1)

Titel Kürzel (char 1)

Geburtsdatum (Format: YYYYMMDD)

5.2.1 Allgemein
Die Tastatur mit Kartenleser muss die Tracks 1, 2 und 3 lesen können. Zudem muss diese Tastatur die Daten über den Keyboardbuffer an Windows senden. Vor den eigentlichen Rohdaten muss die Tastatur eine Startsequenz (Header) und eine Endesequenz (Terminator) senden. Diese Sequenzen müssen mittels Konfigurationsprogramm eingetragen werden, damit diese von der Tastatur gesendet werden, wenn eine Karte durch den Leser gezogen wird.

5.2.2 Angebundene Tastaturen
Derzeit wurde diese Schnittstelle mit der Cherry G81-800LPADE und Jarltech KB 2000-33W Keyboardwetch getestet.

=6 SIHOT.PMS zu Gastrofix=

6.1 Beschreibung der Anwendungsschicht
Die Kommunikation der Kasse und SIHOT geschieht durch den Austausch von Nachrichtendateien.

Ein Dateiname hat immer eine dreistellige Namenserweiterung, die den Typ der Nachrichtendatei spezifiziert; folgende Typen sind definiert:

Bei der Kommunikation werden die Dateinamen beibehalten und die Erweiterungen ausgetauscht; bei einer Verbuchungsanfrage würde das z.B. so aussehen:

Kasse schickt an SIHOT eine Anfragedatei:

00020314.ANF

SIHOT verarbeitet die Anfragedatei und schickt eine Antwortdatei gleichen Namens aber mit der Erweiterung ANT zurück, die Anfragedatei wird dabei von SIHOT gelöscht:

00020314.ANT

Alle Nachrichtendateien bestehen aus Feldern (Schlüsselwörtern und Daten) die jeweils durch ein Semikolon oder eine 'eckige Klammer' ([]) getrennt werden. Steuerzeichen (ASCII-Code < 32) werden ignoriert (=überlesen), ebenso Spaces am Feldanfang. Der Backslash (\) dient als ESCAPE-Zeichen und entwertet die Sonderbedeutung des nachfolgenden Zeichens.

Anmerkung:

Obwohl die Nachrichtendateien im Grunde strukturlos sind (reine Zeichenströme), hat sich doch eine Strukturierung durch Aufteilung in Zeilen (beendet durch NL oder CR+NL) als sinnvoll erwiesen (à bessere Lesbarkeit für den Programmierer).

Folgende Datentypen werden verwendet:

6.2 Anfrage- und Verbuchungsanforderung Kasse  SIHOT
Der Dateiname hat die Endung ANF, der Dateikopf hat folgendes Format:

{ANF|VBR|WARANF|WARVBR};{ZIMM|KARTE};(1-16)

Eine Anfrage von der Kasse wird durch das Schlüsselwort ANF, eine Verbuchungsanforderung durch das Schlüsselwort VBR eingeleitet. Ist ein Warenautomat angeschlossen, wird das Kürzel WAR vorangestellt. Der Unterschied hierbei ist, dass eine WARVBR definitiv ausgeführt wird, auch wenn das Limit des Kontos dies nicht zulassen sollte.

Die Nummer im dritten Feld bezeichnet entweder eine Zimmernummer (2. Feld = ZIMM) oder eine 'Kartennummer' (2. Feld = KART), z.B. bei Verwendung von Türschiessanlagen. Ist ein Warenautomat angeschlossen, so ist in diesem Fall immer nur KART möglich.

Danach folgen die eigentlichen Buchungsdaten geklammert in [].Folgende Buchungsarten sind erlaubt:
 * Betragsverbuchung
 * Warengruppenverbuchung
 * Leistungsanfrage

6.2.1 Betragsverbuchung ohne Warengruppe
[BETRAG;(0-5);

(0-10.0-2);

(0-10.0-2);

(0-10.0-2);

(0-10.0-2)]

Diese Buchungsart ist z.Zt. nicht implementiert.

6.2.2 Betragsverbuchung mit Warengruppe
[WARENGRUPPE;(0-5);

(0-3);

(0-8);

(0-10.0-2);(0-10.0-2);

(0-3.0-2)]

Dieser Satztyp kann auch mehrmals hintereinander vorkommen (verschiedene Warengruppen in einem Vorgang). Dabei sind folgende Grenzen zu beachten:


 * Maximalanzahl an Sätzen in einem Vorgang: 1000.
 * Kassennummer: 1-10
 * Warengruppennummer: 1-500
 * Bei Warengruppen gilt:
 * Bereich 1-250: In House, 15% MwSt.
 * Bereich 250-500: Außer Haus, 7% MwSt. (wird als WG 1-250) gebucht.

6.2.3 Leistungsanfrage
[LEISTUNG;(0-5);(1-3)]

Es erfolgt eine Anfrage von der Kasse, ob die angegebene Leistung für die aktuelle Uhrzeit definiert ist. Die Leistung kann auch Element in der Stückliste sein.

6.3 Anfrage- und Verbuchungsantwort SIHOT  Kasse
Der Dateiname hat die Endung ANT, der Dateikopf hat folgendes Format:

(1-4);(3-6);<Gastname>(0-40);<Leistungsname>(0-40)

Alternativ hierzu kann folgende Struktur eingestellt werden:

<Vorgangsstatus>(1-4);<Zimmernummer>(3-6);<Gastname>(0-40);<Leistungsname>(0-40);<Gastsaldo>(0-10)

Ein Vorgangsstatus von 0 bedeutet Erfolg, alle anderen Werte sind Fehlercodes. Im Fehlerfall kann der Gastname leer sein, der Leistungsname enthält dann eine Klartextfehlermeldung.

Im alternativen Satz kann der Saldo des Gastkonto (in Pfennigen) mit übermittelt werden. Diese Einstellung ist beim Prozess konfigurierbar.

6.4 Anforderungsdatei für einen Kassenabschlag SIHOT  Kasse
Der Dateiname beim Kassenabschlag hat die Endung ANO, der Dateikopf hat folgendes Format:

{INF|NUL};<Kassennummer>(1-5);<Kellnernummer>(1-5)

Ist das erste Feld NUL, so erfolgt nach dem Kassenabschlag eine Nullstellung der Kasse.

ACHTUNG! z.Zt. erfolgt ein Abschlag immer mit INF, NUL wird nicht verwendet.

Angefordert wird ein Kassenabschlag der Kasse <Kassennummer> und des Kellners <Kellnernummer>. Ist die <Kassennummer> gleich 0, so wird ein Abschlag aller Kassen gewünscht. Ist die <Kellnernummer> gleich 0, so wird ein Abschlag aller Kellner gewünscht.

6.5 Kassenabschlags-Ergebnisdatei SIHOT  Kasse
Der Dateiname des Ergebnisses hat die Endung ANI, der Dateikopf hat folgendes Format:

STATUS;<Vorgansstatus>(1-4);<Fehlermeldung>

ACHTUNG! Die Daten, die bereits per Hotelkredit gebucht wurden dürfen nicht mehr berücksichtigt werden!

Vorgangsstatus: siehe oben.

[WARENGRUPPE;<Kassennummer>(0-5);

<Warengruppennummer>(0-3);

<Anzahl Artikel>(0-8);

<Netto Betrag>(0-10.0-2);<Brutto Betrag>(0-10.0-2);

<MwSt-Satz>(0-3.0-2)]

Die Erklärung hierzu wurde in einem vorherigen Kapitel gegeben.

[ABART;

<Kassennummer>(0-5);<Abrechnungsartnummer>(0-3);

<Anzahl Abrechnungen>(0-8);<Betrag>(0-10.0-2)]

Der Finanzweg gibt an, wie bezahlt wurde:
 * Maximalanzahl an Sätzen in einem Vorgang: 1000
 * Kassennummer: 1-10
 * Warengruppennummer: 1-500
 * Abrechnungsart: 0-999

6.6.1 Anfrage von Kasse auf Leistungsname
Die Beispiele beziehen sich auf Zimmer 212 und Unterkonto 0.

Anfrage von Kasse: (Dateiname z.B. 00020012.ANF)

ANF;ZIMM;21200

[LEISTUNG;2;AR1]

Antwort von SIHOT (Dateiname 00020012.ANT)

[0;21200;Meier, Alfons;Arrangement 1]

6.6.2 Anfrage von Kasse auf Leistungsname (Fehlerhaftes Zimmer)
Anfrage von Kasse (Dateiname z.B. 00020013.ANF)

ANF;ZIMM;31300

[LEISTUNG;2;AR3]

Antwort von SIHOT (Dateiname 00020013.ANT)

[20;;++ Zimmer nicht belegt ++]

6.6.3 Verbuchung von Kasse auf Zimmer, Warengruppengenau;
Anfrage von Kasse (Dateiname z.B. 00020014.ANF)

VBR;ZIMM;21200

[WARENGRUPPE;2;14;5;

12.87;14.8;15.0]

[WARENGRUPPE;2;17;1;

24.35;28;15.0]

[WARENGRUPPE;2;18;2;

14.58;15.60;7.0]

Antwort von SIHOT (Dateiname 00020014.ANT)

[0;21200;Meier, Alfons;]

6.7 Übernahme des Tagesabschlusses in SIHOT
Anfrage von SIHOT zur Kasse, Dateiname SIHOT.ANO:

INF;0;0

Antwort von Kasse, Dateiname SIHOT.ANI:

STATUS;0;Abschluss vom .....

[WARENGRUPPE;2;14;5;

12.87;14.8;15.0]

[WARENGRUPPE;2;17;1;

24.35;28;15.0]

[WARENGRUPPE;2;18;2;

14.58;15.60;7.0]

[ABART;2;1;2;42.8]

[ABART;2;2;1;15.60]

6.7.1 Anfrage eines Warenautomaten über Kartennummer
Anfrage von Kasse (Dateiname z.B. 00020015.ANF)

WARANF;KARTE;471109

[WARENGRUPPE;1;1;2;0.01;0.01;16.0]

Antwort an die Kassen (Dateiname ist 00020015.ANT)

[0;21200;Meier, Alfons;]

6.7.2 Verbuchung des Warenautomaten auf der Karte;
Anfrage von Kasse (Dateiname z.B. 00020016.ANF)

WARVBR;KARTE;471109

[WARENGRUPPE;2;14;5;

12.87;14.8;15.0]

Diese Buchung wird definitiv ausgeführt!

6.7.3 Antwort in alternativer Struktur
Anfrage von Kasse (Dateiname z.B. 00020017.ANF)

ANF;ZIM;21200

[WARENGRUPPE;1;1;2;0.01;0.01;16.0]

Antwort an die Kassen (Dateiname ist 00020017.ANT)

Der Gast hat einen Saldo von € 367,00 auf seinem Konto.

[0;21200;Meier, Alfons;36700]

=7 SIHOT.PMS zu RMS-Systemen= Siehe separate Beschreibung: SIHOT.PMS – RMS Interface Specification.

=8 SIHOT.PMS zu Therapie-Systemen=

8.1 Variante I: XML-Interface
Siehe separate Beschreibung: SIHOT.PMS – XML Interface Specification.

8.2.1 Das Therapie-System
SIHOT sendet die Gastinformation mit Name, Adresse, Zimmer-Nr. u.s.w. bei Check-In oder Umzug an das Therapie-System. Wenn im Therapie-System Leistungen für den Gast anfallen, können diese sofort – ähnlich wie Kassenbuchungen oder GDV – an SIHOT übermittelt werden. Damit hat SIHOT die aktuellen Buchungen und einen genauen Tagesumsatz aus dem Therapiebereich.

Im Buchungssatz sendet das Therapie-System eine 3-stellige Leistungsnummer. Diese muss in SIHOT als Leistung angelegt sein.

8.2.2 Datensatz-Arten
Folgende Typen von Datensätzen werden verarbeitet:

8.2.2.1 Check-In
Sobald ein Gast in SIHOT eingecheckt wird, wird dies auch durch den folgenden Check-In-Satz dem Therapie-System bekannt gemacht.

8.2.2.2 Check-Out
Wenn ein Gast aus SIHOT ausgecheckt wird, wird das Therapie-System mit folgendem Check-Out-Satz darüber informiert.

8.2.2.3 Buchung
Wird ein Buchungssatz von SIHOT empfangen wird dieser wie jede andere Leistung oder Gebühr aufs Gastkonto verbucht.

8.2.2.4 Restart-Anforderung
Als Antwort auf die Restart-Anforderung werden alle Check-In und Check-Out Sätze nochmals an das Therapie-System gesendet.

8.2.3 Datenübertrag
Für die Übertragung der Daten wird das Protokoll IBM HIS Verwendet, welches auch in diesem Dokument erläutert ist.

8.2.4 Beispiele
Im Folgenden werden Beispiele für die Datenkommunikation angegeben.

8.2.4.1 Check-In
Check-In-Satz für:

Vorname / Name : Markus Mustermann

Strasse : Hohe Strasse 12

PLZ / Ort : 33444 Auerhausen

Tel : 067732/436621

Gast Nr. : 53467547

Res. Nr. : 87896746

Zimmer Nr. : 110

Aufenthalt vom : 10.05.2002

Aufenthalt bis : 18.05.2002

Gültig ab : 10.05.2002, 12:00 Uhr

1253467547Mustermann.......Markus...........Hohe.Strasse.12....................33444.Auerhausen...................067732/436621......................011020020510200205182002051012:004556745387896746

8.2.4.2 Check-Out
Check-Out-Satz für den Gast mit der Gastnummer 53467547

2053467547

8.2.4.3 Buchung
Über den Buchungs-Satz werden zwei Kurpackungen für je 30 Euro auf das Konto des Gastes mit der Gastnummer 53467547 im Zimmer 110 transferiert.

2353467547222Kurpackung...................2+.....3000+.......60000110

=9 SIHOT.PMS zu Energie Managementsystem=

9.1.1 Funktionsbeschreibung Schnittstelle
Die Schnittstelle zum Energie Managementsystem (EMS) erfüllt folgende Mindest­anforderungen:
 * Aufbau der Kommunikation mit dem EMS beim Neustart des Systems.
 * Wiederaufbau der Kommunikation mit dem EMS bei System- bzw. Kommunikationsausfällen.
 * Austauschen von Nutz- Datagrammen mit dem EMS. Dabei ist zu unterscheiden zwischen unaufgefordert zu sendenden Datagrammen (Ein Ereignis in EMS ist aufgetreten.) und angeforderten Datagrammen (z.B. Keep alive).
 * Weiterreichen von Informationen an das EMS.
 * Jeder Partner (EMS, SIHOT.PMS) muss dafür sorgen, dass die Nachrichten welche an ihn selbst geschickt wurden, gelöscht werden.
 * Ein Prozessabbild der jeweils in der anderen Software enthaltenen Informationen wird nicht erzeugt.

9.1.1.1 Informationen SIHOT.PMS  EMS
Die folgenden Ereignisse führen zur Kommunikation zwischen Systemen:

9.1.1.2 Informationen EMS  SIHOT.PMS
Antworten auf Check-In, Check-Out, Kartenerstellung, Rückgabe der Liste mit den Zimmern im zukünftigen Raumstatus usw..

9.1.2 Anforderung an EMS

 * Die Antworten auf Ereignisse (Prozessreaktion), wie z.B. Check-In müssen in chronologischer Reihenfolge aus der Ereignistabelle lesbar sein. Dies ist möglich durch Sortierung nach dem Timestamp.
 * Ereignisse, die EMS-seitig intern ausgelöst werden, (z.B. Check-In, Check-Out, etc.) dürfen nicht zu Antworttelegrammen ans SIHOT.PMS führen.
 * Eine Plausibilitätsprüfung für ‘alte’ Ereignisse muß im EMS eingangsseitig stattfinden (z.B. Check-In Datagramme vom Vortag, etc.).
 * Für Check-In, Check-Out, Make-Card sowie Nachrichten­übertragung müssen im EMS geeignete Schnittstellen zur Ver­fügung stehen. Dies gilt auch für alle weiteren, hier nicht namentlich genannten Funktionen.
 * Karten können vor dem Eintreffen des Gastes erstellt werden.

9.1.2.1 Kommunikation
Als Kommunikationsprotokoll wird IP verwendet.

Um Übertragungsprobleme auf Netzwerkebene nicht handeln zu müssen, werden ausschließlich TCP-Datagramme definiert und gesendet.

Als Socket für die bidirektionale Kommunikation wird 5100 festgelegt, sollte jedoch konfigurierbar sein.

Jedes EMS hat genau einen Partner (Fremdsystem). Dadurch entsteht eine logische Punkt zu Punkt Verbindung.

Es wird festgelegt, daß das EMS der Socket-Server ist und das SIHOT.PMS der Socket-Client.

Dieser Abschnitt beschreibt die im Schnittstellenmodul zu realisierende Funktionalität im Detail. Ablaufdiagramme ver­deutlichen die Abläufe.

9.1.2.1.1 Start des Schnittstellenmodul
Das Starten des Kopplers führt zu einer Reihe von Initialisierungen. Die Verbindungen mit dem SIHOT.PMS-System müssen aufgebaut werden.

9.1.2.1.2 Aufbau der Verbindung im EMS
EMS spezifische Arbeitsweise

Definition: Alle Telegramme, die nach dem Hochstarten des Schnittstellenmoduls in der System-Messages Tabelle stehen sind als aktuell zu betrachten.

9.1.2.1.3 Aufbau der Verbindung zu SIHOT.PMS
Die Schnittstelle stellt als Socket-Server den Socket zur Verfügung und wartet solange bis vom SIHOT.PMS ein TYSTART geschickt wurde und schickt ein TYSTART zurück.

9.1.2.2 Life-Check
Um eine kontinuierliche Verbindungsüberwachung auf Applikationsebene zu erreichen, werden zwei Alterungszeitgeber verwendet.

9.1.2.2.1 Zeitüberschreitung beim Senden
Der Sende-Timer wird von der Applikation beim Senden jedes Datagramms zurückgesetzt. Überschreitet er einen festgelegten Wert (z.B. 60 Sekunden), wird ein Datagramm vom TYP TYLIFE an den Kommunikationspartner gesendet und er Timer ebenfalls zurückgesetzt.

9.1.2.2.2 Zeitüberschreitung beim Empfang
Der Empfang-Timer wird von der Applikation beim Empfang jedes Datagramms zurückgesetzt. Überschreitet er einen festgelegten Wert (z.B. 150 Sekunden), so wird angenommen, daß der Kommunikationspartner nicht mehr auf Applikationsebene verfügbar ist. Dadurch werden Offline Prozeduren ausgelöst.

9.1.2.3 Check-In und Make-Card
Es gibt zwei Vorgehensweisen einen Gast im EMS einzuchecken und Karten zu erzeugen.

9.1.2.3.1 Check-In mit vorerstellter Karte
Es werden dabei folgende Schritte durchlaufen:
 * Gast meldet sich an und auf dem SIHOT.PMS wird vorgebucht.
 * Für den Gast wird eine Karte vorerstellt. Es werden noch keine Raumcontrollerfunktionalitäten aktiviert. (TYCARD mit CC = 0)
 * Es können Copy Cards erstellt werden (TYCARD mit CC >0)
 * Erst bei der Ankunft des Gastes wird der Gast über das SIHOT.PMS vollständig eingecheckt und so werden die Raumcontrollerfunktionalitäten aktiv. (TYCHIN mit EN > 0)
 * Es wird die Komfort Temperatur eingestellt ( TYHEAT mit HAT = 0) (nur für Zwischenlösung Energiemanagement).

9.1.2.3.2 Check-In ohne vorerstellte Karte
Es werden dabei folgende Schritte durchlaufen:
 * Gast wird auf dem SIHOT.PMS eingecheckt und eine Magnetkarte wird erstellt (TYCHIN mit EN = 0)
 * Es können Copy Cards erstellt werden (TYCARD mit CC > 0)
 * Es können Room-Sharer eingecheckt werden
 * Raumcontrollerfunktionaltitäten werden aktiviert
 * Es wird die Komfort Temperatur eingestellt (TYHEAT mit HAT = 0) (nur für Zwischenlösung Energiemanagement).
 * Der Check-In Vorgang wird durch ein Antwortdatagramm an das SIHOT.PMS quittiert, das u.a. die Emissionsnummer und den Status des Befehlsabschlusses enthält. Es können auch mehrere Personen eingecheckt werden, von denen mindestens eine ihren Namen angeben muß.

Wichtiger Hinweis:

Wurde beim Check-In Vorgang ein Fahler zurückgeschickt (TYERR), so kann mit Hilfe des Datagramms TYINFO angefragt werden, ob der Gast richtig eingecheckt worden ist und nur der Kartenprogrammiervorgang erfolglos war. Das Datagramm TYINFOR liefert EN< >0 zurück, wenn der Check-In Vorgang erfolgreich war. Dann kann der Kartenprogrammiervorgang nochmals wiederholt werden.

Wenn EN=0 ist der Check-In Vorgang mißglückt, es muß der Check-In Vorgang wiederholt werden.

9.1.2.3.3 Empfang Check-In bzw. Make-Card Datagramm
Beim Empfang des Check-In Datagramms (TYCHIN) wird der Check-In Vorgang (Post_Check_In oder Full_Check_In) ausgelöst. Die Daten aus dem SIHOT.PMS werden entsprechend übergeben.

Beim Empfang des Make-Card Datagramms (TYCARD) wird der Karten­programmiervorgang (Create_Key_Card) im EMS ausgelöst. Die Daten aus dem SIHOT.PMS werden entsprechend übergeben.

9.1.2.3.4 Bestätigung Check-In bzw. Make-Card Datagramm
Die Bestätigung des Check-In's bzw. des Make-Card wird durch das EMS veranlaßt. Sobald das Schnittstellenmodul angestoßen wird, werden die benötigten Daten zusammengestellt und das Datagramm TYCHINR versendet.

Konnten die Daten nicht korrekt in die Datenbank geschrieben werden, wird eine Fehlermeldung (TYERR) an das SIHOT.PMS geschickt.

9.1.2.3.5 Checkout
Der Check-Out löscht alle der jeweiligen Magnetkarte zugeordneten Gestattungen (Zimmerzutritt, etc.) und setzt ggf. die Raumcontrollerfunktion zurück.

Man unterscheidet:
 * Check-Out eines Gastes über die Gastnummer
 * Check-Out aller Gäste eines Raumes (Gastnummer wird nicht mitgeliefert oder ist 0)

9.1.2.3.6 Empfang Check-Out Datagramm
Beim Empfang des Check-Out Datagramms (TYCHOUT) wird der Check-Out Vorgang im EMS ausgelöst. Die Daten aus dem SIHOT.PMS werden entsprechend übergeben.

9.1.2.3.7 Bestätigung Check-Out Datagramm
Die Bestätigung des Check-Out wird durch das EMS veranlaßt. Sobald das Schnittstellenmodul angestoßen wird, werden die benötigten Daten zusammengestellt und mittels Datagramm TYCHOUTR versendet.

Konnten die Daten nicht korrekt aus der Datenbank entfernt werden, wird eine Fehlermeldung (TYERR) an das SIHOT.PMS geschickt.

9.1.2.3.8 Info
Dieses Datagramm wurde in definiert aus der Notwendigkeit heraus, daß das SIHOT.PMS nachprüfen kann, ob ein bestimmter Gast erfolgreich eingecheckt wurde oder nicht.

9.1.2.3.9 Empfang Info Datagramm
Beim Empfang des Info Datagramms (TYINFO) wird der Get_Key_code Vorgang in EMS ausgelöst, d.h. um eine Copy Card zu erzeugen ist es notwendig zu erfahren ob schon ein Zutrittscode für den ersten Gast aus dem Zimmer erzeugt wurde. Die Daten aus dem SIHOT.PMS werden entsprechend übergeben.

9.1.2.3.10 Bestätigung Info Datagramm
Die Bestätigung des Info Datagramms wird durch EMS veranlaßt. Sobald das Schnittstellenmodul von EMS aus angestoßen wird, wird der Zutrittscode (falls er bei einem Check-In erstellt wurde) aus der Datenbank gelesen und das Datagramm TYINFOR zusammengestellt. Ansonsten wird, wenn der Zutrittscode noch nicht erstellt wurde, anstelle des Zutrittscodes eine „0“ zurückgesendet.

9.1.2.3.11 Reservierte Zimmer / Energiemanagement
Dieses Datagramm dient zum Heizen/Kühlen der Räume. Das vollautomatische Heizen/Kühlen sieht folgendermaßen aus:

Um eine bestimmte Uhrzeit schickt das SIHOT.PMS eine Liste mit den reservierten/belegten Zimmern als Datagramm. Das Starten dieser Liste wird durch das Datagramm TYSTARTRES angekündigt. Es folgen Datagramme welche folgendes aussagen:

Belegt Zimmer: Status0, Liste von den belegten Zimmer

reservierte Zimmer für den heutigen Tag: Status 1, Raumtyp, Anzahl der reservierten Zimmer dieses Raumtyps, Liste mit den fest reservierten Zimmern dieses Raumtyps

reservierte Zimmer für den nächsten Tag: Status 2, Raumtyp, Anzahl der reservierten Zimmer dieses Raumtyps, Liste mit den fest reservierten Zimmern dieses Raumtyps

9.1.2.4 Belegte Zimmer
Das Datagramm sieht

TYRESRN\tRN101\tRN102\tRN302\t@@@

ST = 0 bedeutet das Zimmer ist belegt. Es folgt eine Liste der belegten Zimmer.

9.1.2.5 Reservierte Zimmer für den heutigen Tag bzw. nächsten Tag
Beispiele:

TYRESRN\tST1\tRT1\tNR6\tRN101\tRN102\tRN103\t@@@

TYRESRN\tST1\tRT2\t\NR10\tRN201\tRN202\tRN203\t@@@

TYRESRN\tST1\tRT3\tMR4\tRN301\tRN302\t@@@

...usw.

bzw.

TYRESRN\tST2\tRT1\tNR6\trn104\tRN105\t@@@

TYRESRN\tST2\tRT2\t\NR8\tRN210\tRN220\tRN230\t@@@

TYRESRN\tST2\tRT2\tNR4\tRN321\tRN322\t@@@

...usw.

Status

ST = 1 das Zimmer ist für heute reserviert

ST = 2 das Zimmer ist für morgen reserviert

Raumtyp

Beispiele:

RT= 1 die Zimmer sind Standardzimmer

RT = 2 die Zimmer sind Komfortzimmer

RT = 3 die Zimmer sind Suiten

...usw.

Wichtig:

Es können beliebig viele Raumtypen definiert sein im Hotel. Wichtig ist nur, daß die

Zimmernummern und -typen bei beiden Systemen die gleichen sind.

Anzahl Zimmer

NR = Anzahl der reservierten Zimmer eines Typs

Zimmerliste

Es folgt eine Liste der reservierten Zimmer.

Liste der Räume nach Temperaturstatus geordnet

Sind alle Daten vom SIHOT.PMS übertragen, wird das Datagramm TYENDRES vom SIHOT.PMS geschickt.

Das EMS berechnet den zukünftigen Temperaturstatus der im Moment belegten Zimmer nach dem Check-Out, sowie den Temperaturstatus für die leeren Räume.

Wenn die Berechnung beendet ist, wird vom EMS ans SIHOT.PMS TYSTARTENERGY geschickt. Danach folgen Datagramme die folgendermaßen aussehen:

TYSTATI\tHT1\tRN201\tRN402\tRN203...\t@@@

TYSTATI\tHT2\tRN301\tRN302\tRN403...\t@@@

TYSTATI\tHT3\tRN401\tRN202\tRN303...\t@@@

Standby A ist der höchste Temperaturstatus eines leeren Raumes, während Standby C den kleinsten Temperaturstatus darstellt. Die Integer Werte werden im Datagramm stellvertretend für die Temperaturkategorien übergeben.

Wurden alle Daten übertragen, folgt ein TYENDENERGY Datagramm.

Wichtig:

Die Liste aller Räume mit deren Energiestatus welche ans SIHOT.PMS geschickt wird, dient dazu um anhand des Temperaturstatus die leeren Zimmer vermieten zu können. Diese Liste entspricht nicht mit der Liste der Räume mit dem aktuellen Temperaturstatus (siehe EMS MMI). Die Zimmer werden beim Check-In automatisch auf den Temperaturstatus Komfort gesetzt.

9.1.2.6 Datenbank Swap
Ein Datenbank Swap wird benötigt, wenn die Datenbanken der beiden Systeme, SIHOT.PMS und EMS, in Bezug auf die Gäste nicht mehr übereinstimmen. Dies wird hervorgerufen durch zeitweilige Unterbrechung einer der Kopplungen oder System. Das SIHOT.PMS ist der Master beim Datenbank Swap. Der Datenbank Swap soll nur bei Bedarf angewendet werden und vom SIHOT.PMS auszulösen sein.

Beispiel:

TYSTARTSWAP\tTS03111997101500\t@@@

TYCHOUT\tRN101\t...SF1\t@@@

TYCHOUT\tRN102\t...SF1\t@@@

TYCHIN\tRN103\tGN12345\t...SF1\t@@@

TYCHOUT\tRN104\t...SF1\t@@@

TYCHIN\tRN105\tGN12005\t...SF1\t@@@

....

TYENDSWAP\tTS03111997103022\t@@@

Beim Datenbank Swap wird die Raumliste vom SIHOT.PMS vom Anfang bis zum Ende durchlaufen. Wenn ein Zimmer leer ist wird ein Check-Out Datagramm geschickt, welches keine Gastnummer beinhaltet. Ist ein Zimmer von einem Gast belegt, wird ein Check-In Datagramm TYCHIN mit den Daten des Gastes geschickt. Die Check-In und Check-Out Datagramme enthalten ebenfalls das Token SF mit dem Wert 1 als Kennung dafür, daß ein Datenbank Swap stattfindet.

Das Datagramm TYSTARTSWAP markiert den Anfang des Datenbank Swaps, wobei das Ende vom Datagramm TYENDSWAP angezeigt wird.

Auf die TYCHIN und TYCHOUT Datagramme werden wie gewöhnlich auch Antworten geschickt. Der Datenbank Swap soll jedoch nicht den normalen Betrieb des Ein- und Auscheckens behindern. Er soll im Hintergrund ablaufen.

9.1.2.7 Zimmerwechsel
Der Zimmerwechsel wird seitens SIHOT.PMS gehandhabt wie ein Check-Out mit anschließendem Check-In. Dies läuft nicht konträr zu den gegebenen Möglichkeiten. Damit werden lediglich die entsprechenden TYCHIN und TYCHOUT bzw.: evtl.: TYCARD Datagramme von EMS empfangen und ausgewertet. Der Zimmerwechsel ist damit transparent.

Offline-Prozeduren

Versuch Kommunikation wiederaufzubauen.

Ereignisse aus dem EMS werden erst wieder verarbeitet, wenn die Verbindung zwischen den Systemen wieder online ist.

9.1.2.8 Fehlerzustände
Für die Meldung von allgemeinen und systeminterne Fehlerzuständewurde das TYERR Datagramm vorgesehen. Der Empfang eines TYERR Datagramms führt nicht generell zu einer Unterbrechung der Kommunikation.

Die einfachen Fehlermeldungen (Status ST = 0) werden vom Kommunikationspartner entgegengenommen und er reagiert auf entsprechende Weise, bricht jedoch die Kommunikation nicht ab.

Die sehr gravierenden Fehlermeldungen (systeminterne Fehlerzustände: Status ST = 1 oder ST = 2) führen zu einer Unterbrechung der Kommunikation. (z.B. „EMS down“).

Eine erneute Verbindung wird durch den Kommunikationsneuaufbau via TYSTART und TASTARTR wie bei einem Neustart der Kommunikation aufgebaut. Zwischenzeitlich werden die Offline-Prozeduren gefahren.

Kommunikationsablaufdiagramm am Beispiel einer Störung im Koppler:

Der gestörte Partner schickt ein TYERR. Danach verhält sich der andere Partner ruhig, bis ein TYSTART anzeigt, daß die Kommunikation wieder aufgebaut werden soll. Ein TYSTARTR zeigt an, daß der Partner damit einverstanden ist.

In der Tabelle 33-11 sind alle Fehlermeldungen, die vom Koppler zu SIHOT.PMS geschickt werden können, mit Status, Fehlernummer und Fehlertext aufgelistet.

Das SIHOT.PMS Interface sollte TYERR mit Status 1 und Fehlernummer 0 für den Fall „SIHOT.PMS down !!“ implementieren. Ansonsten kann das SIHOT.PMS Interface alle Fehlernummern ab ER > 200 für Mitteilungen an den EMS Koppler benutzen.

Tabelle 3-1: Fehler die vom EMS an das SIHOT.PMS geschickt werden können

9.1.3 Datagrammaufbau
Der Datagrammaufbau folgt folgender Syntax: Das Ende eines Datagramms wird durch 3 Klammeraffen „@@@“ gekennzeichnet.

Die Paketgröße gibt die Länge des darauf folgenden Datagramms (eine ASCII-Zeichenfolge) inklusive der 3 Klammeraffen in Byte an. Datentyp: UINT.

Die Länge der Felder sind variabel und passen sich den Notwendigkeiten an. Eine Tabelle mit den Definitionen der Pakettypen und Token finden Sie im nächsten Abschnitt. Als Trennzeichen innerhalb des Datagramms wird das Tabulatorzeichen verwendet. Dies taucht weder in den Regeldatagrammen auf, noch wird es zur Anzeige von Nachrichten seitens des SIHOT.PMS benutzt.

9.1.4 Definition der Datagramme
Die hier beschriebene Definition kennzeichnet den Stand der Implementation des Interface für SIHOT.PMS und EMS. Es ist statthaft, diese Datagrammdefinition zu erweitern. Allerdings wird, um Inkompabilitäten zu vermeiden, eine gegenseitige Benachrichtigung vereinbart.

Die Zeile „Wirkung“ in untenstehender Tabelle gibt die Richtung an, in die das Datagramm versendet wird.

9.1.5 Arrangement- Code
Der Arrangementcode bewirkt in EMS die Auslösung bestimmter Funktionen. Im SIHOT.PMS wird darunter verstanden, bestimmte Bereiche für einen Gast freizugeben oder auch nicht. Beispielsweise könnte die Minibar gesperrt sein.

Die Tabelle der Arrangement-Codes ist eine zweistellige UINT Tabelle mit Werten von 01 bis 99.

Die Tabelle der Arrangementcodes wird von uns vorgegeben.

9.2 Variante II: Einfache Version über Seriell
SIHOT sendet für jeden Check-In und Check-Out eine Message ans EMS-System. Anfrage oder Nachrichten vom EMS-System gibt es nicht. Bei Zimmerumzügen wird ein Check-Out für das zur Zeit belegte Zimmer und ein Check-In für das neue Zimmer gesendet.

Als physikalisches Übertragungsprotokoll wird IBM HIS verwendet, Kapitel 17ab Seite 74.

9.2.1.1 Check-In
Jeder Check-In in SIHOT produziert eine Message ans EMS-System.

9.2.1.2 Check-Out
Nach jedem Check-Out in SIHOT wird eine entsprechende Nachricht ans EMS-System geschickt

9.2.1.3 Restart
Für einen Datenabgleich zwischen SIHOT und dem EMS gibt es keine Anforderung. Um einen abgeglichenen Stand beider Systeme zu gewährleisten, gibt es den Parameter –RESTART im EMS Protokoll. Ist dieser gesetzt wird nach jedem Neustart des Protokolls, automatisch ein Restart durchgeführt. Das bedeutet: Für jedes Zimmer wird je nach Status ein Check-In oder Check-Out Satz von SIHOT ans EMS-System gesendet.

9.2.2 Datenübertragung
Die Daten werden wie in den Beispielen gezeigt an die Schnittstelle gesendet. Die Checksumme berechnet sich durch die Addition der 4 Stellen der Zimmernummer. Die letzte Stelle des Ergebnisses wird als Checksumme mitgesendet. Als Antwort wird ein ACK oder ein NAK erwartet, wie im IBM HIS- Protokoll erläutert.

9.2.3 Beispiele
Im folgenden werden je ein Beispiel für einen Check-In und einen Check-Out Satz gezeigt.

9.2.3.1 Check-In
Check-In für Zimmer 110

E01102

9.2.3.2 Check-Out
Check-Out für Zimmer 4671

V46718

9.2.4 Parameter
Folgende Parameter können von SIHOT-Seite aus manipuliert werden:

=10 SIHOT.PMS zu Türschließsystemen=

10.1 Variante I: XML-Interface
Siehe separate Beschreibung: SIHOT.PMS – XML Interface Specification.

10.2 Variante II: Serielles Interface
Im nachfolgenden werden die beiden Datensätze beschrieben, welche von SIHOT.PMS zum Türschließsystem gesendet werden. Das physikalische Protokoll ist in DIN 66258, Teil 2 definiert.

Allgemein ist festzuhalten, dass die hier gegebenen Längen in Zukunft am Ende des Satzes erweitert werden können.

10.2.1 CKI-Satz
Der CKI-Satz wird zum Türschließsystemen gesendet, um diesem mitzuteilen, dass ein Zimmer durch ein Gast belegt wird und das Türschließsystemen für diesen Gast eine Karte erstellen muss.

10.2.2 CKO-Satz
Der CKO-Satz wird zum Türschließsystem gesendet, um diesem mitzuteilen dass ein Zimmer nicht mehr belegt ist. Hierdurch wird dem Gast durch das Türschließsystem der Zutritt verboten. Dies gilt auch für die Zutrittsbereiche und die zusätzlichen Zimmer.

10.2.3 Beispiele
CKI.....101.01101.........000043180001+004080010000073800005172.Koster.Kaart.....................................10.ESP........2001041200002001041700000.......2..................................................................................................................................................................................Palma.De.Mallorca............................

CKO....101.01101.........000043180001+004080010000073800005172.Koster.Kaart.....................................10.ESP........2001041200002001041700000.......2.................................001......................00200104171200000000000000..............................................................................................Palma.De.Mallorca........................................

=11 SIHOT.PMS zu FIBU-Systemen= Bei allen FIBU-Schnittstellendateien gilt es zu beachten: Sollen bei der Übergabe der FIBU-Daten zusätzlich zu den Zahlungen aus Auslagebuchungen auch deren Umsätze übergeben werden, so muss der Registryschalter „class = uebergabeFibu, typ = verwendeAuslagen“ gesetzt werden. Dies wird durch folgenden Befehl erreicht:

Sireg –S –c uebergabeFibu –v verwendeAuslagen

11.2 Eigene Schnittstelle (Neue Version)
Die eigene Schnittstelle ist eine ASCII-Datei ohne Größenlimitation. Diese Schnittstelle bedient auch die Filosof-FIBU.

11.2.1 Parameter
Die folgenden Parameter im Dialog „Konfiguration FIBU“ beeinflussen das Verhalten der Schnittstelle. Insbesondere ist auch ein Aus­tausch­pfad für die zu erstellende Datei zu definieren.

11.2.2 Definition des Dateinamens
Der Dateiname endet immer mit 001. Das FIBU-System ist für das Löschen dieser Dateien verantwortlich.

Falls es sich um eine MPE-Installation von SIHOT handelt, werden die Übergabedateien in unterschiedliche Verzeichnisse abgestellt.

11.2.3 Definition des Satzaufbaus
Jede Zeile wird mit CR und LF abgeschlossen. D.h. die Zeile der Standardschnittstelle hat 367 Zeichen, die der erweiterten 467.

Negative numerische Werte werden mit „-„ links dargestellt.

11.2.4 Logik der Schnittstelle
Die Logik der Schnittstelle kann auf folgende Art definiert werden:
 * Tag der Leistungserbringung, dies entspricht der Soll-Versteuerung gemäß Umsatzsteuergesetzt.
 * Tag der Leistungsabrechnung. In Deutschland ist diese Logik (Ist-Besteuerung) nur dann möglich, wenn:
 * Im Vorjahr der Gesamtumsatz unter € 125.000,- lag oder
 * Befreiung von der Verpflichtung zur Buchführung (i.d.R. Einnahmen-Überschuss-Rechnung) bestand oder
 * Bei Angehörige von freien Berufen

Die Debitornummer wird von SIHOT.PMS vergeben, wenn das erste Mal ein Debitorkonto für diesen Gast kreiert wird. Der Startwert der Debitornummer kann in der Konfiguration der Nummernkreise hinterlegt werden. Das FIBU-System legt den Debitor an, wenn diese Debitornummer das erste mal in der Schnittstelle erscheint.

11.3 DATEV
Es wird eine Textdatei übergeben, die folgenden Aufbau hat:
 * Umsatz in Cent
 * Leer
 * Steuerschlüssel gemäß DATEV, bzw. Leer wenn es sich um ein Automatikkonto handelt
 * Gegenkonto
 * Belegfeld 1
 * Belegfeld 2
 * Datum
 * Konto
 * Kostenstelle 1
 * Kostenstelle 2
 * Skonto
 * Buchungstext

Diese lesbare Datei wird durch ein Programm von DATEV (damo.exe) in ein DATEV-internes-Format umgewandelt. Der Aufruf lautet: damo.exe FBOP‑BW. Hieraus entstehen zwei Dateien:
 * dv01: Vorlaufdatei
 * de001: Datendatei

11.3.1 Regsitry
Die nachfolgenden Schalter können/müssen in der Registry definiert werden.

11.3.2 Daten nach Leistungserbringung oder Leistungsabrechnung
DATEV kann generell konfiguriert nach:
 * Tag der Leistungserbringung, dies entspricht der Soll-Versteuerung gemäß Umsatzsteuergesetzt.
 * Tag der Leistungsabrechnung. In Deutschland ist diese Logik (Ist-Besteuerung) nur dann möglich, wenn:
 * Im Vorjahr der Gesamtumsatz unter € 125.000,- lag oder
 * Befreiung von der Verpflichtung zur Buchführung (i.d.R. Einnahme-Überschuß-Rechnung) bestand oder
 * Bei Angehörigen von freien Berufen

11.3.3 DATEV oder DATEV pro Tag
Weiterhin muss entschieden werden, ob die Daten verdichtet oder einzeln übergeben werden sollen (Programm „Übergabe Fibu“ unter Listen)

Einzeln (DATEV pro Tag) bedeutet, dass der Umsatz pro Tag übergeben wird. Vorteil: Genauigkeit (bessere Kontrolle). Nachteil: bei Übergabe an ein Zentralrechnersystem wird DATEV nach Buchungssätzen bezahlt (relativ teuer).

Verdichtet (DATEV) bedeutet, Übergabe eines Buchungssatz pro Umsatzkonto für die ganze angegebene Periode.

11.3.4 Abrechnungsnummer
Im Programm „Übergabe Fibu“ gibt es weiterhin ein Feld für die „Abrechnungsnummer“. Hier kann manuell die Abrechnungsnummer eingetragen werden. Die Abrechnungsnummer kann nur einmalig vergeben werden und ergibt sich standardmäßig aus der Monatsnummer.

Wenn zum Beispiel in der Finanzbuchhaltung für den Umsatz und die Kosten eine Abrechnungsnummer vergeben werden, muss bei der monatlichen Eingabe der Abrechnungsnummer eine Zahl übersprungen werden. Hierzu ein Beispiel: Dies ist der Standard. D.h. keine Eingabe in diesem Feld.
 * Einfach ohne Kosten Januar = 01 ; Februar = 02 ; März = 03 ...
 * Mit Kosten Januar = 01 ; Februar =03 ; März =05..... (02, 04, 06 werden als Abrechnungsnummer für die Kosten genutzt.

11.3.5 Automatikkonten
In der DATEV-Finanzbuchhaltung gibt es die Möglichkeit, die Umsatzkonten als Automatikkonten anzulegen. Bei Automatikkonten wird vor der Fibu - Umsatzkontennummer der Mehrwertsteuerschlüssel definiert und in DATEV automatisch die Mehrwertsteuer ausgegeben.

Z.B Umsatzkonto 5016 = Logis 305016 = Logis mit 16% Mehrwertsteuer

WICHTIG : Werden die Umsatzkonten für DATEV als Automatikkonten konfiguriert müssen alle Leistungen die auf die jeweiligen Umsatzkonten laufen auf die richtige Mehrwertsteuer überprüft werden (keine unterschiedliche Mwst-Sätze in SIHOT und FIBU).

Sind in DATEV keine Automatikkonten definiert, muss die Mehrwertsteuertabelle unter Konfiguration Fibu angepasst werden. Zudem muss der Schalter und der Schalter „6113“ in der regsitry gesetzt.

11.3.6 OP-Buchungen und DATEV
Die Offenen Posten können in SIHOT ausgebucht werden und die Ausbuchungen an die FIBU übergeben werden. Die in der DATEV hinterlegte Debitor Nr. muss manuell in SIHOT (Gaststamm) eingetragen werden.

Werden die Offene Posten detailliert an die FIBU übergeben, sollten diese auch in der FIBU ausgebucht werden. Dies hat den weiteren Vorteil, daß periodengerecht (Abgrenzung) gebucht bzw. nachgebucht werden kann.

Hierzu ein Beispiel:

Ein Kontoauszug wird wöchentlich von der Bank bezogen. Die Wertstellung (Buchungseingang) der meisten Zahlungseingänge liegt ein oder mehrere Tage zurück. In SIHOT können nur für den aktuellen Tag Zahlungen gebucht werden.

In der Finanzbuchhaltung kann für einen bestimmten Zeitrahmen in die Vergangenheit gebucht werden. Dies ist wichtig für Zeiträume, die z.B. Monats- Jahres- bzw. Bilanzperioden überschreiten.

In dem Menü „Konfiguration Fibu“ kann der Schalter „Keine OP – Buchungen“ auf JA gestellt werden und somit parallel zur Finanzbuchhaltung ausgebucht und das Mahnungswesen betrieben werden.

Wichtig: Bei DATEV sollte der Registy-Schalter „Bei Neuanlage eines Debitorkontos keine Debitornummer anlegen“ unbedingt auf JA stehen.

11.3.7 Buchungslogik
SIHOT ist die Nebenbuchhaltung zur Hauptbuchhaltung FIBU. Restanten werden als Forderungen an die Finanzbuchhaltung gegeben.

Beispiel: 3 Tage a 100,-, Barzahlung

1.Tag

2.Tag

3.Tag

Zum Beispiel dient die Gastkontenliste zur Abstimmung der Haupt­buchhaltung.

In diesem Zusammenhang soll der Hotelier an die Auf­bewahrungs­pflicht / -frist der SIHOT Unterlagen erinnert werden.

11.3.8 Übergabe der FIBU Daten
Die folgenden Dateien werden unter den vordefinierten Pfad (Konfiguration Fibu) durch den Start der „Übergabe Fibu“ abgestellt:

dv01 : Vorlaufdatei

de001 : Datendatei


 * eingabe.ini: Konfigurations-Datei (wird immer neu erstellt), sie beinhaltet z.B. die Mandaten- und die Beraternummer.

Konfiguration Umsatz- und Zahlungskonten

Die Fibu Kontonummer und das Gegenkonto muss bei den Umsatz- und Zahlungskonten eingetragen werden

11.4 DATEV-Rewe
Bei einigen DATEV-Versionen (REWE) ist die Mandantnummer explizit auf 1 zu setzen.

11.4.1 Buchungsätze in SIHOT
Im folgenden werden Leistungsbuchen und eine Debitorbuchung aufgezeigt:

11.4.2 Debitorausbuchung in SIHOT
Die Ausbuchung und einzelne Übertragung von Debitoren zu DATEV wird nur von der Schnittstelle pro Tag gewährleistet. Dabei wird bei der Buchung aufgesplittet zwischen Zahlung im Bereich Debitor und Auszifferung einer Rechnung. Damit das Bankkonto besser abgestimmt werden kann ist eine eigene Zahlungsart für das Ausbuchen der Debitoren anzulegen:

UI Überweisung Interimskonto

Wird nun obige Debitorrechnung ausgebucht, werden folgende Buchungssätze übertragen:

Die Buchhaltung bucht nun alle Debitoreingänge eines Tages auf das Interimskonto 1372. Damit ist eine Abstimmung des Bankkontos für die Buchhaltung möglich.

11.4.3 Austauschpfad
Als Austauschpfad für die FIBU-Dateien muß ein Laufwerk ausgewählt werden, welches von allen Arbeitsplätzen aus erreichbar ist. I.d.R sollte hierfür u:\transfer\fibu eingerichtet werden.

=12 SIHOT.PMS zur Internetreservierung=

12.1 Einführung
In den folgenden Abschnitten wird die Schnittstelle von SIHOT zu einem Internetreservierungssystem (IR) beschrieben. Die Schnittstelle basiert dabei auf einem Dateiaustausch zwischen SIHOT und IR. Die Beschreibung der Dateiformatierung ist bewusst allgemein gehalten.

Die Internetverbindung des Rechners kann wahlweise über eine ISDN-Callback-Leitung oder eine Standleitung zu einem Provider realisiert werden.


 * Wahlleitung zu einem Internet-Provider
 * Router
 * HUB
 * ISDN Telefonverbindung

Der Rechner kann als Kommunikations-Server folgende Aufgaben übernehmen:
 * Annahme der Internet-Buchungsanfragen über den Web-Server (Provider verwaltet die übrigen Web-Seiten und sichert die Leitungsverbindung Hotel-Internet)
 * Komplette Übernahme der Internet-Präsenz eines Hotels (alle Web-Seiten liegen auf dem Kommunikations-Server, der Provider sichert nur noch die Leitungsverbindung zum Internet)
 * ftp-Server
 * Mail-Server

Da vom Internet direkt auf den NT-Server zugegriffen wird, empfehlen wir, das Hotel-Netzwerk mit zusätzlichen Mechanismen abzusichern (Firewallsyteme, Proxyserver, etc.).

Weiter sollte das System aus folgenden Gründen nicht mit elementaren Aufgaben von SIHOT betraut werden: Zur Zeit bietet kein Betriebssystem / Firewallsystem eine 100-prozentige Sicherheit gegenüber äußeren Angriffen. Eine Entkopplung des NT-Rechners vom Reservierungssystem des Hotels, bietet den Vorteil, daß ‘nur’ der NT-Rechner Angriffen ausgesetzt ist, und so der Betrieb des Hotelnetzwerkes weiter nicht gefährdet wird. Im schlimmsten Fall (NT-Rechner wird geplant von außen ausgelastet / heruntergefahren) können keine Reservierungen aus dem Internet eintreffen, der übrige Hotel-Betrieb wird davon nicht berührt. Falls der NT-Server weitere, über die reine Online-Buchung hinausgehende Internet-Dienste übernehmen soll (ftp, mail, Internet-Gateway für Arbeitsplätze innerhalb des Hotels), sollte als Datenbank-Server des Reservierungssystems würde die Performance der unterschiedlichen Dienste stark herabsetzen. Die Erfahrung zeigt, das Internetsysteme bei zunehmender Akzeptanz weiter ausgebaut werden, so daß eine von Beginn an getrennte Architektur eine maximale Skalierbarkeit bietet.
 * Sicherheit
 * Performance:

12.2.1 Generelles Verfahren
Ziel der Architektur von ist die Erhaltung der Datenintegrität beider Systeme. Weiter sollen Konflikte bei Releasewechseln auf beiden Seiten (IR und SIHOT) vermieden werden. Zu diesem Zweck werden Standardschnittstellen genutzt. Im folgenden Text wird ein typischer Transfer von Buchungsdaten beschrieben:

Der Internet-Benutzer stellt über den Webbrowser eine Anfrage an das IR. Das System stellt eine Datei mit den Informationen

in einen vordefinierten Pfad des Hotelnetzwerkes. Das Reservierungssystem liest nach Signalisierung über TCP/IP diese Datei ein und verarbeitet die Anfrage. Das Ergebnis ist:
 * Gast- / Firmenschlüssel
 * Ankunft
 * Abreise
 * Länge des Aufenthalts
 * Zimmerkategorie
 * Anzahl der Zimmer
 * Anzahl der erwachsenen Personen
 * gewünschte Zimmer frei / nicht frei
 * Preis pro Zimmer

wird wiederum als Datei dem IR zur Verfügung gestellt, das daraus eine dynamische HTML-Seite mit Preisinformationen und Buchungsformular erstellt. Falls vom Reservierungssystem keine Datei erstellt wurde (System ausgelastet / heruntergefahren), wird der Benutzer über das IR aufgefordert, sich telephonisch mit dem Hotel in Verbindung zu setzen oder über die Buchungsmaske eine Reservierungsanfrage zu stellen. Die vom

Internet-Benutzer erstellten Buchungsinformationen werden vom IR SIHOT für den Import zur Verfügung gestellt.

Es gibt hier zwei Möglichkeiten für den Austausch der Daten. Dies sind

12.2.2 Dateibasierter Austausch
Der Austauschmechanismus über diese drei Dateien bietet gegenüber einer prozessgesteuerten Lösung den Vorteil, daß Anfragen aus dem Internet auch dann gesammelt werden können, falls das Reservierungssystem nicht reagiert. Diese Anfragen können dann in einem nachträglich gestarteten Importlauf eingelesen werden und gehen dem Hotel nicht verloren.

12.2.3 IP-basierter Austausch
Die Vorteile liegen hier darin, dass kein Austauschpfad definiert werden muss.

Die folgende Übersicht veranschaulicht die oben beschriebene Kommunikation. Die Formate der Dateiinhalte werden im nächsten Abschnitt beschrieben.

Formate

Allgemein

Datumsformat: DDMMYYYY

Zeitformat: HHMM

Datei

Die Daten werden im CSV-Format mit Semikolon als Trennzeichen von SIHOT abgestellt. Werden die Daten über eine Datei ausgetauscht, dann wird CR/LF als Zeilentrenner verwendet.

TCP/IP

Das Ende des TCP/IP Streams wird mit \n gekennzeichnet.

Datenaustausch

Die Daten werden, falls da Protokoll über Datenaustausch arbeitet, auf dem SIHOT-Server in einem definierten Pfad abgestellt, z.B.: \\SIHOT-SERVER\internetreservation.

Gäste

Dem IR werden die Gastdaten zur Verfügung gestellt, damit eine Vorprüfung schon auf Seiten des IR (aus Kostengründen) vorgenommen werden kann. Die Daten haben dabei folgenden Aufbau.

12.3.1 Anfragedaten für freie Zimmer
Folgende Anfragedaten dienen zur Verifikation der Verfügbarkeit. Es ist nicht notwendig, daß alle Felder gefüllt sind.

12.3.2 Antwort für freie Zimmer
Die Antwort auf obige Anfrage ist wie folgt definiert:

12.3.3 Beispiel
Folgendes Beispiel (über IP) verdeutlicht die Arbeitsweise

Anfrage für den 01.10.2000 für Einzelzimmer

BR01102000;01102000;EZ\n

Antwort: zwei freie Einzelzimmer

BAEZ;01102000;2

Anfrage für 01.10.2000 bis 02.2000 für alle Kategorien

BR01102000;02102000;EZ\n

Antwort:

BREZ01102000;2;EZ;02102000;2;DZ;01102000;5;DZ02102000;8\n

12.4 Zimmerbezogene Reservierung
Mit dieser Struktur kann eine zimmerbezogene Verarbeitung durchgeführt werden. Es wird eine Kategoriereservierung im SIHOT.PMS angelegt.

12.4.1 Daten der Anfrage
Die Datei mit den Anfragedaten wird wie folgt benannt: R (für request), eine aufsteigende 7-stelllige Nummer und die Endung 001 (Beispiel: R1234567.001).

Nach einer kurzen Beschreibung der Daten wird das Format in folgender Form spezifiziert:

12.4.2 Ergebnisdaten zur Anfrage
Zur Berechnung der Preisinformation wertet das IR die von SIHOT geschriebene Datei aus. Diese ist nach folgendem Schema benannt: A (für answer), die Nummer der entsprechenden Anfrage und die Extension 001 (Beispiel: A1234567.001). Die Datei muß folgenden Aufbau besitzen:

12.4.3 Buchungsdaten
Die Buchungsdaten werden vom IR in eine wie folgt bezeichnete Datei geschrieben: T (für transaction), eine siebenstellige Zahl (z.B. ein Teil der Reservierungsnummer) und die Extension 001. Änderungen dieser Reservierung, die über das Internet durchgeführt werden, erhalten dann aufsteigend die Extensionen 002 für die erste Änderung, 003 für die zweite Änderung usw. (Beispiel: T1997041.001).

Die Daten haben folgenden Aufbau:

Im folgenden werden die Daten angegeben, die von SIHOT an das IR übergeben werden. Dabei ist zu beachten, daß immer komplett alle Daten an das IR übergeben werden.

Als Ergebnis kommen die Daten zurück, welche in Kapitel 11.4.2beschrieben ist.

Kategorien

12.5.1 Anfragedaten
Folgende Anfragedaten dienen zur Verifikation der Verfügbarkeit. Es ist nicht notwendig, dass alle Felder gefüllt sind.

12.5.2 Buchungsdaten
Die Buchungsdaten werden an das SIHOT.PMS übergeben, um eine Buchung im System zu erzeugen.

12.5.3 Ergebnisdatei
Die Ergebnisdatei besteht aus mehreren Zeilen

Zeile 1 Zeile 2 Zeile 3 Zeile 4 bis n

12.6 Generelle Ablauf
Zimmeranfrage vom IR Zimmerbuchung über IR Initialisierung IR

Die Initialisierung des IR kann zu jedem beliebigen Zeitpunkt erfolgen. Zusammenstellung der möglichen Messages auf den Ports

Nicht bekannte Messages sollten vom IR ignoriert werden Es wird keine Unterscheidung zwischen Groß- und Kleinschreibung gemacht.

=13 SIHOT.PMS zu Seminarverwaltungen= Es wird keine Unterscheidung zwischen Groß/Kleinschreibung vorgenommen. Es wird eine Historie der Änderungen geführt durch umbenennen der Files mit einer laufenden Nummer.

Beispiel:

T1999ABC0101.txt

T1999X##0303.txt

Format

CSV mit „;“

Anmerkung: CSV begrenzt das Zeilenende mit „\n“, nicht mit „;“

Zeichensatz

TODO

Einlesen der Dateien

Durch Polling in einem einzustellenden Pfad (z.B. c:\SIHOT\transfer\hvbg ) und zu definierenden Rhythmus ( eine Stunde ).

13.1.1 Reservierungsdaten
In einer Datei wird jeweils eine Blockreservierung erfasst.

13.1.2 Namen
Die übergebenen Gastdaten werden bei einem vorhandenen Gast überschrieben.

Gast wird temporär angelegt. Es werden immer alle Namen zu der Blockreservierung übergeben. Verarbeitung wird durch große Transaktionen gesichert, d.h. „Alles oder Nichts“. Es wird automatisch eine Zimmerzuordnung aus der übergebenen Kategorie vorgenommen.

Antwortdatei Sonstiges

Falls eine Reservierung nicht verarbeitet werden konnte, Fehlermeldung über den serrhnd. Drucker hierzu einrichten. Die vom HVBG-System übergebenen Daten sind die Masterdaten.

Die notwendigen Felder in der Übergabedatei sind in der Tabelle durch eine Schattierung dargestellt.

13.2.1 Reservierungsdaten
In einer Datei wird jeweils eine Blockreservierung erfasst.


 * Es wird das Arrangement immer auf Gruppenkonto gebucht.
 * Tagesveranstaltungen werden in einer Pseudo-Kategorie angelegt. Hier ist Anreise = Abreise

13.2.2 Namen
Die Kostenstelle des Teilnehmer wird durch den Besteller dieser Reservierung bestimmt.

13.3.1 Reservierungen
In einer Datei wird jeweils eine Blockreservierung erfasst.

13.3.2 Namen
=14 SIHOT.PMS zu Telefonanlagen=

14.1.2 Format der Gebührensätze für I3
=15 SIHOT.Billbackup= Die Rechnungssicherung erfordert keine weitere Konfiguration, Sie müssen lediglich das Programm Rechnungen sichern aus dem Menü Administration – Rechnungssicherung starten. Die Rechnungen des Hotels werden daraufhin auf die eingelegte Diskette im Laufwerk A: verschoben.

Wenn Sie eine Rechnung suchen wollen, verwenden Sie hierzu das Programm Rechnungen suchen, ebenfalls aus dem Menü Administration – Rechnungssicherung.

=16 SIHOT.Export=

16.1 Export Reservation
Structure of the tables provided by the interface for exporting reservations

The following tables are provided as text-files in the ‘ODBC’-exchange-directory of the respective hotel:

These tables are linked together by unique links. The structure of the table is exactly stated below:

res.txt - reservations

grp.txt - list of names

fix.txt - rack-rates

gst.txt - guest record

16.2 Export reservation-quotas
This interface exports all reservation quotas

ktg.txt - Global information

ktp.txt - Information about one quota

ktggst.txt -

This table has the same structure as the table gst.txt in export reservation (see page 62).

16.3 Export Bill
rech.txt - Information about bills

Each paymenttype, defined in SIHOT, is given in this export file. The types are alphabetically listed. Path: xx\odbc\mandant\rech.txt

rechnung.bin - Information about bills

Each payment type, defined in SIHOT, is given in this export file. The types are alphabetically listed.

16.4 Export Sales&Marketing (Cobra)
Die in der Liste selektierten Adressen werden im ODBC-Verzeichnis des Hotels in einer DBASE-III Tabelle mit dem Namen smgst.dbf abgelegt.

Zur Erinnerung: der ODBC-Pfad für das Hotel 1 ist c:\sihot\odbc\0001

Die Feldnamen in der dbf-Datei sind mit COBRA abgesprochen und selbsterklärend.

16.5 Export-Call
The program is called with ‘date from’ and ‘date to’ and type type of daten to export as follows:

siexport -exporttype yyyy mm dd yyyy mm dd

Then all reservations whose stay touches the ‘date from’ and the ‘date to’ are exported together with all the persons attached to it on the list of names including all rack-rates.

The exporttypes are given below:

The following figure shows the dependencies between these tables as an object-diagram.

German Description for GST

=17 SIHOT.PMS Export zum GalileoZutrittssystem= Es wird bei jedem Check-In- und Check-Out eine Datei mit temporärem Namen in einen Pfad (Standard: c:\sihot\galileo) geschrieben. Das auslesende System ist dafür verantwortlich, dass diese Dateien gelöscht werden. Es wird keine Antwortdatei von SIHOT.PMS erwartet und damit auch verarbeitet. Diese Dateien enthalten die folgenden Daten:

17.1 Checkin
CKI

Vorname

Zuname

Ankunftsdatum

Abreisedatum

Zimmernummer

Kartennummer

VIP-Kz

Datum YYYYMMDD

Zeit HHMMSS

Nebenstelle

ResNr.

ResUnterNr.

Gastkontovorzeichen

Gastkontonummer

HotelNummer

GastNummer

PersonenGruppe

Sprachkennzeichen

Land-Kennzeichen

Nationalität

Anrede

Titel

Paßwort gültig?

Paßwort

Kartenanzahl

Kartenart

Sofortiger Checkout

Checkin-Position

Permission-Bits

Straße

PLZ

Ort

Telefon

Telex

17.2 Checkout
CKO

Zimmernummer

Kartennummer

Datum YYYYMMDD

Zeit HHMMSS

Nebenstelle

ResNr.

ResUnterNr.

Gastkontovorzeichen

Gastkontonummer

HotelNummer

GastNummer

Kartenart

=18 Übertragungsprotokoll IBM HIS= Für die Kommunikation wird ein logisch prüfbares Protokoll verwendet, das nach jedem Datenrecord durch den Empfänger bestätigt werden muss. Das Protokoll realisiert eine Punkt-zu-Punkt-Verbindung ohne Master.

18.1 Schnittstellen-Parameter
Folgende Schnittstellen-Parameter sind möglich:
 * 1 Start-Bit
 * 7 / 8 Daten-Bits
 * parity even, odd oder keine
 * 1 / 2 Stop-Bits
 * BCC - Blockprüfzeichen: XOR-Verknüpfung aller Zeichen nach STX (inkl. ETX/ETB)

18.2 Steuerzeichen
Zeichen innerhalb eines Datensatzes:

18.3 Kommunikationssteuerung
Zeichen zur Kommunikationssteuerung:

18.4 Format der Datenrecords
STX DatenETX BCC

18.5 Protokoll-Parameter
Time-out-Zeiten:
 * T0 = 1-3 Sekunden Reaktionszeit nach ENQ
 * T1 = 1-3 Sekunden Reaktionszeit nach Blockende
 * T2 = 3 Sekunden Reaktionszeit nach ACK

Anzahl der Sendeversuche n = 3 - 7

18.6.4 Keine Antwort
=19 Verteiltes Arbeiten mit SIHOT= Da SIHOT zur Kommunikation zwischen Client und Server als Netzwerkprotokoll TCP/IP verwendet ist es ohne weiteres möglich mit einem SIHOT Client auf einem entfernten Server zu arbeiten.

Voraussetzung ist die korrekte Konfiguration von TCP/IP am Clientstandort, d.h. wenn der Server XYZ angesprochen wird muß eine TCP/IP-Verbindung zu ihm aufgebaut werden. Ob Sie hierzu z.B. ISDN-Router verwenden oder das ganze über RAS oder andere Techniken realisieren, ist vollständig Ihnen überlassen.

In SIHOT müssen Sie nur dafür Sorge tragen, daß ein Profile mit dem entsprechenden Servernamen usw. im Pfad c:\sihot\inst steht, bevor Sie SIHOT starten. Dies können Sie z.B. durch eine Batchdatei, die mit einem Desktop-Icon verknüpft ist, realisieren.

Grund hierfür ist, dass einige Warenautomaten zwar ein Limit von der Kasse bekommen, dieses jedoch nicht beachten. Aus diesem Grund muß die Buchung dennoch ausgeführt werden, da die Ware schon entnommen ist. D.h. der Gast schuldet dem Hotel den Betrag von € 367,00. Damit die Satzart „O“ explizit übertragen wird, ist dies in der Registry (class: filosof, value: markcldifferent) zu setzten. Ansonsten werden diese Werte als Zahlung übertragen. Der Aufbau kann sich in Abhängigkeit der verwendeten DATEV-Version unterscheiden. In SIHOT ist in der Kategorienverwaltung ein Prozentsatz anzugeben, der angibt wie viel der freien Zimmer für eine Internet-Reservierung verwendet werden können.