Amadeus II unterstützt die Anbindung verschiedener Reservierungssysteme direkt an der Kasse. Dabei können gleichzeitig auch mehrere unterschiedliche Reservierungssysteme verwendet werden. Jedes dieser Systeme wird von Amadeus II getrennt und unabhängig voneinander behandelt. Die Implementierung läuft jeweils über einen eigenen individuell programmierten Treiber an einem der angeschlossenen ACFs.

Vom Ratskeller Reservierungssystem werden Reservierung und Kundendaten übernommen und in der Kasse angezeigt.


Diese Technik ist Amadeus II Kassenserver (LINA POS vor Version 1.6.4) und wird in LINA POS ab Version 1.7.x nicht weitergeführt


In der Übersicht Reservierungen in https://support.gastro-mis.de/support/solutions/36000168933 findet ihr mehr zu den möglichen Funktionen im Bereich Reservierung.

Weitere Informationen zu den LINA Schnittstellen findet ihr auf unserer LINA-Webseite https://www.amadeus360.de/partner/partner-und-schnittstellen/ .


VoraussetzungLINA POS von und bis Version 1.6.4
Lizenz LINASchnittstelle
BerechtigungBuchung Lizenzen: Geschäftsführer
Kontaktnn




INHALTSVERZEICHNIS




Amadeus Reservierungen

Die proprietären Treiber tauschen Daten in einer XML-Struktur zwischen Amadeus Kasse und Reservierungssystem aus.

Um Reservierungen Tischen zuordnen zu können gibt es in der Funktionsliste die Funktionen 602 und 603, die eine Zuordnung zwischen Tisch und Reservierung herstellen bzw. wieder aufheben.

Die Reservierung ist in Amadeus einem Tisch zugeordnet. Werden an diesem Tisch mehrere Personen bzw. Gruppen von Personen bedient, die getrennte Rechnungen wünschen, so werden die aus dem Tisch durch Splitten oder Separieren hervorgehenden Rechnungen nicht der Reservierung zugeordnet. Es müsste - im Sinne des CRM-Grundsatzes "Lieber keine Daten erfassen, als schlechte Daten erfassen" - der Kellner für jede der Rechnungen bzw. jeden der Tische separat Debitoren erfassen und korrekt zuordnen. Das wird im laufenden Betrieb nicht machbar sein, zumal ja die Entscheidung gefallen ist, Debitorendaten nur im Backoffice bzw. an der Rezeption zu erfassen.


Ratskeller Reservierungssystem, Verbindung von und zu Amadeus Kasse

Technische Umsetzung

Das Ratskeller Reservierungssystem muss zum Computer auf dem der zugehörige Reservierungs-Treiber läuft eine Socketverbindung auf Port 2006 aufbauen. Diese Socketverbindung wird in der Folge benutzt, um das hier definierte Protokoll auszutauschen.

Jeder Befehlsaufruf erfolgt in Form eines übermittelten Texts, der mit UTF-8 codiert ist, und einem CRLF abgeschlossen wird. Die Antwort auf den Befehl erfolgt wiederum in Form eines UTF-8 codierten Textes und einem nachfolgenden CRLF. XML-Strukturen werden ohne Formatierungen, also ohne Zeilenumbrüche und Einrückungen, übertragen.

Verbindungsaufbau

Nach dem Öffnen des Sockets zum Treiber muss binnen 10 Sekunden der Befehl "START" geschickt werden.

Daraufhin initialisiert der Treiber die Kommunikation mit dem Server, und antwortet mit einer XML-Struktur status-xml, in der alle heute gültigen Reservierungen des Partnersystems mit ihrem in Amadeus gültigen Status gelistet werden.

status-xml ... Struktur mit den Statusdaten für Reservierungen. Definition siehe unten.

Verbindungsstatus

Damit Amadeus im laufenden Betrieb erfolgte Änderungen des Reservierungsstatus in Echtzeit übermitteln kann, muss die Socketverbindung zwischen Reservierungssystem und dem Treiber offen gehalten werden.

Um den Verbindungsstatus zuverlässig überwachen zu können muss zwischen den Systemen ein fortlaufender Handshake ausgetauscht werden. Hierfür hat sich ein "Ping/Pong" Mechanismus gewährt:

  • Nach spätestens 10 Sekunden ohne Datenaustausch schickt das Reservierungssystem den Befehl "PING", und erhält umgehend die Antwort "PONG" zurück.
  • Klappt dieser Handshake nicht binnen längstens 12 Sekunden ist die Verbindung gestört, beide Systeme beenden die Verbindung, und initiieren/erwarten einen neuen Verbindungsaufbau wie oben beschrieben.

Nachdem Amadeus mit "PONG" geantwortet hat würden eventuell verfügbare unmittelbar folgend (in jeweils eigenen mittels CRLF terminierten Zeilen) Status-Updates in Form von status-xml übermittelt.


Verbindungsabbau

Um die Socketverbindung kontrolliert zu beenden können beide Seiten den Befehl "STOP" absetzen. Nach dem Senden bzw. Erhalten dieses Befehls wird das Socket von beiden Seiten unmittelbar geschlossen.


Datenaustausch Reservierung

RESERVATION id res-xml (res-xml)

Mit dem RESERVATION-Befehl werden die Daten einer Reservierung übertragen. Amadeus legt eine neue Reservierung an bzw. ändert eine bereits mit der ID vorhandene Reservierung. Als Antwort wird eine XML-Struktur status-xml zurückgegeben.

ID ... Eindeutiger alphanumerischer Schlüssel der Reservierung im Reservierungssystem

res-xml ... XML-Datenstruktur mit den Reservierungsdaten

<reservation id="ID">
    <status>STATUS</status>
    <start>YYYY-MM-DD HH:MM:SS</start>
    <duration>HH:MM:SS</duration>
    <nbr_adults>x</nbr_adults>
    <nbr_kids>x</nbr_kids>
    <nbr_infants>x</nbr_infants>
    <customer>x</customer>
    <firstname>FIRSTNAME</firstname>
    <middlename>MIDDLENAME</middlename>
    <lastname>LASTNAME</lastname>
    <street>STREET</street>
    <streetnumber>STREETNUMBER</streetnumber>
    <street2>STREET2</street2>
    <street3>STREET3</street3>
    <zip>ZIP</zip>
    <city>CITY</city>
    <state>STATE</state>
    <country>COUNTRY</country>
</reservation>


start ... Startdatum und -zeit der Reservierung.

duration ... Geplante Dauer der Reservierung.

nbr_adults ... Anzahl der Erwachsenen bzw. Personen der Reservierung

nbr_kids ... Anzahl der Kinder. Dieses Feld ist optional und muss nicht angegeben werden.

nbr_infants ... Anzahl der Kleinkinder die spezielle Stühle benötigen. Dieses Feld ist optional und muss nicht angegeben werden.

csustomer ... Kundennummer im Reservierungssystem. Dieses Feld ist optional und muss nicht angegeben werden.

firstname ... Vorname des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

middlename ... Mittelname des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

lastname ... Hauptname des Kunden.

street ... Straße der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

streetnumber ... Hausnummer (ggf. mit Zusatz) der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

street2 ... Straße #2 der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

street3 ... Straße #3 der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

zip ... Postleitzahl der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

city ... Ort der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

state ... Bundesland der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

country ... Land/Nation der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden. Hier kommt der international übliche Ländercode mit 2 Buchstaben zum Einsatz, also z.B. "DE" für Deutschland oder "AT" für Österreich.

 

RESERVATION STATUS (status-xml)

Mit dem RESERVATION-STATUS-Befehl ohne Code wird der Status aller heutigen (Geschäftstag, nicht Kalenderdatum) Reservierungen in Amadeus abgefragt. Amadeus antwortet mit einer XML-Struktur status-xml, die den Reservierungsstatus der einzelnen Reservierungen enthält.


status ... Der Reservierungsstatus in Amadeus.

  • OPEN - Reservierung ist offen. Dieser Status wird vom Reservierungssystem gesetzt und an Amadeus übermittelt.
  • CANCELLED - Reservierung wurde storniert. Dieser Status wird vom Reservierungssystem gesetzt und an Amadeus übermittelt.
  • CONFIRMED - Reservierung wurde bestätigt. Dieser Status wird vom Reservierungssystem gesetzt und an Amadeus übermittelt.
  • CHECKIN - Gäste sind eingetroffen und die Reservierung wurde einem Tisch zugeordnet. Dieser Status wird von Amadeus gesetzt und an das Reservierungssystem übertragen.
  • CLOSED - Die Rechnung wurde bezahlt und der Tisch damit geschlossen. Dieser Status wird von Amadeus gesetzt und an das Reservierungssystem übertragen.
  • INVALID - Die Reservierungsdaten wurden als für Amadeus nicht verarbeitbar eingestuft, und die Reservierung als ungültig verworfen.

 

RESERVATION STATUS id (status-xml)

Mit dem RESERVATION-STATUS-Befehl wird der Status der Reservierung ID in Amadeus abgefragt. Amadeus antwortet mit einer XML-Struktur status-xml, die den angefragten Reservierungsstatus enthält.

ID ... Eindeutiger alphanumerischer Schlüssel der Reservierung im Reservierungssystem

status-xml ... XML-Datenstruktur mit den Statusdaten von Reservierungen

<status>
    <res id="ID" table="TABLE">
        STATUS
    </res>
</status>

id ... Der eindeutige Schlüssel der Reservierung im Reservierungssystem.

table ... Die Tischnummer des der Reservierung zugeordneten Tisches. Dieser Parameter ist optional, und wird nur angegeben, wenn eine Tischzuordnung aktiv ist. Achtung: Die Tischnummer ist alphanumerisch, muss also keine Zahl sein.

status ... Der Reservierungsstatus in Amadeus.


RESERVATION DETAILS id   (details-xml)

Mit dem RESERVATION-DETAILS-Befehl werden die Details der Reservierung ID in Amadeus abgefragt. Amadeus antwortet mit einer XML-Struktur details-xml, die Details zum der Reservierung zugeordneten Tisch enthält. Hat die Rechnung den Status OPEN, CONFIRMED oder CANCELLED sind hier noch keine Details verfügbar. Für den Status CHECKIN werden die Details zum offenen Tisch übertragen. Diese Details können sich laufend ändern, da am offenen Tisch ja laufend bestellt und geändert wird. Für den Status CLOSED werden die Rechnungsdetails übertragen.

ID ... Eindeutiger alphanumerischer Schlüssel der Reservierung im Reservierungssystem

details-xml ... XML-Struktur mit detaillierten Tischdaten zur Reservierung.

<details id="ID">
    <status>STATUS</status>
    <table>TABLE</table>
    <document>DOCUMENT</document>
    <datetime>DATETIME</datetime>
    <nbr_adults>x</nbr_adults>
    <nbr_kids>x</nbr_kids>
    <nbr_infants>x</nbr_infants>
    <waiterteam>
        <number>NUMBER</number>
        <name>NAME</name>
    </waiterteam>
    <articles>
        <article>
            <number>NUMBER</number>
            <name>NAME</name>
            <count>COUNT</count>
            <priceperunit>PRICE</priceperunit>
            <balance>BALANCE</balance>
            <dataset>ID</dataset>
            <parent>ID</parent>
            <site>
                <number>NUMBER</number>
                <name>NAME</name>
            </site>
            <menucard>
                <number>NUMBER</number>
                <name>NAME</name>
            </menucard>
            <pricelevel>
                <number>NUMBER</number>
                <name>NAME</name>
            </pricelevel>
            <sortorder>
                <number>NUMBER</number>
                <name>NAME</name>
            </sortorder>
            <finance>
                <number>NUMBER</number>
                <name>NAME</name>
            </finance>
            <financecategory>
                <number>NUMBER</number>
                <name>NAME</name>
            </financecategory>
            <waiter>
                <number>NUMBER</number>
                <name>NAME</name>
            </waiter>
            <masterwaiter>
                <number>NUMBER</number>
                <name>NAME</name>
            </masterwaiter>
            <vat>
                <number>NUMBER</number>
                <name>NAME</name>
                <factor>FACTOR</factor>
            </vat>
            <detailcategory>
                <number>NUMBER</number>
                <name>NAME</name>
            </detailcategory>
            <category>
                <number>NUMBER</number>
                <name>NAME</name>
            </category>
            <grosscategory>
                <number>NUMBER</number>
                <name>NAME</name>
            </grosscategory>
        </article>
    </articles>
    <finances>
        <finance>
            <number>NUMBER</number>
            <name>NAME</name>
            <balance>BALANCE</balance>
            <financecategory>
                <number>NUMBER</number>
                <name>NAME</name>
            </financecategory>
            <waiter>
                <number>NUMBER</number>
                <name>NAME</name>
            </waiter>
            <masterwaiter>
                <number>NUMBER</number>
                <name>NAME</name>
            </masterwaiter>
        </finance>
    </finances>
</details>

status ... Der Reservierungsstatus in Amadeus. Ist die übergebene Reservierungs-ID aus Amadeus-Sicht ungültig wird der Status "INVALID" zurückgegeben.

table ... Die alphanumerische Tischnummer des der Reservierung zugeordneten Tisches. Dieses Element, und alle in der obigen Struktur folgenden Elemente, sind nur angegeben, wenn die Reservierung gültig ist, und einem Tisch zugeordnet worden ist.

document ... Der Rechnungsnummer, die von Amadeus vergeben wurde. Dieses Element ist nur vorhanden, wenn der Tisch bereits mit einer Rechnung abgeschlossen wurde.

datetime ... Datum und Uhrzeit der Rechnung, wiederum nur gegeben, falls der Tisch mit einer Rechnung abgeschlossen wurde.

nbr_adults ... Anzahl der Erwachsenen bzw. Personen die für den Tisch der Reservierung eingegeben wurde. Ist hier keine Eingabe erfolgt wird dieses Element nicht ausgegeben.

nbr_kids ... Anzahl der Kinder die für den Tisch der Reservierung eingegeben wurde. Ist hier keine Eingabe erfolgt wird dieses Element nicht ausgegeben.

nbr_infants ... Anzahl der Kleinkinder die für den Tisch der Reservierung eingegeben wurde. Ist hier keine Eingabe erfolgt wird dieses Element nicht ausgegeben.

waiterteam ... Das Kellnerteam, das den Tisch bedient hat. Hier sind die Elemente number und name enthalten, die jeweils eindeutige Bezeichner für das Kellnerteam sind. Ist kein Kellnerteam auf diesem Tisch aktiv, so wird die gesamte Sub-Struktur waiterteam nicht ausgegeben.

Das Schema wie hier beim waiterteam ist für alle folgenden Elemente mit number und name gültig, und wird nicht wiederholt erläutert.

articles ... Enthält die Liste der am Tisch bonierten Artikeldaten.

article ... Enthölt die Daten eines am Tisch bonierten Artikels. Dieses Element wird so oft vorkommen, wie verschiedenartige Artikel am Tisch boniert worden sind.

number ... Artikelnummer.

name ... Artikelname.

count ... Anzahl.

priceperunit ... Einzelpreis

balance ... Saldo.

dataset ... Datensatz-Id für diesen Artikel.

parent ... Datensatz-Id des übergeordneten Artikels, also z.B. die Id des "Schnitzels", wenn "Kartoffelsalat" dazu bestellt worden ist. Dieses Element ist nur gegeben, wenn es eine solche Zurdnung gibt.

site ... Verkaufsstelle.

menucard ... Angebot.

preislevel ... Preisebene in der boniert wurde.

sortorder ... Sortierung in der boniert wurde. Dieses Element wird nur angegeben, wenn eine Sortierung explizit gewählt wurde.

finance ... Finanzart die für diesen Artikel gilt. Das wird in der Regel "Umsatz" sein, kann aber für Storno, Auslagen, Hausbons, etc. anders sein.

financecategory ... Kategorie der Finanzart.

waiter ... Kellner der diese Bonierung durchgeführt hat.

masterwaiter ... Chefkellnernr., der diese Bonierung für den Kellner durchgeführt hat. Dies kann z.B. im Zusammenhang mit Stornos und entsprechenden Stornoberechtigungen auftreten. Dieses Element ist optional.

vat ... Umsatzsteuer, die zur Anwendung kommt. Als factor ist der Steuersatz zusätzlich verfügbar.

finances ... Enthält die Liste der am Tisch durchgeführten Finanzarten.

finance ... Enthält die Daten einer am Tisch angewendeten Finanzart.

number ... Nummer der Finanzart.

name ... Name der Finanzart.

balance ... Saldo.

financecategory ... Kategorie der Finanzart.

waiter ... Kellner der diese Bonierung durchgeführt hat.

masterwaiter ... Chefkellnernr, der diese Bonierung für den Kellner durchgeführt hat. Dies kann z.B. im Zusammenhang mit Stornos und entsprechenden Stornoberechtigungen auftreten. Dieses Element ist optional.

 

DEBITOR id debitor-xml  (debitor-xml)

Mit dem DEBITOR Befehl werden Kundendaten übertragen. Amadeus legt einen neuen Kunden an bzw. ändert einen bereits mit der ID vorhandenen Kunden. Als Antwort wird eine XML-Struktur status-xml mit Status OKAY oder ggf. INVALID und dem XML-Tag deb anstelle von res zurückgegeben.

debitor-xml ... XML-Datenstruktur mit den Kundendaten.

<debitor>
    <customer>x</customer>
    <firstname>FIRSTNAME</firstname>
    <middlename>MIDDLENAME</middlename>
    <lastname>LASTNAME</lastname>
    <street>STREET</street>
    <streetnumber>STREETNUMBER</streetnumber>
    <street2>STREET2</street2>
    <street3>STREET3</street3>
    <zip>ZIP</zip>
    <city>CITY</city>
    <state>STATE</state>
    <country>COUNTRY</country>
</debitor>

customer ... Kundennummer im Reservierungssystem.

firstname ... Vorname des Kunden.

middlename ... Mittelname des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

lastname ... Hauptname des Kunden.

street ... Straße der Anschrift des Kunden.

streetnumber ... Hausnummer (ggf. mit Zusatz) der Anschrift des Kunden.

street2 ... Straße #2 der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

street3 ... Straße #3 der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

zip ... Postleitzahl der Anschrift des Kunden.

city ... Ort der Anschrift des Kunden.

state ... Bundesland der Anschrift des Kunden. Dieses Feld ist optional und muss nicht angegeben werden.

country ... Land/Nation der Anschrift des Kunden. Hier kommt der international übliche Ländercode mit 2 Buchstaben zum Einsatz, also z.B. "DE" für Deutschland oder "AT" für Österreich.