Modify Preview: Unterschied zwischen den Versionen
(→Anpassungen einzelner Datenelemente) |
(→Packaged Positions) |
||
Zeile 215: | Zeile 215: | ||
<module name="Package Builder"> | <module name="Package Builder"> | ||
− | + | Für Packaged Positions greift grundsätzlich dieselbe Logik wie oben beschrieben. Neue Leistungen werden allerdings in eine neue, eigene Position eingefügt. | |
</module> | </module> | ||
Version vom 7. September 2012, 15:12 Uhr
Inhaltsverzeichnis
Übersicht
Auf dem Modify Preview werden die Änderungen angezeigt, welche beim Akzeptieren des Modify auf dem Dossier ausgeführt werden.
Layout
Benutzeroberfläche
Bereich 'Hinweise falls Modify akzeptiert wird'
Dieser Bereich gibt eine Vorschau Systemmeldungen welche ausgegeben werden falls der Modify akzeptiert wird. Typische Meldungen sind
- Die Rechnung(en) 1199-001 wurde(n) denummeriert aufgrund von Änderungen folgender Daten: Preisdetail
- Hier würde der Modify eine Preisposition ändern, was zum Denummeriern der Rechnung 1199-001 führen würde
Bereich 'SER notes'
Falls der Modify SER Notes enthält, werden diese in diesem Bereich angedruckt.
Bereich 'Pendente Änderungen'
In diesem Bereich werden die einzelnen Änderungen des Modifies angezeigt. Die Daten sind hierarchisch strukturiert, es wird also immer zuerst die betroffene Dossierposition angedruckt, darunter die Leistung und ggf. die Flugsegmente.
Buttons
Akzeptieren | Der Modify wird akzeptiert, die angezeigten Änderungen werden ins Dossier übernommen. |
Ablehnen | Der Modify wird abgelehnt, es werden keine Änderungen am Dossier vorgenommen |
Abbrechen | Der Modify bleibt als 'pendent' stehen und kann später erneut in der Modify Preview geladen werden. |
Arbeitsabläufe / Prozesse
Modify akzeptieren
Der Modify wird akzeptiert, die angezeigten Änderungen werden ins Dossier übernommen. In der #Modify Logik wird beschrieben nach welchen Kriterien Datenelemente angepasst werden.
Modify ablehnen
Der Modify wird abgelehnt, es werden keine Änderungen am Dossier vorgenommen. Der Modify bleibt als Eintrag im Register "Reservationen" des Dossier stehen (mit Status abgelehnt).
Technische/Funktionale Details
Modify Logik
Details zu #Modify akzeptieren
Eine Reservation wird als Modify erkannt, falls eine andere Reservation mit identischem:
- Filiale-Zuordnung (basierend auf Agency ID)
- Origin (zB 'CETS')
- BF Nummer
- Produkt (Kombination auf Vendor- und Servicecode)
schon vorhanden ist, und diese andere Reservation schon einem Dossier zugewiesen ist. Im folgenden wird die "andere Reservation" Basis-Reservation genannt. Diese kann prinzipiell auch selbst ein Modify (gegenüber einer noch älteren Basis-Reservation) sein.
Grundsätzliches Konzept
Das grundsätzliche Konzept zur Verarbeitung eines Modify ist:
- Unterschiede zwischen der Modify Reservation und der Basis-Reservation suchen
- Gefundene Unterschiede in Dossier übertragen
Es muss ausdrücklich erwähnt werden dass also nicht der Modify mit dem Datenstand im Dossier verglichen wird. Ändert man zB im Dossier versehentlich eine Flugnummer (LX 460 auf LX 406), und ist die ursprüngliche Flugnummer (LX 460) aber in der Basis-Reservation und im Modify gleich, dann wird das Dossier nicht angepasst!
Dieses Konzept erlaubt es dem Benutzer die Reisedaten relativ frei zu überarbeiten, ohne dass ein Modify sämtliche Änderungen überschreibt.
Anpassungen einzelner Datenelemente
Im Modify werden die einzelnen Datenelemente (Teilnehmer, Position, Leistungen etc.) geladen, dann wird anhand von Schlüsselfeldern das entsprechende Datenelement in der Basis-Reservation gesucht.
- Wird das Datenelement gefunden, werden die Nicht-Schlüssel-Felder verglichen. Änderungen werden ins Dossier überspielt
- Wird das Datenelement nicht gefunden, wird es als neues Datenelement ins Dossier eingefügt.
Zuletzt werden in der Basis-Reservation Datenelemente gesucht die im Modify nicht mehr vorkommen. Diese Datenelemente werden im Dossier gelöscht. Siehe dazu aber auch #TO Reservationssysteme versus CRS.
Datentyp | Schlüsselfelder |
---|---|
Teilnehmer | In Reservationen werden sehr wenige Teilnehmerdaten übermittelt. Um hier das Kind Thomas Müller von seinem Vater Thomas Müller zu unterscheiden müssen hier alle verfügbaren Felder als Schlüsselfelder behandelt werden:
|
Flug | Für Flugleistungen gelten folgende Felder des ersten Flugsegments als Schlüsselfelder:
|
Hotel |
|
Mietwagen |
|
Schiff |
|
Zug | Für Zugleistungen gelten folgende Felder des ersten Segments als Schlüsselfelder:
|
Rundreise |
|
Bus |
|
Transfer |
|
Versicherung |
|
Misc. |
|
Für die übrigen Leistungstypen wird keine Modify-Logik unterstützt:
|
Beispiele
Ein Kunde bucht einen Flug:
- ZRH - FRA, LH5771, 07:00 ab ZRH
- FRA - SFO, LH454, 09:50 ab FRA
- Umbuchung auf BSL - FRA - SFO
- Die Umbuchung betrifft das erste Flugsegment und darin ein Schlüsselfeld, nämlich den Abflugort (alt: ZRH, neu: BSL). Bei einer CRS Buchung wird also eine neue Flugposition hinzugefügt. Die alte Position bleibt bestehen wegen #TO Reservationssysteme versus CRS. Bei einer Buchung in einem TO Reservationssystem wird die alte Flugleistung gelöscht und eine neue eingefügt.
- Umbuchung auf ZRH - FRA - LAX
- Die Umbuchung betrifft NICHT das erste Flugsegment, die bestehende Flugleistung wird also angepasst. Das Flugsegment FRA - SFO wird gelöscht, und das neue Flugsegment FRA - LAX eingefügt.
TODO: add swf for both examples here
TO Reservationssysteme versus CRS
TO Reservationssysteme wie CETS oder TourOnline liefern bei jeder Änderung einen vollständigen Buchungsrecord. Dies ermöglicht Umbrella.net eine umfassende Aktualisierung des Dossier.
CRS wie Galileo, Amadeus etc. liefern MIRs welche ggf. nicht die vollständige Buchung beinhalten. Bei einem Modify hat Umbrella.net also nicht die vollständige Buchungsinformation, bestimmte Anpassungen am Dossier können daher nicht automatisiert werden. Insbesondere werden folgende Daten nicht automatisch angepasst:
- Aus der Buchung entfernte Teilnehmer werden nicht automatisch gelöscht
- Aus der Buchung entfernte Positionen werden nicht automatisch gelöscht
Packaged Positions
Für Packaged Positions greift grundsätzlich dieselbe Logik wie oben beschrieben. Neue Leistungen werden allerdings in eine neue, eigene Position eingefügt.
BSP Zahlungen
Approval Code!