Das Offene Touristische Datenformat OTDS hat sich als Marktstandard in der deutschen Reisebranche etabliert. Interessierten Reiseveranstaltern und Leistungsträgern gibt diese Präsentation einen Überblick über die Stärken und Strukturen des Formats und führt ein die Bedingungen (Conditions) und Preisberechnung mit diesem regelbasierten XML-Format.
2. Agenda
Was ist OTDS? - Was ist XML?
Grundaufbau OTDS
Bedingungen und Preisbestanteile
Preisberechnung mit OTDS
PriceItems
3. Übersicht des ersten Arbeitsblocks
Was ist OTDS und warum braucht man OTDS?
Wie kam es zu OTDS?
Zusammenhang Katalog und Datenlieferung
Grundaufbau von OTDS
4. Was ist OTDS und warum braucht man OTDS? 1/3
Formatbeschreibung zur Interpretation von
Daten für Reiseangebote
Der Empfänger der Daten soll wissen, in
welcher Form er die Daten verarbeiten muss,
um die Angebote suchen und buchen zu können
Ähnlich wie bei einem Kochrezept:
– Der Koch übermittelt Informationen, wie Zutaten
verarbeitet werden müssen, damit am Ende eine
wohlschmeckende Mahlzeit rauskommt
5. Was ist OTDS und warum braucht man OTDS? 2/3
Vorteile
– Einheitlicher Workflow
– 100% ausspezifiziert
– Nachvollziehbare Verarbeitung
– Ausführlicher Verarbeitungsreport
– In der Praxis bessere Qualität (Probleme sind besser adressierbar)
– Besser validierbar als flache Daten
– Enthält Kinder- und Seniorenermäßigungen
– Ermöglicht inkrementelle Datenlieferungen
– Optionale und integrierte Zusatzleistungen
– Erweiterte Angebotsattribuierung
– Leichter produzierbar für den Lieferanten
– Verkürzt die Gesamtprozesskette
– Nicht auf den nationalen Markt begrenzt
– Langfristig erweiterbar
– Ausgerichtet auf zukünftige Anforderungen
6. Was ist OTDS und warum braucht man OTDS? 3/3
Nachteile
– höhere Komplexität als flache Datenlieferungen (INFX, INFX2, etc.)
– Aufwändiger zu verarbeiten als flache Datenlieferungen
– Das Zählen der Angebote ist aufwendiger als bei flachen
Datenlieferungen
– Je nach Szenario dauert die Verarbeitung länger als bei flachen
Datenlieferungen
– Je nach Szenario ist das Datenvolumen größer als bei flachen
Datenlieferungen
– Die Verarbeitungsgeschwindigkeit einer OTDS-Datenlieferung mit
unbekannten Strukturen kann kaum vorhergesagt werden
7. Wie kam es zu OTDS? 1/3
Katalog
Info-Fax
INFX
INFX2
AICP und andere Formate
KATI + Derivate
– Komponentenbasiert
– Besteht aus einzelnen CSV-Dateien
– Ermöglicht leichter den Austausch sehr großer Datenvolumina
– Keine Einheitlichkeit
– Keine Kinderabschläge, Kinderfestpreise, etc.
– keine Transparenz für den Markt
8. Wie kam es zu OTDS? 2/3
EDF
– Komponentenbasiert
– XML basiert
– Standardisierter als KATI
– aber immer noch implizite veranstalterabhängige
Interpretationen
– Kinderermäßigungen enthalten
– proprietär, also nicht offen zugänglich
– nicht an allgemeiner Transparenz interessiert
Im Kontext Player/HUB
Gefahr des Zugriffsverlustes auf die Angebotsdaten
9. Wie kam es zu OTDS? 3/3
OTDS als Marktinitiative mehrerer Distributionssysteme
(Traveltainment, Bewotec, Traffics)
– Komponentenbasiert
– 100 % standardisiert
– Ein freies Format mit ausgeprägter Dokumentation, die permanent
weiterentwickelt wird und mit Einschränkung offen zugänglich ist
– Quasi Dokumentation für den Veranstalter, wie seine Daten zu interpretieren
sind
– Keine unnötigen Redundanzen
– Auch für flache Daten geeignet
– Enthält alle Bestandteile zum Suchen und Buchen
– Attribute des Angebotes
– Preiskalkulation
– Buchungsparameter
– flexibel erweiterbar
– XML basiert
10. Was ist XML? 1/3
Erklärungen anhand einer XML-Struktur für Kochrezepte
Ein RezeptDas wird
serviert
Weitere
Rezepte
Das wird
serviert
Das wird
serviert
11. Das Element „Flüssigkeit“
Der Value des
Elements „Flüssigkeit“
Die Attribute des
Elements „Flüssigkeit“
Die Values der Attribute des
Elements „Flüssigkeit“
Auch das ist ein Element
Was ist XML? 2/3
12. In OTDS gibt es auch kontextabhängige Default-Values
Eine Liste von Values
Keine Liste
Default-Values
Was ist XML? 3/3
13. Womit betrachte ich XML-Dateien?
Notepad ++ als XML-Viewer
– Voraussetzung: XML Modul muss installiert sein.
– Funktionen von NotePad++:
• Farbliche Darstellung von Attributen etc.
• Elemente „einklappen“ bzw. expandieren mit „-“ und „+“ am linken
Rand
• „PrettyPrint“ Funktion
o Menü ->Plugins ->XML-Tools -> PrettyPrint with LineBreaks
• Check XML Syntax
o Menü ->Plugins ->XML-Tools -> Check XML Syntax
• Validieren eines XML
o Menü ->Plugins ->XML-Tools -> Validate Now
14. Was ist eine XSD? 1/4
Beschreibung des Formates
– der einzelnen Elementen
– der erlaubten Values
– der Interpretation der gelieferten Daten
Einschränkung der Datenlieferung auf den definierten Umfang
Validierungsmöglichkeit vor dem Absenden und nach dem
Empfang der Daten
Reduktion auf die erlaubten Werte bzw. bei Strings
Sonderzeichen
Spezielle Software zum Betrachten (Oxygen/Altova)
Bei OTDS sind die Inhalte auch in der Technischen Doku
enthalten
15. Was ist eine XSD? 2/4
So sieht eine XSD zum Kochrezept aus:
16. Was ist eine XSD? 3/4
Anzahl
Choice/Sequence
Optional
Attribute gibt es
nicht mehrfach
17. Was ist eine XSD? 4/4
Definitionen für das Attribut „Mengeneinheit“
Die Values der Elemente
können genauso
eingeschränkt werden.
19. Auszug aus der Technischen Doku zu OTDS
Link: https://forum.otds.de/documentation/public/de/technisch/otds_technisch.html
User: OTDS
Passwort: 0nlined0ku ("o" als Null geschrieben)
21. Grundaufbau von OTDS 1/2
Alle Regeln für Produkte
Alle enthaltenen Brands
Alle enthaltenen Unterkünfte
Alle enthaltenen Flüge
Alle zusätzlichen Leistungen
Alle Regeln für kombinierte Komponenten
22. Grundaufbau von OTDS 2/2
Enthält alle Daten zu PMI913
Enthält alle Daten zu PMI914
usw.
23. Komponenten der Accommodation
Unterschiedliche Unterkünfte
Verkaufsebene der Unterkünfte
Unterschiedliche Verpflegungen
Unterschiedliche Zimmer
Verkaufsebene des Zimmers
Die Keys identifizieren jeweils eindeutig eine Komponente
Beispiel:
- Accommodation Key=„PMI913“
- SellingAccom Key=„W15_PMI913“
- Unit Key=„DZT“
- SellingUnit Key=„DZT_33122202“
24. Übersicht des nächsten Arbeitsblocks
Grundaufbau von OTDS
– Grundgerüst
– Eigenschaften des Angebotes
– Buchungsparameter des Angebotes
– Belegungen
27. Beispiel für mehrere Preiszeilen in einer Unit
3 Preiszeilen für
das gleiche Zimmer mit
unterschiedlichen Belegungen
28. Aufbau der SellingAccom
Bis jetzt kennen wir den Aufbau der SellingAccom in dieser Form:Die Realität ist geringfügig komplexer:
Freie Markierungen
Buchungsparameter
Attribute
Preisbestandteile
Einschränkungen
Komponentenverschiebung
38. optionale Priority
optionale Bedingung
gilt für alle enthaltenen SellingAccoms
gilt für alle enthaltenen Units
gilt für dieses Board
gilt für alle enthaltenen SellingUnits
gilt für diese SellingUnit
Theorie zur Property 1/6
39. Schrittweise Abarbeitung
1. Überprüfen der Condition der
PropertyGroup
2. Einsammeln der gültigen Properties nach
XML-Order
3. Überschreiben identischer Properties
1. Höhere Priorität gewinnt
2. Nachfolgende Properties
überschreiben
Theorie zur Property 2/6
54. Field=„BrandCode“ Field=„TravelType“
„RequestCode“ „ServiceCode“ „ServiceFeatureCode“ „BoardCode“ „DateStart“ „DateEnd“
„Title“ „Age“
Eine Servicezeile hat nur
Felder mit identischen
Source- und Classwerten
Analogien der OTDS Buchungsparameter 2/2
Jedes relevante Feld in der Buchungsmaske wird in OTDS durch ein „Field“
repräsentiert
55. Buchungsparameter 1/2
BookingParameter mit
identischem „Name“ und
„Field“ überschreiben sich.
Bei unterschiedlichen
Namen werden sie sortiert
nach Index aneinander
gefügt
Fehlen „Name“ oder „Index“
gelten Name=„Default“ und
Index=„0“
58. Schrittweise Abarbeitung
1. Überprüfen der Condition der
BookingGroup
2. Einsammeln der gültigen
Buchungsparameter nach XML-Order
3. Überschreiben / Zusammenfügen /
entfernen identischer Buchungsparameter
a) Sortierung zuerst nach Priorität
aufsteigend, dann nach XML-Order
b) Beim Überschreiben gewinnt der
nachfolgende Buchungsparameter
Theorie zu den Buchungsparametern 2/2
60. Brand-Definition 1/2
Jedes Angebot kann für mehrere Brands angeboten
werden.
Die für eine OTDS-Lieferung verwendeten Brands
werden nach den Products definiert.
Globale Booking-Definitionen wie
– Personenanreden
– Personenaltersangaben
– Terminzuordnungen der Komponenten
werden in der Regel in der Brand definiert
63. Eine Occupancy besteht aus
mehreren Gruppen von Personen
mit gleichen Eigenschaften
Die Personengruppen können
Einschränkungen bzgl. des Alters
und der Anzahl der Personen enthalten
Belegungen der Zimmer 2/3
64. 2 Personen mit Alter ab 13 Jahren
0-1 Person ab 1 Jahr
Belegungen der Zimmer 3/3
So liefert es der Veranstalter:
65. Beispiel:
2 Erwachsene (ab 18)
+ 1-2 Kinder bis 13
+ 0-1 Baby (bis 1 Jahr)
Die Occupancy hat nur damit zu tun, welche Belegung möglich ist.
Wer welche Zu-/Abschläge bekommt, wird in den PriceItems gesteuert
Beispiel für eine Belegung
66. Übersicht des nächsten Arbeitsblocks
Grundaufbau von OTDS
– Einschränkungen
– Preisbestandteile
69. Alle Bedingungen müssen erfüllt sein
Eine Bedingung muss erfüllt sein
Die Bedingung darf nicht erfüllt sein
Nur wenn diese Bedingung erfüllt ist…
… muss auch diese Bedingung erfüllt sein
Theorie der Filter und Conditions 2/2
70. Alle Einzelbedingungen müssen erfüllt sein, damit die AND-Bedingung erfüllt ist.
Es muss nur eine Einzelbedingungen erfüllt sein, damit eine OR-Bedingung erfüllt ist.
AND
Bedingung 1
Bedingung 2
OR
AND und OR
71. AND und OR und NOT im Zusammenspiel
Bedingungen können ineinander verschachtelt sein
erfüllt,
wenn
erfüllt,
wenn
erfüllt,
wenn
76. I = CheckIn
S = Stay
O = CheckOut
Mögliche Werte für DayType
Mögliche Werte für Source
(nur die vor den Klammern)
Theorie zu DayTypes und Source
77. Definition der Komponente
Die Duration ist die Anzahl der Datumsübergänge zwischen CheckIn und CheckOut
Theorie zu Duration
78. Mögliche Werte für Source
(nur die vor den Klammern)
Hier ist die Dauer für alle Komponenten identisch.
Nur OnewayFlight und BookingClass hätte eine Dauer = 0
Hier ein Standardangebot: Kein Übernachtflug oder ähnliches
Duration eines Standardpauschalangebotes
79. Die verschiedenen Duration-Sonderfälle 1/4
Ein Pauschalangebot mit Übernachtflug auf dem Hinflug
Szenario: Hinflug 22:30 Uhr -> Ankunft 10:30 Uhr
Je nach Source hat man hier ganz unterschiedliche Werte.
80. Ein Pauschalangebot mit Überlappung auf dem Hinflug
Szenario: Hinflug 0:20 Uhr -> Ankunft 3:30 Uhr
-> Es wird eine Übernachtung ab dem Vortag gebraucht/gebucht
Man checkt früher im Hotel ein als man abfliegt. Aber so ist es.
Die verschiedenen Duration-Sonderfälle 2/4
81. Ein Pauschalangebot mit Gap auf dem Rückflug
Szenario: Hinflug wie zuvor, Rückflug 0:20 Uhr -> Ankunft egal
-> Es wird keine Übernachtung am Vortag des Rückfluges gebraucht/gebucht
Die verschiedenen Duration-Sonderfälle 3/4
82. Ein Pauschalangebot mit Saisonübergang am 01.11.
Ein Pauschalangebot mit Saisonübergang am 01.11.
Die verschiedenen Duration-Sonderfälle 4/4
83. Tags sind Markierungen an Komponenten.
Die Tags werden für Produktregeln und die Preiskalkulation benutzt.
Beispiel:
Im Reisekatalog steht eine Rabattaktion:
• Alle Hotels, die auf blauen Seiten stehen, geben 10% Rabatt.
• Alle, die auf roten Seiten stehen, geben 30% Rabatt.
So sieht ein passendes PriceItem dazu aus:
Was sind Tags? 1/2
84. Beliebt sind auch Tags an Produkten.
– Damit wird gesteuert, dass bestimmte Unterkünfte
nicht für Pauschalangebote genutzt werden können
Aber auch die Kombination von Hin- und
Rückflügen wird häufig über Tags geregelt.
– Tags repräsentieren dann meistens Airlines oder
Airlinegruppen, die miteinander kombinierbar oder
nicht kombinierbar sind.
Was sind Tags? 2/2
88. Eine Unterkunft zusammen-
gesetzt aus 2 Saisons
Spezifische Einschränkungen
für den Saisonübergang
zeitliche Reihenfolge
Die Product-Definition 2/3
89. Produkt bestehend aus einer
Unterkunft und einem
ReturnFlight
Einschränkungen:
Unter anderem, welche Flüge mit
welchen Unterkünften kombiniert
werden sollen
Die Product-Definition 3/3
90. Produkteinschränkungen
z.B. ein Hotel darf nur als NurHotel verkauft werden
Bestimmte Hotels dürfen nur in Reisebüros verkauft
werden
Bestimmte Flüge dürfen nur mit bestimmten Hotels
angeboten werden
Oder es sollen generell nur bestimmte Dauern
angeboten werden
… und beliebige weitere Bedingungen
91. DefinedComponent bestehend aus
einem Hin- und einem Rückflug
Einschränkungen, welcher Hinflug mit
welchem Rückflug kombiniert werden
soll
Es werden alle DefinedComponents
mit der passenden Rolle benutzt
Defined Components
92. Zimmerpreise mit Frühstück
Je Zimmer und Terminabschnitt
VerpflegungszuschlägeFlugbasispreis = 291,-
Ermäßigungen
bestimmter Personen
Frühbucherermäßigungen
Langzeitermäßigungen
Preise
93. PriceItem
Absolute
Percent
Tagespreis 25 Euro pro Tag
Reisezuschlag 150 Euro pro Reise
Personenzuschlag 100 Euro pro Person
Verpflegungszuschlag 5 Euro pro Tag
Festtagszuschlag 50 Euro
10% Frühbucher
20% Einzelzimmerzuschlag
7=6 (100% auf den ersten oder letzten Tag)
30% Rabatt auf das 2. Kind
5% Seniorenrabatt
Theorie der Preisbestandteile (PriceItems) 1/3
94. Eigenschaften des PriceItems
• PriceItem Klassifizierung
• Wert
• pro Tag - pro Reise
• pro Person - pro Zimmer
Bedingung des PriceItems
• Normale Bedingungen
• Impact-Bedingungen
Theorie der Preisbestandteile (PriceItems) 2/3
95. Eigenschaften des PriceItems
• Wert
• Wirkung (Bezug zu Absolute-Class)
Bedingungen
• Normale Bedingungen
• Impact-Bedingungen
Theorie der Preisbestandteile (PriceItems) 3/3
96. Übersicht des nächsten Arbeitsblocks
Grundaufbau von OTDS
– PriceItems
– Impact-Bedingungen
– ConditionalTags
– Arbeiten mit der Dokumentation
97. Theorie zur Kostenmatrix
Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. Person
Kostenmatrix einer 7 Tagereise mit 3 Personen
Es reisen 2 Erwachsene (35, 34) und ein Kind (12)
P(35)
P(34)
P(12)
Die Reise startet am 26.10.
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Hauptsaison geht bis zum 31.10.
Saison A Saison N
98. Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Saison A Saison N
Tagespreis 25,- € für die Hauptsaison (Saison A)
Tagespreis 10,- € für die Nebensaison (Saison N)
Basispreis pro Person 210,- €
Kinderrabatt -30% für Kinder bis 14 Jahre auf Tagespreis
Frühbucherrabatt -5% bei Buchung bis 31.7. auf Tagespreis und Basispreis
25 25 25 25 25 25
25 25 25 25 25 25
25 25 25 25 25 25
10
10
10
30 30 30 30 30 30 30
30 30 30 30 30 30 30
30 30 30 30 30 30 30
-5% -5% -5% -5% -5% -5% -5% -5%
-5% -5% -5% -5% -5% -5% -5% -5%
-5% -5% -5% -5% -5% -5% -5% -5%
-30% -30% -30% -30% -30% -30% -30% -30%
Aufteilung von Preisbestandteilen
100. Tagespreis 25,- € für die Hauptsaison (Saison A)
Tagespreis 10,- € für die Nebensaison (Saison N)
Basispreis pro Person 210,- €
Kinderrabatt -30% für Kinder bis 14 Jahre auf Tagespreis
Frühbucherrabatt -5% bei Buchung bis 31.7. auf Tagespreis und Basispreis
Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Saison A Saison N
Aufbau der Kostenmatrix 2/4
101. Tagespreis 25,- € für die Hauptsaison (Saison A)
Basispreis pro Person 210,- €
Frühbucherrabatt -5% bei Buchung bis 31.7. auf Tagespreis und Basispreis
25,- € 30,- €+-5% -5%0,95 0,95x x = 52,25 €
Berechnung eines Kostenknoten
102. Tagespreis 25,- € für die Hauptsaison (Saison A)
Tagespreis 10,- € für die Nebensaison (Saison N)
Basispreis pro Person 210,- €
Kinderrabatt -30% für Kinder bis 14 Jahre auf Tagespreis
Frühbucherrabatt -5% bei Buchung bis 31.7. auf Tagespreis und Basispreis
52,25
Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Saison A Saison N
52,25 52,25 52,25 52,25 52,25 52,25
52,25 52,25 52,25 52,25 52,25
Aufbau der Kostenmatrix 3/4
103. Tagespreis 25,- € für die Hauptsaison (Saison A)
Basispreis pro Person 210,- €
Kinderrabatt -30% für Kinder bis 14 Jahre auf Tagespreis
Frühbucherrabatt -5% bei Buchung bis 31.7. auf Tagespreis und Basispreis
25,- € 30,- €+-5% -5%0,95 0,95x x = 45,13 €-30%0,70x
Berechnung eines Kostenknoten
104. 52,25
Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. Person
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Saison A Saison N
52,25 52,25 52,25 52,25 52,25 52,25
52,25 52,25 52,25 52,25 52,25
45,13 45,13 45,13 45,13 45,13 45,13 34,82 0
38,00 0
38,00 0 351,50
351,50
305,60
149,63 149,63 149,63 149,63 149,63 149,63 110,82 0 1008,60
Aufbau der Kostenmatrix 4/4
105. Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Saison A Saison N
Tagespreis 25,- € für die Hauptsaison (Saison A)
Tagespreis 10,- € für die Nebensaison (Saison N)
Kinderrabatt -30% für Kinder bis 14 Jahre auf Tagespreis
25 25 25 25 25 25
25 25 25 25 25 25
25 25 25 25 25 25
10
10
10
-30% -30% -30% -30% -30% -30% -30% -30%
Die folgenden PriceItems benutzen alle Impact Bedingungen:
Impact Bedingungen 1/5
106. Normale (Non-Impact)
– Die Bedingung wird erfüllt, wenn einer der Tage vom 24.12. – 31.12. in der Reise enthalten ist.
– Das PreisItem gilt dann an allen Aufenthaltstagen.
Impact
– Die Bedingung wird nur für die Aufenthaltstage vom 24.12. -31-12. erfüllt.
– Das PriceItem gilt dann nur an diesen Aufenthaltstagen.
Impact Bedingungen 2/5
109. Gilt nur für Personen von 3 -12 Jahren
Gilt für die 1. und 3. und 7. Person (alter absteigend)
Gilt für die 3. und 4. älteste Person derjenigen
Personen, die 2-6 Jahre alt sind
Impact Bedingungen 5/5
110. Vorfilterung der Tage
Welche Tage
Definition einer wiederholenden Periode
Die Tage welcher Komponente sollen betrachtet werden
Nur die Stay-Tage oder auch inklusive CheckOut?
Addressierte Tage
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Repeat = „5“ und Indices= 1 3
DayIndex
111. Negativer Index
Positiver Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-8 -7 -6 -5 -4 -3
1 2 3 4 5 6
-2
7 8
-1
Negativer Index
Positiver Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-7 -6 -5 -4 -3 -2
1 2 3 4 5 6
-1
7
Standard ohne IntervalType (IntervalTypeDefault = „Stay“)
IntervalType = „CheckInOut“
Negativer Index
Positiver Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-1 -2 -4 -3 -2 -1
1 2 3 4 5 6
Filter = 26-.10. -31.10.
DayIndex – Negative Indices und Filter
112. Negativer Index
Positiver Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-7 -6 -5 -4 -3 -2
1 2 3 4 5 6
-1
7
Standard
Until = 3
oder Until = -5
From = 4 oder
From = -4
Die letzten 2 From = -2
Die ersten 2 Until = 2
DayIndex – From/Until
113. Ähnliche Beschreibungen findet man in der Online-
Doku „Thematische Spezifikation“
Der Zugriff ist seit 02/2018 Mitgliedern des OTDS e.V.
vorbehalten
Hier zum Beispiel:
- DayIndex
- DayPriceIndex
- PersonIndex
eingeben
Arbeiten mit der thematischen Doku
114. Formal
ConditionalTags sind bedingte Markierungen von Komponenten.
Im Zusammenspiel mit ImpactBedingungen können einzelne Tage oder Personen markiert werden.
Valuebereich
Bedingung
ConditionalTags können theoretisch an allen Komponenten platziert werden:
- Accommodation, SellingAccom, Board, Unit, SellingUnit
- Brand, Product, GlobalValue
- ReturnFlight, OnewayFlight, BookingClass
- Addon, Service, ServiceFeature
Praxis
Was sind ConditionalTags? 1/4
115. ConditionalTags werden für bestimmte Bedingungen in Filtern und Conditions benutzt.
In der Regel kommen sie bei PriceItems zum Einsatz.
Formal
Praxis
Bezug zur Komponente
Bezug zur Class
Was sind ConditionalTags? 2/4
116. So sieht ein passendes PriceItem dazu aus:
Definition des ConditionTags
Valuebereich der Definition
Bedingung der Definition
ConditionalTag-Bedingung
Was sind ConditionalTags? 3/4
118. Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. Person
Reise am 26.03. für 7 Tage für 2 Erwachsene + 1 Kind
P(35)
P(34)
P(8)
26.03. 27.03. 28.03. 29.03. 30.03. 31.03. 01.04. 02.04.
C-Tag „Saison“= A
C-Tag„PersonType“=A
Imaginäre Verarbeitung in der Kostenmatrix
