Modify Preview

Ü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.

Module: EinkaufÄnderungen an Einkäufen sind im Modify Preview nicht ersichtlich.

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.

Einige typische Modify-Prozesse sind:

Zusätzliche Versicherung

Wird nachträglich eine Annullationskosten-Versichung abgeschlossen, erscheint diese als neue Leistung im TO Record. Beim Modify wird nur die neue Leistung ins Dossier eingefügt, alle anderen Daten werden nicht angepasst. Falls zB die Hoteladresse im Dossier ergänzt wurde, überschreibt der Modify diese Adresse nicht. (siehe #Anpassungen einzelner Datenelemente)

Name change (CRS)

Durch die Änderungen eines Tnr.-Namens wird beim Modify ein neuer Tnr. eingefügt. Aufgrund der Eigenheiten von Modifies aus CRS bleibt der alte Tnr. bestehen (siehe #TO Reservationssystem versus CRS) und muss anschliessend mit dem neuen Tnr. zusammengeführt werden, siehe Dossier#Teilnehmer zusammenführen.

Name change (TO Reservationssystem)

Durch die Änderungen eines Tnr.-Namens wird beim Modify ein neuer Tnr. eingefügt. Der alte Tnr. wird gelöscht. (Es gibt eine Ausnahme zu dieser Regel, nämlich falls der alte Tnr. noch mit Leistungen verknüpft ist die nicht Teil des BF sind, zB der Dossiergebühr)

Open issue: TODO: Gibt es weitere, typische Anwendungsfälle?

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

Konzept Modify Logik

Das grundsätzliche Konzept zur Verarbeitung eines Modify ist:

1. Unterschiede zwischen der Modify Reservation und der Basis-Reservation suchen
2. 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: Anrede Vorname Nachname Alter / Geburtsdatum (falls vorhanden)
Flug	Für Flugleistungen gelten folgende Felder des ersten Flugsegments als Schlüsselfelder: Abflugort Destination Abreisedatum Flugnummer
Hotel	Leistungs-Startdatum Leistungs-Enddatum Hotelname Bestätigungsnummer (falls vorhande)
Mietwagen	Leistungs-Startdatum Pickup location Return location Anbieter Bestätigungsnummer
Schiff	Leistungs-Startdatum Schiffsname Abreiseort
Zug	Für Zugleistungen gelten folgende Felder des ersten Segments als Schlüsselfelder: Abreiseort Ankunftsort Abreisedatum und -zeit
Rundreise	Leistungs-Startdatum Ort
Bus	Leistungs-Startdatum Anbieter Abreiseort (Land, Ort) Zielort (Land, Ort)
Transfer	Leistungs-Startdatum Leistungs-Enddatum Leistungsbeschreibung
Versicherung	Leistungs-Startdatum Leistungsbeschreibung Preis
Misc.	Leistungs-Startdatum Leistungs-Enddatum Leistungsbeschreibung
Für die übrigen Leistungstypen wird keine Modify-Logik unterstützt: Refund Gutschein Gebühr

Beispiele

Ein Kunde bucht einen Flug:

1. ZRH - FRA, LH5771, 07:00 ab ZRH
2. 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). Es wird daher eine neue Flugleistung eingefügt. Bei einer CRS Buchung bleibt die alte Position bestehen wegen #TO Reservationssysteme versus CRS. Bei einer Buchung in einem TO Reservationssystem wird die alte Flugleistung gelöscht.

Video, Beispiel CRS Buchung

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.

Open issue: 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

Module: 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.

BSP Zahlungen

Enthält ein MIR eine BSP Zahlung, so muss verhindert werden dass ein MIR Modify dazu führt dass die Zahlung nochmals importiert wird. Bei der Verarbeitung eines Modifies wird daher geprüft ob im Dossier eine Zahlung existiert mit identischem

• Status
• Beschreibungstext (wird aus der Zahlungsform abgeleitet, zB 'Air Plus BSP, XXXX XXXX XXXX 4367')
• Valutadatum
• Betrag
• Kreditkarten-Nummer
• Reference-Nummer (AirPlus: Approval code)