Importserver: Unterschied zwischen den Versionen
(→TT BIRT) |
Alice (Diskussion | Beiträge) |
||
(46 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt) | |||
Zeile 11: | Zeile 11: | ||
= Entgegennahme von Daten = | = Entgegennahme von Daten = | ||
+ | |||
+ | [[Datei:dataflow_importserver.png|600px]] | ||
== FTP / Files == | == FTP / Files == | ||
+ | |||
+ | Dateien können via FTP (oder Fileshare) dem Importserver bereitgestellt werden. | ||
== E-Mails == | == E-Mails == | ||
+ | |||
+ | E-Docs werden von vordefinierten E-Mail Adressen abgeholt und verarbeitet. Dabei muss der Attachment-Name und der Mail-Betreff ggf. bestimmte Bedingungen erfüllen damit die Dokumente dem richtigen Dossier zugeordnet werden können. | ||
== Pricecoach / SOAP == | == Pricecoach / SOAP == | ||
+ | |||
+ | Eine SOAP-Schnittstelle erlaubt die Entgegennahme von Pricecoach-Daten (''im Moment inaktiv'') | ||
= Konvertierung = | = Konvertierung = | ||
Zeile 32: | Zeile 40: | ||
* [[Medium:example_cets.xml|Beispiel einer CETS-Buchung]] | * [[Medium:example_cets.xml|Beispiel einer CETS-Buchung]] | ||
− | |||
− | <module name=" | + | == XHT / Direct Sales == |
− | Traveltainment | + | <module name="Kuoni"> |
− | + | ||
+ | Unter XHT / Direct Sales werden bei Kuoni diverse Buchungs via IBE (Internet Booking Engine) zusammengefasst. DirectSales Buchungen erzeugen immer einen IMIR (Kundenrecord), welcher wiederum in Umbrella.net die automatische Erstellung eines Dossiers auslöst. Je nach Datenquelle gibt es dazu noch 1-n B2B Records. | ||
+ | |||
+ | [[Datei:directsales_overview_importserver.png|600px]] | ||
+ | |||
+ | === Traveltainment === | ||
+ | |||
+ | Amadeus Traveltainment (TT) ist eine IBE von Amadeus. Wird in TT eine Buchung ausgelöst, laufen folgende Schritte ab: | ||
+ | |||
+ | # TT verschickt für Buchungen via "helvetic tours" immer einen ShoppingCart BIRT. Dieser wird im ImportServer zu einem IMIR und einem Retail-B2B gesplittet. | ||
+ | ## Der IMIR bewirkt, dass in Umbrella.net ein Dossier angelegt wird (AutoProc BF Nummer = der Booking ID des Retail B2B). | ||
+ | ## Der Retail B2B wird automatisch ins Dossier importiert | ||
+ | ## Enthält der ShoppingCart "Add-ons" wie zB eine Versicherung, werden diese als separate B2B, in separate Dossier-Positionen verarbeitet | ||
+ | # TT verschickt - sofern mindestens eine Komponente gebucht werden konnte - eine TourOperator BIRT. Dieser enthält die Reservationsnummern der Arrangement-Komponenten im jeweiligen CRS/GDS. Für einen in Amadeus gebuchten Flug ist im TourOperator BIRT also der PNR enthalten. Im ImportServer wird der TourOperator BIRT in Komponenten B2B aufgesplittet | ||
+ | ## Für jeden Komponenten B2B wird ein EK erstellt | ||
+ | ## Resale-seitig gibt es ein paar wenige Updates durch den Komponenten-B2B: | ||
+ | ##* Reservationsnnummer des Hotels | ||
+ | ##* Terminal-Angaben auf den Flugsegmenten | ||
+ | ##* Infotexte des Lieferanten werden hinzugefügt | ||
+ | ##* Für Add-ons wird zudem der Positionstitel neu aufgebaut (weil sich der Lieferant ändert) | ||
* [[Medium:example_ttbirt_cart.xml|Beispiel eine TT-BIRT, ShoppingCart]] | * [[Medium:example_ttbirt_cart.xml|Beispiel eine TT-BIRT, ShoppingCart]] | ||
* [[Medium:example_ttbirt_to.xml|Beispiel eine TT-BIRT, TourOperator]] | * [[Medium:example_ttbirt_to.xml|Beispiel eine TT-BIRT, TourOperator]] | ||
− | + | (''Der Ablauf oben ist der Normalfall, da mehrere Systeme beteiligt sind kann sich aber die Reihenfolge verschieben'') | |
− | === | + | |
+ | [[Datei:xht_reservations.png|600px]] | ||
+ | |||
+ | In der Reservationsliste oben sieht man: | ||
+ | # Hotel-Buchung Schauinsland (814448) - Aus der BIRT-Komponente für das Hotel wird die BF Nummer 814448 ausgelesen, sowie der Origin CETS. | ||
+ | # Flug-Buchung Amadeus (8R7PRN) - Aus der BIRT-Komponente für den Flug wird die BF Nummer 8R7PRN ausgelesen, sowie der Origin Amadeus. | ||
+ | # Die Retail-B2B Buchung von TT, welche das Arrangement im Dossier erstellt | ||
+ | # Ein XHT Transfer Addon (HolidayTaxi), erzeugt eine separate Position | ||
+ | # Ein Modify von Amadeus | ||
+ | |||
+ | Ab TT-BIRT Version 2.3 gilt zusätzlich: | ||
+ | # TT verschickt für Buchungen via Fremdportale (zB ebookers) nur einen TourOperator BIRT. Dieser wird im ImportServer zu einem IMIR, einem Retail-B2B und 1-n Komponenten-B2B gesplittet. Dieser Ablauf ist in der Grafik in Khaki dargestellt | ||
+ | |||
+ | Da Traveltainment Einzelbuchungen in Drittsystemen auslöst, können diese ggf. ebenfalls Reservationdaten an Umbrella.net schicken. | ||
+ | # CETS schickt einen "Create" Record. Dieser wird in Umbrella.net via dem BIRT Komponenten-B2B abgeglichen, und | ||
+ | der EK aktualisiert | ||
+ | # Ein Amadeus PNR wird als regulärer Modify verarbeitet | ||
+ | |||
+ | ==== Zuordnung Produkte ==== | ||
+ | |||
+ | Der Origin / Vendorcode / Servicecode wird nach folgendem Mapping gesetzt: | ||
+ | |||
+ | {| class='sortable' | ||
+ | ! Supplier !! System !! Vendorcode !! Servicecode | ||
+ | |- | ||
+ | | BCH || CETS || BCH || | ||
+ | |- | ||
+ | | FTI || CETS || FTI || PCH | ||
+ | |- | ||
+ | | HELV || CETS || KUON || 015 | ||
+ | |- | ||
+ | | ITSC || CETS || ITSC || 001 | ||
+ | |- | ||
+ | | KUON || CETS || KUON || 010 | ||
+ | |- | ||
+ | | SLR || CETS || SLR || | ||
+ | |- | ||
+ | | TUIS || CETS || IMHO || 020 | ||
+ | |- | ||
+ | | JAHN || CETS || JAHN || | ||
+ | |- | ||
+ | | 5VF || CETS || 5VF || | ||
+ | |- | ||
+ | | Default Flight || CrsSystem/@System (TTDirectPricer, DirectTTPricer = Amadeus) || BSP || | ||
+ | |- | ||
+ | | Default Hotel || CrsSystem/@System || Wert von Supplier || | ||
+ | |- | ||
+ | | Holiday Taxi || Holiday Taxi || HLTX || | ||
+ | |} | ||
+ | |||
+ | |||
+ | Diese Kombination führt beim Import der Buchung letztlich zu einem assoziierten Produkt. | ||
+ | |||
+ | ==== Einkauf ==== | ||
Der Einkauf aus dem BIRT wird nach folgender Regel übernommen oder verworfen: | Der Einkauf aus dem BIRT wird nach folgender Regel übernommen oder verworfen: | ||
Zeile 67: | Zeile 146: | ||
Im Falle eines 'discard' wird beim Import der Buchung in Umbrella.net der Einkauf aufgrund der auf dem Produkt hinterlegten Marge berechnet. | Im Falle eines 'discard' wird beim Import der Buchung in Umbrella.net der Einkauf aufgrund der auf dem Produkt hinterlegten Marge berechnet. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==== Saleschannel ==== | ==== Saleschannel ==== | ||
Zeile 84: | Zeile 154: | ||
! TT-ID !! Sales channel !! Comment !! Branch | ! TT-ID !! Sales channel !! Comment !! Branch | ||
|- | |- | ||
− | | 315000 || | + | | 315000 || 12 || HelveticTours || Direct Sales |
|- | |- | ||
− | | 315001 || | + | | 315001 || 12 || HelveticTours FR || Direct Sales |
|- | |- | ||
− | | 315100 || | + | | 315100 || 11 || Kuoni || Direct Sales |
|- | |- | ||
− | | 315101 || | + | | 315101 || 11 || Kuoni FR || Direct Sales |
|- | |- | ||
| 315150 || 13 || Lastminute.ch || Direct Sales | | 315150 || 13 || Lastminute.ch || Direct Sales | ||
Zeile 96: | Zeile 166: | ||
| 315151 || 13 || Lastminute.ch FR || Direct Sales | | 315151 || 13 || Lastminute.ch FR || Direct Sales | ||
|- | |- | ||
− | | 315004 || | + | | 315004 || 12 || Helvetic Tours Mobile DE || Direct Sales |
|- | |- | ||
− | | 315005 || | + | | 315005 || 12 || Helvetic Tours Mobile FR || Direct Sales |
|- | |- | ||
− | | 315104 || | + | | 315104 || 11 || Kuoni Mobile DE || Direct Sales |
|- | |- | ||
− | | 315105 || | + | | 315105 || 11 || Kuoni Mobile FR || Direct Sales |
|- | |- | ||
| 315000 || 22 || HelveticTours || XHT | | 315000 || 22 || HelveticTours || XHT | ||
Zeile 123: | Zeile 193: | ||
|- | |- | ||
| 315105 || 22 || Kuoni Mobile FR || XHT | | 315105 || 22 || Kuoni Mobile FR || XHT | ||
+ | |} | ||
+ | |||
+ | |||
+ | ==== Dynamix ==== | ||
+ | |||
+ | Mit Kuoni "Dynamix" können Arrangement dynamisch zusammengestellt werden. Flüge werden oft bei Amadeus gebucht, Hotels via CETS. | ||
+ | |||
+ | BookingInfos/BookingCategory/@Type ist immer 'DynamixRetailer' | ||
+ | |||
+ | ==== Classic ==== | ||
+ | |||
+ | "Klassische" Traveltainment Packages sind vordefinierte Arrangements welche über diverse Websites (zB lastminute.ch) gebucht werden können. | ||
+ | |||
+ | BookingInfos/BookingCategory/@Type ist zB 'DefaultRetailer' | ||
+ | |||
+ | Aus dem BIRT einer klassischen Buchung wird ein MPSXML generiert. Dabei gilt: | ||
+ | |||
+ | * bookingReference = Shoppingcart/BookingList/Booking/ServiceList/CommonServiceInformation/ProcessNo | ||
+ | * cooperationId = 8438 (hardcoded) | ||
+ | * cooperationName = Shoppingcart/BookingList/Booking/BookingInfos/Credentials/Agency/@Label | ||
+ | * SalesChannel see [[#Saleschannel]] | ||
+ | |||
+ | |||
+ | === MicronNexus === | ||
+ | |||
+ | MicronNexus ist ein Anbieter von Mietwagen, und [http://www.traveldailynews.com/news/article/34309/micronnexus-cooperates-with-traveltainment kooperiert mit Traveltainment]. | ||
+ | |||
+ | * [[Medium:example_mironnexus.xml|Beispiel eines MicronNexus Record]] | ||
+ | |||
+ | Eine MicronNexus Buchung erzeugt ein Dossier mit einer "MICRONX" Mietwagen-Position. | ||
+ | |||
+ | === OLT === | ||
+ | |||
+ | Via onlinetravel (OLT) können bei Kuoni Hotels von verschiedenen Anbieter gebucht werden. Im Moment werden unterstützt: | ||
+ | * GTA | ||
+ | * Exclusively Hotels (ivector) | ||
+ | |||
+ | Im OLT-Record ist das B2B System der Buchung unter HotelBooking/@system sichtbar. Zu beachten ist dass Exclusively Hotels (system = IVECTOR) durchaus Hotels mit Lieferant GTA verkaufen kann. In einem solchen Fall ist das system = IVECTOR, der Hotel/Broker aber 'GTA'. Eine solche Buchung ist aber nur im Exclusively Hotels System sichtbar, darf also nicht mit einer GTA-Buchung verwechselt werden. | ||
+ | |||
+ | * [[Medium:example_olt.xml|Beispiel eines OLT Records]] | ||
+ | |||
+ | {| | ||
+ | ! Cardname !! Mapping | ||
+ | |- | ||
+ | |VI* || VI | ||
+ | |- | ||
+ | |MC* || CA | ||
+ | |- | ||
+ | |AM* || AX | ||
+ | |- | ||
+ | |AX* || AX | ||
+ | |- | ||
+ | |AP* || TP | ||
+ | |- | ||
+ | |DC* || DC | ||
|} | |} | ||
Zeile 128: | Zeile 253: | ||
= Delivery = | = Delivery = | ||
+ | |||
+ | Die (konvertierten) Daten werden in einer Queue auf dem Importserver gehalten, und - sofern Umbrella.net verfügbar ist - via SOAP an Umbrella.net geschickt. | ||
+ | |||
+ | * Falls entsprechend konfiguriert kann der Importserver mehrere Umbrella.net Instanzen "abfragen", um eine Agency ID korrekt zuzuordnen | ||
+ | * Falls Umbrella.net nicht verfügbar ist (dh Unavailable, oder im Single-User Mode), so wird die Delivery alle 5min erneut versucht (unbegrenzte Retries) | ||
+ | * Ist Umbrella.net verfügbar, aber die Agency ID ist nicht bekannt, wird der Datenrecord verworfen. | ||
= Technische/Funktionale Details = | = Technische/Funktionale Details = | ||
+ | == Datenübernahme == | ||
+ | |||
+ | Der ImportServer ist fähig DBI-Daten aus dem PNR zu lesen, sofern der Mandant [[http://www.umbrella.ch/tzdoc Umbrella Faces]] verwendet. Dort kann der Setup definiert werden, so dass zB ein "RM*KS1:/" auf die Kostenstelle 1 abgebildet wird. Ohne Umbrella Faces ist eine Übernahme der DBI-Daten nicht möglich. | ||
+ | |||
+ | |||
+ | Ein PNR mit mehr als einem Reisenden muss für die korrekte Funktion gesplittet werden. Im Anschluss sind zwei MIR's oder AIR's zu generieren. | ||
+ | |||
+ | |||
+ | === Amadeus === | ||
+ | |||
+ | Neben dem generischen Setup für die DBI-Daten gelten folgende Konventionen: | ||
+ | |||
+ | {| | ||
+ | ! Eingabe !! Beispiel !! Verwendung in Umbrella.net | ||
+ | |- | ||
+ | | AIAN || || Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird beim OrderGen als Default gesetzt | ||
+ | |- | ||
+ | | RM*UMB-TRAV/nnnn || RM*UMB-TRAV/744 || Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird auf dem Dossier als Reisender gesetzt. Die DBI-Daten des Reisenden werden zudem als Defaults auf dem Dossier gesetzt. (Es ist zu beachten dass explizite DBI-Daten aus dem PNR diese Defaults übersteuern) | ||
+ | |- | ||
+ | | RM*UMB-ARR/aaaa || RM*UMB-ARR/FR HUBER || Die Angaben in 'aaaa' werden auf dem Dossier als "Besteller" gesetzt. Dieser wird dann auf die Rechnung übernommen | ||
+ | |- | ||
+ | | RM*UMB-SC/nnnn || RM*UMB-SC/OFF || Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt | ||
+ | |- | ||
+ | | RM*UMB-SV/NFdd.dd FOdd.dd RCaa FTaa || RM*UMB-SV/NF3000.00 FO2000.00 RC10 FT50 || Savings-Daten. Die RM können Pax und/oder Segmenten zugeordnet werden, um Savings für spezifische Tickets auszuweisen. | ||
+ | |||
+ | * NF - Benchmark fare | ||
+ | * FO - Offered fare | ||
+ | * RC - Reason code | ||
+ | * FT - Fare type | ||
+ | |- | ||
+ | | RM*UMB-SV/S3,4 NFdd.dd FOdd.dd RCaa FTaa || RM*UMB-SV/S3,4 NF3000.00 FO2000.00 RC10 FT50 || *Wie oben, aber für PNRs mit mehreren Tickets und unterschiedlichen Savings-Daten sowie für Hotel- und Mietwagen-Segments. Der RM-Eintrag muss das entsprechende Segment referenzieren. | ||
+ | |- | ||
+ | |RM*UMB-SV/P1 S3,4 NFdd.dd FOdd.dd RCaa FTaa || RM*UMB-SV/P1 S3,4 NF3000.00 FO2000.00 RC10 FT50 || *Wie oben, aber die Daten gelten nur für das Ticket für Pax '1'. | ||
+ | |- | ||
+ | | RM*UMB-AUTO/STOP || || Automatisierung für diesen PNR komplett unterbinden | ||
+ | |- | ||
+ | | RM*UMB-AUTO/12345 || || Einen PNR in ein bestehendes Dossier mit Dossiernummer 12345 forcieren | ||
+ | |} | ||
+ | |||
+ | |||
+ | |||
+ | === Galileo === | ||
+ | |||
+ | Neben dem generischen Setup für die DBI-Daten gelten folgende Konventionen: | ||
+ | |||
+ | {| | ||
+ | |- | ||
+ | ! Eingabe | ||
+ | ! Beispiel | ||
+ | ! Verwendung in Umbrella.net | ||
+ | |- | ||
+ | | DI.FT-SAnnnnnn | ||
+ | | DI.FT-SA891244 | ||
+ | | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird beim OrderGen als Default gesetzt | ||
+ | |- | ||
+ | | DI.FT-TRAVnnnnnn | ||
+ | | DI.FT-TRAV891244 | ||
+ | | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird auf dem Dossier als Reisender gesetzt. Die DBI-Daten des Reisenden werden zudem als Defaults auf dem Dossier gesetzt. (Es ist zu beachten dass explizite DBI-Daten aus dem PNR diese Defaults übersteuern) | ||
+ | |- | ||
+ | | DI.FT-ARRaaaa | ||
+ | | DI.FT-ARRFR HUBER | ||
+ | | Die Angaben in 'aaaa' werden auf dem Dossier als "Besteller" gesetzt. Dieser wird dann auf die Rechnung übernommen | ||
+ | |- | ||
+ | | DI.FT-SLCHnnnn | ||
+ | | DI.FT-SLCHOFF | ||
+ | | Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt | ||
+ | |- | ||
+ | | DI.FT-SV/NFdd.dd FOdd.dd RCaa FTaa | ||
+ | | DI.FT-SV/NF3000.00 FO2000.00 RC10 FT50 | ||
+ | | Savings-Daten welche global für alle Leistungen (Flugtickets, Hotels, Mietwagen) gelten | ||
+ | *NF - Benchmark fare | ||
+ | *FO - Offered fare | ||
+ | *RC - Reason code | ||
+ | *FT - Fare type | ||
+ | |||
+ | |- | ||
+ | | DI.FT-SV/S1.4 NFdd.dd FOdd.dd RCaa FTaa | ||
+ | | DI-FR-SV/S1.4 NF3000.00 FO2000.00 RC10 FT50 | ||
+ | | *Wie oben, aber für PNRs mit mehreren Tickets und unterschiedlichen Savings-Daten sowie für Hotel- und Mietwagen-Segments. Der DI-Eintrag muss das entsprechende Segment referenzieren. | ||
+ | |- | ||
+ | | DI.FT-SV/P1 S2.3 NFdd.dd FOdd.dd RCaa FTaa | ||
+ | | DI.FT-SV/P1 S2.3 NF3000.00 FO2000.00 RC10 FT50 | ||
+ | | *Wie oben, aber die Daten gelten nur für das Ticket für Pax '1'. | ||
+ | |- | ||
+ | | DI.FT-AUTO/STOP | ||
+ | | | ||
+ | | Automatisierung für diesen PNR komplett unterbinden | ||
+ | |- | ||
+ | | DI.FT-AUTO/12345 | ||
+ | | | ||
+ | | Einen PNR in ein bestehendes Dossier mit Dossiernummer 12345 forcieren | ||
+ | |- | ||
+ | | DI.FT-TPdd oder<br/> DI.FT-TPd | ||
+ | | DI.FT-TP02 oder DI.FT-TP2 | ||
+ | | | ||
+ | <module name="ABB">der durch dd oder d gesetzte Trip Purpose Code wird im Register Commercial unter dem Bereich 'Diverses' abgebildet<br/> </module> | ||
+ | |||
+ | |- | ||
+ | | DI.FT-HCaa | ||
+ | | DI.FT-HCHZ | ||
+ | | <module name="ABB">der durch aa gesetzte Hotel Compliance Code wird im Register Commercial unter dem Bereich 'Diverses' abgebildet<br/> </module> | ||
+ | |} | ||
− | * | + | '*' Die Eingaben in PNRs mit mehreren Teilnehmern und unterschiedlichen Savings pro Ticket sind nur möglich, wenn für alle Teilnehmer dasselbe Farequote erstellt wurde. DBI-Felder können in einem beliebigen DI.FT-Format abgebildet werden. |
− | |||
− |
Aktuelle Version vom 11. Januar 2018, 15:40 Uhr
Inhaltsverzeichnis
Übersicht
Der Importserver dient als Schnittstelle zwischen diversen Reservationssystemen und Umbrella.net. Buchungsrecords werden in ein Standardformat (Umbrella B2B) konvertiert und an Umbrella.net geschickt.
Grundsätzlicher Ablauf
- Daten via FTP, E-Mail, SOAP
- Konvertierung
- B2B in MSMQ
- Retry bis zu 10x, dann "unsent"
Entgegennahme von Daten
FTP / Files
Dateien können via FTP (oder Fileshare) dem Importserver bereitgestellt werden.
E-Mails
E-Docs werden von vordefinierten E-Mail Adressen abgeholt und verarbeitet. Dabei muss der Attachment-Name und der Mail-Betreff ggf. bestimmte Bedingungen erfüllen damit die Dokumente dem richtigen Dossier zugeordnet werden können.
Pricecoach / SOAP
Eine SOAP-Schnittstelle erlaubt die Entgegennahme von Pricecoach-Daten (im Moment inaktiv)
Konvertierung
Galileo
Amadeus
CETS
XHT / Direct Sales
Delivery
Die (konvertierten) Daten werden in einer Queue auf dem Importserver gehalten, und - sofern Umbrella.net verfügbar ist - via SOAP an Umbrella.net geschickt.
- Falls entsprechend konfiguriert kann der Importserver mehrere Umbrella.net Instanzen "abfragen", um eine Agency ID korrekt zuzuordnen
- Falls Umbrella.net nicht verfügbar ist (dh Unavailable, oder im Single-User Mode), so wird die Delivery alle 5min erneut versucht (unbegrenzte Retries)
- Ist Umbrella.net verfügbar, aber die Agency ID ist nicht bekannt, wird der Datenrecord verworfen.
Technische/Funktionale Details
Datenübernahme
Der ImportServer ist fähig DBI-Daten aus dem PNR zu lesen, sofern der Mandant [Umbrella Faces] verwendet. Dort kann der Setup definiert werden, so dass zB ein "RM*KS1:/" auf die Kostenstelle 1 abgebildet wird. Ohne Umbrella Faces ist eine Übernahme der DBI-Daten nicht möglich.
Ein PNR mit mehr als einem Reisenden muss für die korrekte Funktion gesplittet werden. Im Anschluss sind zwei MIR's oder AIR's zu generieren.
Amadeus
Neben dem generischen Setup für die DBI-Daten gelten folgende Konventionen:
Eingabe | Beispiel | Verwendung in Umbrella.net |
---|---|---|
AIAN | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird beim OrderGen als Default gesetzt | |
RM*UMB-TRAV/nnnn | RM*UMB-TRAV/744 | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird auf dem Dossier als Reisender gesetzt. Die DBI-Daten des Reisenden werden zudem als Defaults auf dem Dossier gesetzt. (Es ist zu beachten dass explizite DBI-Daten aus dem PNR diese Defaults übersteuern) |
RM*UMB-ARR/aaaa | RM*UMB-ARR/FR HUBER | Die Angaben in 'aaaa' werden auf dem Dossier als "Besteller" gesetzt. Dieser wird dann auf die Rechnung übernommen |
RM*UMB-SC/nnnn | RM*UMB-SC/OFF | Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt |
RM*UMB-SV/NFdd.dd FOdd.dd RCaa FTaa | RM*UMB-SV/NF3000.00 FO2000.00 RC10 FT50 | Savings-Daten. Die RM können Pax und/oder Segmenten zugeordnet werden, um Savings für spezifische Tickets auszuweisen.
|
RM*UMB-SV/S3,4 NFdd.dd FOdd.dd RCaa FTaa | RM*UMB-SV/S3,4 NF3000.00 FO2000.00 RC10 FT50 | *Wie oben, aber für PNRs mit mehreren Tickets und unterschiedlichen Savings-Daten sowie für Hotel- und Mietwagen-Segments. Der RM-Eintrag muss das entsprechende Segment referenzieren. |
RM*UMB-SV/P1 S3,4 NFdd.dd FOdd.dd RCaa FTaa | RM*UMB-SV/P1 S3,4 NF3000.00 FO2000.00 RC10 FT50 | *Wie oben, aber die Daten gelten nur für das Ticket für Pax '1'. |
RM*UMB-AUTO/STOP | Automatisierung für diesen PNR komplett unterbinden | |
RM*UMB-AUTO/12345 | Einen PNR in ein bestehendes Dossier mit Dossiernummer 12345 forcieren |
Galileo
Neben dem generischen Setup für die DBI-Daten gelten folgende Konventionen:
Eingabe | Beispiel | Verwendung in Umbrella.net |
---|---|---|
DI.FT-SAnnnnnn | DI.FT-SA891244 | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird beim OrderGen als Default gesetzt |
DI.FT-TRAVnnnnnn | DI.FT-TRAV891244 | Der durch 'nnnnnn' als Kunden-Nummer identifizierte Kunde wird auf dem Dossier als Reisender gesetzt. Die DBI-Daten des Reisenden werden zudem als Defaults auf dem Dossier gesetzt. (Es ist zu beachten dass explizite DBI-Daten aus dem PNR diese Defaults übersteuern) |
DI.FT-ARRaaaa | DI.FT-ARRFR HUBER | Die Angaben in 'aaaa' werden auf dem Dossier als "Besteller" gesetzt. Dieser wird dann auf die Rechnung übernommen |
DI.FT-SLCHnnnn | DI.FT-SLCHOFF | Der durch 'nnnn' gekennzeichnete SalesChannel (externer Code) wird auf dem Dossier gesetzt |
DI.FT-SV/NFdd.dd FOdd.dd RCaa FTaa | DI.FT-SV/NF3000.00 FO2000.00 RC10 FT50 | Savings-Daten welche global für alle Leistungen (Flugtickets, Hotels, Mietwagen) gelten
|
DI.FT-SV/S1.4 NFdd.dd FOdd.dd RCaa FTaa | DI-FR-SV/S1.4 NF3000.00 FO2000.00 RC10 FT50 | *Wie oben, aber für PNRs mit mehreren Tickets und unterschiedlichen Savings-Daten sowie für Hotel- und Mietwagen-Segments. Der DI-Eintrag muss das entsprechende Segment referenzieren. |
DI.FT-SV/P1 S2.3 NFdd.dd FOdd.dd RCaa FTaa | DI.FT-SV/P1 S2.3 NF3000.00 FO2000.00 RC10 FT50 | *Wie oben, aber die Daten gelten nur für das Ticket für Pax '1'. |
DI.FT-AUTO/STOP | Automatisierung für diesen PNR komplett unterbinden | |
DI.FT-AUTO/12345 | Einen PNR in ein bestehendes Dossier mit Dossiernummer 12345 forcieren | |
DI.FT-TPdd oder DI.FT-TPd |
DI.FT-TP02 oder DI.FT-TP2 |
Module: ABBder durch dd oder d gesetzte Trip Purpose Code wird im Register Commercial unter dem Bereich 'Diverses' abgebildet
|
DI.FT-HCaa | DI.FT-HCHZ | Module: ABBder durch aa gesetzte Hotel Compliance Code wird im Register Commercial unter dem Bereich 'Diverses' abgebildet
|
'*' Die Eingaben in PNRs mit mehreren Teilnehmern und unterschiedlichen Savings pro Ticket sind nur möglich, wenn für alle Teilnehmer dasselbe Farequote erstellt wurde. DBI-Felder können in einem beliebigen DI.FT-Format abgebildet werden.