Generelles Problem der IBE

Die Advanced-IBE ist schlicht nicht dafür gemacht, einen exakten Treffer auf ein zuvor bis ins Detail spezifiziertes Angebot zu liefern. Die IBE macht vielmehr eine neue Suche anhand der üebrgebenen Suchparameter und wählt aus den potentiellen Angeboten das jeweils günstigste gefundene.


Zimmertyp (room)

Die Amadeus IBE erwartet für die Parameter room (Zimmertyp) einen Integer-Wert, den wir von Amadeus nicht übermittelt bekommen. Der bisher von für die IBE 2.5 und IBE 3.5 uns verwendete veranstalterspezifische Parameter sleistung nicht mehr zu funktionieren. Somit können wir den veranstalterspezifischen Zimmertyp nicht mehr an die IBE übergeben. Ein Mapping des Parameters room über den Zimmernamen unsererseits wäre extrem unzuverlässig, Beispiel: "Superior Zimmer" - das können wir nicht mappen.


Es gibt weitere in sleistung versteckte Informationen, die sich mit einem Mapping des Parameters nicht lösen lassen. Das typische Beispiel ist das DZ Meerblick vs. DZ Parkplatzblick. Ein Mapping des Namens “Doppelzimmer Meerblick“ wäre fehleranfällig, da es sich hier nicht um eine kategorisierte Information, sondern um veranstalterspezifischen Freitext handelt. Es gibt also auch “Seeblick”, “Poolblick”, “Bergblick” usw. und demenstprechend können wir den korrekten Match nicht garantieren - die IBE wird automatisch das günstigere, möglicherweise falsche, Zimmer anzeigen. Ein weiteres typisches Beispiel sind die 2 Einzelbetten vs. ein Doppelbett.


MultiRoom

Beachten Sie, dass das MultiRoom Feature für die Amadeus IBE explizit von Amadeus freigeschaltet werden muss. Ansonsten können MutliRoom Angebote aus Bistro nicht korrekt in die IBE verlinkt werden.


Transfers (trans)

Den IBE-Parameter trans können wir nicht verwenden, da wir Transfer-Informationen nicht von Bistro geliefert bekommen. Da sleistung nicht mehr als Parameter zur Verfügung steht, kann die IBE die im Angebot inkludierte Transfer-Leistung offensichtlich nicht mehr über die Veranstalter-Objekt-Codierung bestimmen.


Verpflegungsart (board)

Die Amadeus IBE erwartet für die Parameter board (Verpflegungsart) einen Integer-Wert, den wir von Amadeus nicht übermittelt bekommen. Der bisher von für die IBE 2.5 und IBE 3.5 uns verwendete veranstalterspezifische Parameter sleistung nicht mehr zu funktionieren. Somit können wir die veranstalterspezifische Verpflegungsart nicht mehr an die IBE übergeben. Ein Mapping des Parameters board über den Verpflegungsnamen unsererseits wäre möglich, zumindest für die Standard Verpflegungsarten Frühstück, Halbpension etc.


Angabe von Alternativ-Flügen (dtime & rtime)

Über die Angabe der Abflug- (dtime) und Ankunftszeit (rtime) können prinzipiell zwar Alternativ-Flüge von der IBE angefordert werden - allerdings sind diese Parameter unscharf (es können auch 2 Flieger zur selben Zeit starten aber mit unterschiedlichen Stopovern) und es fehlt außerdem ein Parameter zur Angabe des konkret gewünschten Carriers. Ob und inwieweit die Deeplinks bei Alternativflügen fehleranfällig sind, können wir nicht einschätzen.


Veranstalter Codes (brand)

In den Daten, die wir von Bistro erhalten, fehlt der exakte Veranstaltercode. Z.B. bekommen wir nur FTI anstatt FTI DE, FTI CH oder FTI FR. Diese Problematik tritt im Gegensatz zu den anderen Defiziten bereits beim Übertrag auf - wir können bei der GIATA-Abfrage für den non-bookable Content nicht den exakten Veranstaltercode übergeben. Ob sich diese Unschärfe des Veranstalters (Parameter brand) letztlich auch auf die Trefferliste in der IBE auswirkt, dazu liegen uns bislang noch keine Erkenntnisse vor.