In einem Zimmer gelten folgende Belegungsregeln:
- Das Zimmer darf maximal mit 4 Personen belegt werden
- Alle Personen müssen älter als 2 Jahre sein
- Mindestens eine Person muss 10 Jahre alt sein
- Es dürfen höchstens 2 Personen im Alter von bis zu 12 Jahren in ein
Zimmer
Welche Occupancy-Regel deckt diese Bedingungen ab?
A:
<Occupancy Key="A">
<Person>
<MinAge>10</MinAge>
<MinCount>1</MinCount>
<MaxCount>2</MaxCount>
</Person>
<Person>
<MinAge>2</MinAge>
<MaxAge>12</MaxAge>
<MaxCount>2</MaxCount>
</Person>
</Occupancy>
B:
<Occupancy Key="B">
<Person>
<MinAge>10</MinAge>
<Count>1</Count>
</Person>
<Person>
<MinAge>2</MinAge>
<MaxCount>3</MaxCount>
</Person>
<Exclude>
<Person>
<MinAge>10</MinAge>
<Count>1</Count>
</Person>
<Person>
<MaxAge>12</MaxAge>
<Count>3</Count>
</Person>
</Exclude>
</Occupancy>
Hinweis
Testen Sie Ihre Lösung mit folgender Personenliste (Alter)
(12,12,12,10) -> Falsch, da 3 Personen im Alter von bis zu 12
Jahren enthalten.
Vollzahler und Erwachsene
In einem Hotel gilt im Doppelzimmer (DZ):
- Mindestbelegung 2 Personen ist, wobei mindestens eine Person bei
Reiseantrit 16 Jahre oder älter sein muss.
- maximale Belegung mit 3 Personen, wobei die dritte Person jünger als
16 Jahre sein muss
- stets 2 Personen Vollzahler sind
- Vollzahlerpreis beträgt 100 Währungseinheiten pro Person und
Nacht
- für Personen < bis 2 Jahre bei Reiseantritt gilt eine 100%
Ermäßigung auf alles
- für Personen < 6 Jahre bei Reiseantritt gilt eine 50% Ermäßigung
auf den Vollzahler-Preis
- für Personen < 16 Jahre bei Reiseantritt gilt eine 25% Ermäßigung
auf den Vollzahler-Preis
Belegung
Wieviele Belegungsregeln (Occupancy) sind zur Abbildung der Belegung
maximal notwendig?
- A: 2
- B: 3
- C: 1
- D: diese Belegung kann nicht abgebildet werden, da die
Vollzahler-Regel mit der Mindestbelegungsregel kollidieren kann.
Preis
Wie stellt man sicher, dass der Vollzahlerpreis stets für 2 Personen
berechnet wird?
- A: Mit einem Filter, der nur dann das Doppelzimmer durchlässt, wenn
es zwei Erwachsene (>= 16 Jahre) gibt
- B: Mit einem Conditional Tag, der die Anzahl der Erwachsenen zählt
und in einem PriceItem der Klasse für Vollzahler verwendet wird
- C: Mit einer Impact-Bedingung für die ersten 2 Personen in allen
PriceItems der PriceItem-Klasse für den Vollzahlerpreis
Optimierung
Wenn es mehrere Saisonzeiten (Vorsaison, Hauptsaison, Nachsaison) für
das Hotel gäbe, wie könnte dann die Umsetzung der Preisregel
redundanzarm erfolgen?
- A: Mit Hilfe globaler PriceItem-Klassen und entsprechenden
Bedingungen, die auf das Hotel, Zimmer und das Checkin-Datum prüfen
- D: Mit Hilfe von Conditional Tags in der SellingAccom, die die
Datumsgrenzen der Saisonzeiten prüfen und entsprechenden PriceItems in
der Unit oder SellingUnit verwendet werden
- C: Mit Hilfe von Conditional Tags, die die Datumsgrenzen der
Saisonzeiten prüfen und entsprechenden PriceItems in der
SellingAccom
- D: Mit Hilfe von SellingUnit und Filter, die auf die Sasisonzeiten
prüfen
In einem Hotel gilt, dass für einen Service immer 30% des Grundpreises des Zimmers als Zuschlag erhoben werden soll.
Das wird mit einem GenericAbsolute ausgedrückt, dass als Basis die Priceitems der Klasse Basisprice definiert.
<PriceItem Class="ServiceFee">
<GenericAbsolute>
<GenericValue>
<PercentModificationValue>
<PercentValue>30</PercentValue>
<ModificationBasis>
<ConsideredPriceItems>
<ConsideredPriceItemClasses>
Baseprice
</ConsideredPriceItemClasses>
</ConsideredPriceItems>
</ModificationBasis>
</PercentModificationValue>
</GenericValue>
<DayBase>1</DayBase>
<PersonBase>1</PersonBase>
</GenericAbsolute>
</PriceItem>
Ein Sonderpreis, definiert als Tagespreis pro Person, soll den Basispreis überschreiben,
was mit Hilfe der Kombinatorik ausgedrückt wird.
<PriceItem Class="Baseprice">
<Absolute>
<Value>560</Value>
<DayBase>x</DayBase>
<PersonBase>1</PersonBase>
</Absolute>
<Combinatorics>
<CombinationLevel>2</CombinationLevel>
<CombinationCode>ABS</CombinationCode>
</Combinatorics>
</PriceItem>
<PriceItem Class="SuperPrice">
<Absolute>
<Value>60</Value>
<DayBase>1</DayBase>
<PersonBase>1</PersonBase>
</Absolute>
<Condition>
<DayImpact>
<Date Source="Product">
<Min>2024-10-01</Min>
<Max>2024-10-06</Max>
</Date>
</DayImpact>
</Condition>
<Combinatorics>
<CombinationLevel>1</CombinationLevel>
<CombinationCode>ABS</CombinationCode>
<CombinableWhen>
<Not>
<CombinationCode>ABS</CombinationCode>
</Not>
</CombinableWhen>
</Combinatorics>
</PriceItem>
Frage: Soll das GenericAbsolute nach Abarbeitung der Kombinatorik dennoch in die Preisberechnung einfließen?
Sind regelbasierte Datenformate wie OTDS zu kompliziert für Bettenbanken oder andere Aggregatoren? Das kommt darauf an, welchen Teil des Angebots wir betrachten.
Fall 1
Oft handelt es sich bei den angebotenen Produkten um Durchverkäufe, bei denen die Angebotsdaten lediglich als mehr oder weniger vorausberechnete Preise pro Zimmer und Nacht bzw pro Person und Nacht vorliegen. In solchen Fällen sind die Regeln für die Preisberechnungen den Anbietern selbst nicht mehr bekannt, es kommt lediglich eine Aufschlagskalkulation auf die Zimmerrate zum Einsatz. Eine Lieferung solcher Konstrukte gestaltet sich in OTDS in der Tat umständlich und ineffizient, da der eigentliche Anwendungsfall von OTDS, die Erstellung der Angebote auf den Abnehmer zu verlagern und lediglich das Regelwerk dafür zu liefern, verfehlt wird.
Fall 2
Ein kleinerer Anteil des Portfolios einer Bettenbank stammt jedoch aus dem eigenen Inventar, hier sind Regeln für Basispreise, Sonderangebote, Specials etc. bestens bekannt und lassen sich sehr gut in OTDS ausdrücken.
Die Frage ist, ob OTDS für Bettenbanken bereits in der heutigen Form ein attraktives Format darstellt, oder ob OTDS um eine Möglichkeit erweitert werden sollte, die eine effiziente Übermittlung der Zimmerraten aus Fall 1 unterstützt. Im Technischen Ausschuss des OTDS-Vereins wurden dazu erste Überlegungen angestellt, um mit einem sogenannten SimplePriceItem eine Vereinfachung Abbildung "flacher" Daten zu erreichen. Doch wird mit einem solchen Ansatz wirklich eine attraktivere Lösung für Bettenbanken möglich? Es ist eher so, dass eine Einführung von SimplePriceItems auch den Wunsch nach einer Kombinierbarkeit dieses Elements mit bisherigen Konstrukten aufkommen lässt. Im Ergebnis wird die Nutzung von OTDS komplizierter, abgesehen davon, dass die bisherigen Verarbeiter solche Erweiterungen vermutlich nur zögernd umsetzen würden.
Es vermutlich sinnvoller, den bestehenden Sprachumfang zu vereinfachen, Mehrdeutigkeiten zu beseitigen und gleichzeitig die Vorteile regelbasierter Datenlieferungen auch im internationalen Umfeld besser darzustellen.
Während der gemeinsamen Sitzung der DRV-Ausschüsse
Dynamisch produzierende Veranstalter,
Informationstechnologie und
Onlinevertrieb am 16. September 2019 hat
a-five das Thema Datenqualität nochmal unter dem Aspekt der Automatisierung mit Hilfe des Offer Inspectors dargestellt. Hier die Präsentation zum
kostenlosen Download.
Wie Amadeus am 13.2.2019 in seinem Blog-Post "I killed Kati" mitteilte, bilden die im OTDS-Format angelieferten Daten inzwischen den größten Anteil im Cache des Anbieters. Was wohl zum Aussterben des ersten, ansatzweise regelbasierten Formats KATI führte.
Damit stellt sich die Frage, ob das letzte Legacy-Datenformat INFX das gleiche Schicksal ereilen wird. Unsere Prognose: nein. Im gegensatz zu KATI wird INFX quasi als universelles Format anbieterübergreifend genutzt. Die Vorteile eines regelbasierten Formats wie OTDS lassen sich nur dann nutzen, wenn in kleinteiligen Kontexten live angefragt und gesucht wird. Dann sinken Preis- und Verfügbarkeitsfehler dramatisch und die Aktualisierung der Suchmaschine wird auf Komponentenebene möglich. Zum Massenausrechnen taugt OTDS in der heutigen Fassung leider nur bedingt und es wird in diesem Feld von anderen Formaten deutlich geschlagen.
Abhilfe schaffen könnte hier das konsequente Aufräumen und ein beherztes Refactoring des Standards, davon ist aber die aktuelle Roadmap von OTDS weit entfernt.
Um das Bild nochmal aufzugreifen: I shot the sheriff, but I didn't shoot the deputy. Und somit leben wir weiter mit ausgerechneten und veralteten Angeboten im INFX-Format.
Auf der Info-Veranstaltung "Beefed-Up by OTDS" des OTDS-Vereins, die am 27.9.2016 in Köln stattfand, war angekündigt, etwas zu der Neuerung "OTDS Compressed" zu berichten. Leider gelang es aus technischen Grümdem lediglich, eine allgemeine Einführung in das Problemfeld der OTDS-Produktion von Linienflügen zu geben.
Die Argumentation geht dahin, dass ein Linienflug-Produkt sich stark von Veranstalter-Flügen bzw. Charterflügen unterscheidet, da mehr Parameter zur Suche des Produkts benötigt werden. In der Konsequenz entstünde aufgrund der Regelbasiertheit von OTDS eine Vielzahl von einzelnen Flug-Komponenten, da sich die Preis-Berechnung nicht ohne weiteres abstrahieren lässt. Das dadurch entstehende XML-Markup wäre demnach eine Ineffizienz, da zuviel "Overhead" in Form von XML-Tags benötigt würde.
Als Ausweg wird wohl eine "flache Datenlieferung" in Form einer in das OTDS eingebetteten "Tabelle" angestrebt, die bereits fertig ausgerechnete Produkte zeilenweise enthält.
Leider ist dieses Thema von außen betrachtet nicht schlüssig und - entgegen der bisherigen Praxis - auch nicht vorab dokumentiert.
Zum Einen ist das Argument des Overheads durch XML nicht stimmig. Genau so gut kann man sich darüber beschweren, dass die menschliche Sprache zuviele Redundanzen enthält. Im normalen Gebrauch stört das nicht. Setzt man moderne Tools zur Verarbeitung ein, spielen die Tags in Punkto Laufzeit-Effizienz ohnehin keine Rolle. Ein weiteres Argument, nämlich das der zu großen Dateien, ist noch leichter zu widerlegen. Eine XML-Datei mit vielen redundaten Elementen wird mit einem Kompressionsverfahren wie zip komplett eingedampft, da bleibt kaum was vom "Overhead" übrig und der Transport ist kein Problem mehr.
Jede moderne Programmierplatform bietet die Möglichkeit, riesige Dateien häppchenweise zu verarbeiten. Alle, die schonmal echte Big-Data-Probleme gelöst haben, wissen das und können damit umgehen. Warum sollten also einige Milliarden Bytes an dieser Stelle überhaupt zum Thema gemacht werden?
Daher besteht die Gefahr, dass hier in Wirklichkeit der Versuch gestartet wurde, die alte, flache Datenwelt quasi durch die Hintertür wieder salonfähig zu machen. Die Flugdaten liegen doch als Flatfile-Cache vor, warum also diese nicht direkt in den OTDS-Container reinwerfen und durchtunneln? Und nach der gleichen Logik schieben wir dann als nächstens die fertig ausgerechneten Cache-Files der EDF-Player nach etc.
Da stellen sich dann gleich zwei Fragen:
1. Warum entwirft man ein regelbasiertes Datenformat, wenn man eigentlich lieber flache Dateien verarbeiten möchte?
2. Warum nennt man das Kind nicht beim Namen und sagt dazu OTDS-Expanded statt OTDS Compressed?
Wenn nämlich bereits fertig ausgerechnete Produkte in die OTDS-Lieferung packt, stellen diese die expandierten Komponenten dar.
Es bleibt zu hoffen, dass hier bald eine Klarstellung erfolgt, verbunden mit einem Bekenntnis zum regelbasierten Ansatz des Formats.