Modify Preview: Unterschied zwischen den Versionen
Jasmin (Diskussion | Beiträge) |
Jasmin (Diskussion | Beiträge) |
||
| Zeile 4: | Zeile 4: | ||
=== Grundsätzliches Konzept === | === Grundsätzliches Konzept === | ||
| − | [[File: | + | [[File:Modify logik 1.png|thumb|right|Konzept Modify Logik]] |
Das grundsätzliche Konzept zur Verarbeitung eines Modify ist: | Das grundsätzliche Konzept zur Verarbeitung eines Modify ist: | ||
| Zeile 360: | Zeile 360: | ||
*Wenn das Original Ticket bereits in ein Dossier importiert wurde, wird der Refund als Modify dargestellt und erstellt im bestehenden Dossier eine neue Position | *Wenn das Original Ticket bereits in ein Dossier importiert wurde, wird der Refund als Modify dargestellt und erstellt im bestehenden Dossier eine neue Position | ||
| − | *Wenn das Original Ticket nicht in ein Dossier importiert wurde, kommt der Refund ohne Dossier Referenz auf die Importqueue | + | *Wenn das Original Ticket nicht in ein Dossier importiert wurde, kommt der Refund ohne Dossier Referenz auf die Importqueue |
| + | |||
| + | [[Category:Seiten mit defekten Dateilinks]] | ||
Aktuelle Version vom 1. November 2017, 16:18 Uhr
Inhaltsverzeichnis
Übersicht
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 der Modify nicht mit dem Datenstand im Dossier verglichen wird, sondern mit der Basis-Reservation. Ändert man z.B. im Dossier versehentlich eine Flugnummer (LX 460 auf LX 406), und ist die ursprüngliche Flugnummer (LX 460) 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.
Umbrella.net ist kein Reservationssystem. Es ist immer der aktuelle Stand der Kundenreservation im Reservationssystem (TO-Reservationssystem, CRS/GDS was bedeuten diese Abkürzungen?), in welchen die Kundenreservation vorgenommen wurde, verbindlich. Der Umbrella-Benutzer muss dafür besorgt sein, die Daten in Umbrella.net uptodate zu halten. Ob dies im Falle einer Umbuchung/Änderung der Reservation, also einem Modify, automatisch oder manuell vorgenommen wird, ist ein Prozedere, dass jedem Benutzer freigestellt ist.
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'
In diesem Bereich werden Systemmeldungen angezeigt. Diese erklären, was der Modify am Dossier ändern wird, 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 angezeigt.
Bereich 'Pendente Änderungen'
In diesem Bereich wird die Buchung angezeigt und es wird aufgeführt, welche Änderungen am Dossier vorgenommen werden, wenn der Modify akzeptiert wird. Die Daten sind hierarchisch strukturiert, es wird also immer zuerst die betroffene Dossierposition angedruckt, darunter die Leistung und ggf. die Flugsegmente. Elemente die durch den Modify gelöscht würden, werden rot hinterlegt. Elemente die durch den Modify neu eingefügt würden, werden grün hinterlegt. Elemente die durch den Modify geändert würden, werden grau hinterlegt. Elemente die nicht geändert werden, die aber zur besseren Übersicht der Struktur angezeigt werden, sind weiss hinterlegt.
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
Wird der Modify akzeptiert, werden die angezeigten Änderungen ins Dossier übernommen. In der Modify Logik wird beschrieben nach welchen Kriterien Datenelemente angepasst werden.
Einige typische Modify-Prozesse sind:
- EMD
- Unterschieden wird zwischen EMD-A und EMD-S. Details siehe EMD verarbeiten
- Exchange
- Die Umbuchung wird je nach Änderung von Hinflug oder Änderung von Rückflug unterschiedlich importiert. Details siehe Exchange verarbeiten
- 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, ebenso alle seine Leistungen. (Es gibt eine Ausnahme zu dieser Regel, nämlich falls der alte Tnr. noch mit Leistungen verknüpft ist die nicht Teil der Reservations sind, zB der Dossiergebühr)
- 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)
- Leistungsänderung/-umbuchung
- Wird eine Leistung umgebucht, ändern sich im Allgemeinen die Schlüsselfelder (siehe Anpassungen einzelner Datenelemente). Bei TO-Reservationen wird die alte Leistung gelöscht und die neue eingefügt.
- Statusänderung
- Wird eine Option bestätigt (oder annulliert), so wird der Status auf den entsprechenden Leistungen angepasst. Im Falle einer Annullation werden zudem die alten Preispositionen gelöscht und durch Preispositionen mit Betrag 0.00 ersetzt.
- Bestätigung Flugzeiten
- Arrangement (meistens Rundreisen Übersee) werden weit im voraus gebucht, da ist die Flugroute noch nicht genau bestätigt/bestimmt, es gibt mehrere Möglichkeiten. Irgendwann schickt TO dann die definitiven Flugnummern/Flugzeiten (von manchen TO's werden diese Informationen im Freitext geschickt)
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 identischer/m:
- Filiale-Zuordnung (basierend auf Agency ID)
- Origin (zB 'CETS')
falls Origin CETS:
- CETS Referenznummer (CETSRef)
sonst: (Orgin nicht CETS oder anhand der CETSRef keine Reservation gefunden)
- Reservations- oder Buchungsnummer
- 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.
Falls die Basis-Reservation noch nicht in einem Dossier verarbeitet ist, so wird diese durch den Modify ersetzt.
Die CETS Referenznummer wird auf der Reservation in das Feld ParentBFNumber geschrieben (im UI nicht sichtbar).
Leistungsreihenfolge
Wenn eine Leistung im Modify als neue Leistung erkannt wird, so wird diese nach dem Akzeptieren des Modify zuunterst eingefügt. Leistungen können manuell im Doceditor verschoben werden. Leistungsreihenfolge ändern
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). Es wird keine Übereinstimmung gefunden, daher wird eine komplett 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.
| CRS Buchung, zB Galileo | TO-Res. Buchung, zB CETS |
|---|---|
| Im Modify Preview wird angezeigt dass eine komplett neue Position eingefügt wird. Der Benutzer muss nach dem Akzeptieren des Modify die alte Position manuell löschen. Bei Leistungen, welche normalerweise mehrere Segmente enthalten (Flugleistung mit Flugsegmenten, Zugleistung mit Zugabschnitten) wird beim Modify nur das erste Segment des Modify mit dem ersten Segment der Originalbuchung verglichen. Dies erklärt das unterschiedliche Einfügen/Anpassen der Leistungen/Segmente, je nachdem ob der Hinflug oder der Rückflug umbgebucht wurde. weitere Details zu Flug- und Zugpositionen | Im Modify Preview wird angezeigt dass innerhalb des Arrangments eine neue Flugleistung eingefügt wird, und die alte Flugleistung gelöscht wird. Der Benutzer muss nach dem Akzeptieren des Modify nichts mehr machen. |
- 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.
| CRS Buchung, zB Galileo | TO-Res. Buchung, zB CETS |
|---|---|
| Im Modify Preview wird angezeigt dass das alte Flugsegment gelöscht wird, und ein neues Flugsegment eingefügt wird. | Im Modify Preview wird angezeigt dass das alte Flugsegment gelöscht wird, und ein neues Flugsegment eingefügt wird. |
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:
|
| Preisposition | Preispositionen haben nur zwei Felder, beides sind Schlüsselfelder:
|
| 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:
|
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
Details zu Flug- und Zugpositionen
Je nach System wird eine Reservation mit Flug- oder Zugleistungen und deren Segmenten unterschiedlich mitgeschickt.
- Airline-Systeme wie Galileo, Amadeus usw. schicken immer eine Flugleistung mit mehreren Segmenten (z.B. Hin- und Rückflug).
- TO-Systeme wie CETS, Touronline schicken eine Flugleistung mit jeweils nur einem Segment, also Flugleistung mit Segment Hinflug und Flugleistung mit Segment Rückflug. Dies, weil es sich um ganze Arrangments handelt bei denen meistens noch andere Leistungen (Hotel, Metrokarten usw.) mitgebucht werden.
Für die Anpassung der Datenelemente kann es von Bedeutung sein, wie die Leistungen und deren Segmente (Flug, Zug, Bus) in den Modifies mitgeschickt werden.
Zudem ist die Überprüfung des ersten Segments massgebend, also z.B. die Hinreise in einem Städtearrangement:
Hierzu ein Beispiel:
Originalbuchung:
Ein Arrangement mit Leistung Zug und Reiseabschnitt Hinfahrt und eine separate Leistung Zug mit Reiseabschnitt Rückfahrt ist gebucht. Beide Reisewege sind noch unbestimmt:
- Originalreservation:
- Leistung Zug
- Reiseabschnitt Hinreise: 20.07.2012 Schweiz - Paris
- Reiseabschnitt Rückreise: 23.07.2012 Paris - Schweiz
- Modify:
- Leistung Zug
- Reiseabschnitt Hinreise: 20.07.2012 Zürich - Paris-Gare de Lyon mit TGV 9000
- Reiseabschnitt Rückreise: 20.07.2012 Paris-Gare de Lyon - Zürich mit TGV 9001
Das erste Segment der Original Buchung hat den Abreiseort Schweiz, das erste Segment des Modify hat den Abreiseort Zürich, die Schlüsselfelder stimmen nicht überein und die Leistung wird NICHT angepasst. Die Leistung Zug des Modify wird mit den beiden Reiseabschnitten als komplett neue Leistung zuunterst eingefügt. Die alten Leistungen Schweiz - Paris - Schweiz werden 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
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 (Approval code)
Stimmen die Daten nicht mit der im Dossier existierenden Zahlung überein, wird eine neue Zahlung importiert. Enthält die Zahlung im Dossier eine Referenznummer und die Zahlung im Modify keine Referenznummer, wird in diesem Fall die Prüfung der Referenznummer ignoriert und es wird, sollten alle anderen Daten übereinstimmen, keine neue Zahlung importiert.
EMD's
Zusatzleistungen von Airlines, wie beispielsweise Umbuchungsgebühren, Gebühren für Übergepäck oder Sitzplatzreservationen (bei Air Berlin), werden über EMD's (Electronic Miscellaneous Documents) abgerechnet. Dabei gibt es zwei Arten von EMD's:
- EMD-A (associated): Wird für Leistungen verwendet, welche im direkten Zusammenhang mit der Flugposition stehen.
- EMD-S (stand alone): Kann für alle Arten von Gebühren verwendet werden.
Das EMD-A erscheint als Modify im Dossier. Beim Verarbeiten wird der im Dossier bereits bestehenden Flugposition ein neues Flugticket angefügt. Pro Flugticket wird ein Einkauf mit der Flugticketnummer importiert.
Auch das EMD-S erscheint als Modify im Dossier. Wird ein EMD-S verarbeitet, so wird eine komplett neue Dossierposition mit Leistungstyp 'Diverses' angefügt. Im Freitext wird die Original-Ticketnummer angedruckt. Der Einkauf und die Rechnungsnummer werden importiert.
Ein EMD kann in einem Dossier auch manuell angefügt werden. Siehe hierzu: Doceditor - Neu hinzufügen.
Exchange verarbeiten
Beim Verarbeiten von Exchanges ist massgebend, ob der Hin- oder der Rückflug umgebucht wurde. Wurde der Hinflug umgebucht, so wird eine komplett neue Flugposition mit dem neuen Flugticket importiert. Ebenso wird die Einkaufsposition mit der Flugticketnummer angefügt.
Betrifft die Umbuchung nicht das erste Flugsegment, so wird der bereits bestehenden Flugposition ein neues Flugticket angefügt. Die alten Flugsegmente werden gelöscht und die neuen Flugsegmente eingefügt. Es wird eine Einkaufsposition mit der Flugticketnummer angefügt. Beispiele siehe Flugumbuchungen.
Refund verarbeiten
Bei der Verarbeitung von Refunds kann PRO MANDANT entschieden werden, ob diese in Umbrella.net als Modify oder unabhängig behandelt werden sollen. Es ist eine einmalige Einstellung, die auf Wunsch durch den Support von Umbrella.net vorgenommen werden kann.
Wenn die Einstellung 'Behandle Refund als Modify' eingestellt ist, wird die Übermittlung wie folgt behandelt:
- Wenn das Original Ticket bereits in ein Dossier importiert wurde, wird der Refund als Modify dargestellt und erstellt im bestehenden Dossier eine neue Position
- Wenn das Original Ticket nicht in ein Dossier importiert wurde, kommt der Refund ohne Dossier Referenz auf die Importqueue
