Kategorie:Fulfillment: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „Mit Fulfillment werden IBE-basierte Buchungen automatisch in Umbrella.net übernommen, zusammen mit den assozierten Kundendaten. Grundvoraussetzung ist dass di…“) |
|||
| Zeile 1: | Zeile 1: | ||
| − | Mit Fulfillment werden IBE-basierte Buchungen automatisch in Umbrella.net übernommen, zusammen mit den assozierten Kundendaten. Grundvoraussetzung ist dass die IBE einen Kundenrecord (MPSXML oder | + | Mit Fulfillment werden IBE-basierte Buchungen automatisch in Umbrella.net übernommen, zusammen mit den assozierten Kundendaten. Grundvoraussetzung ist dass die IBE einen Kundenrecord (MPSXML ([http://www.http://www.onlinetravel.ch/ Online Travel]) oder Midoco ([http://www.midoco.de Traveltainment])) sowie einen Buchungsrecord in einem bekannten Format schickt. |
== Kosten / Abhängigkeiten des Moduls {{PAGENAME}} == | == Kosten / Abhängigkeiten des Moduls {{PAGENAME}} == | ||
| Zeile 6: | Zeile 6: | ||
== Konzept der {{PAGENAME}} == | == Konzept der {{PAGENAME}} == | ||
| + | |||
| + | [[Image:fulfillment_prozess.png|thumb|right|Fulfillment-Prozess]] | ||
| + | |||
| + | Der Kunden-Datensatz enthält eine Quell-ID (auch "Cooperation ID"), anhand deren Umbrella.net die [[Buchungsquellen|Buchungsquelle]] bestimmt. Diese Buchungsquelle legt einige Default-Werte für zu erstellende Dossier fest. Mit dem Kunden-Datensatz wird in einem ersten Schritt ([[#Kundenverarbeitung]]) ein Kunde angelegt bzw. ein existierender Kunde aktualisiert. Anschliessend wird automatisch ein Dossier erstellt ([[#Dossierverarbeitung]]). Sobald eine Reservation mit passender Buchungsnummer bei Umbrella.net eintrifft wird diese automatisch in das neu erstellte Dossier importiert. Der Benutzer wird über all diese Schritte mit entsprechenden Agendaeinträge informiert. | ||
| + | |||
| + | == Kundenverarbeitung == | ||
| + | |||
| + | Kunden werden anhand der E-Mail Adresse gesucht. Wird so kein Kunde gefunden, so wird ein neuer Kunde angelegt. Wenn auf der Einstellung der [[Buchungsquellen|Buchungsquelle]] nicht anderst vermerkt, werden die Default-Einstellungen von derjenigen Filiale übernommen, welche auf der entsprechenden [[Buchungsquellen|Buchungsquelle]] hinterlegt ist. | ||
| + | |||
| + | <module name="Kuoni">Für Kuoni werden Kunden nicht anhand der E-Mail Adresse gesucht, sondern anhand der (exakten) Adresse</module> | ||
| + | |||
| + | Es werden immer (auch bei einem schon existierenden Kunden) sämtliche Daten aus den Kunden-Datensatz auch den Kunden in Umbrella.net geschrieben: | ||
| + | |||
| + | * Anrede und Namen | ||
| + | * Adressdaten | ||
| + | * Telefonnummern | ||
| + | * Geburtsdatum | ||
| + | |||
| + | |||
| + | <module name="Kuoni"> | ||
| + | == Kundenkreditkarten bei Buchungen aus Traveltainment == | ||
| + | |||
| + | Wird eine Buchung via Traveltainment getätigt (Alternative heute ist nur noch OLT), so enthält der MPSXML IMIR einen "TT Payment-Token". Anhand dieses Token können die CC-Daten bei Traveltainment abgefragt werden. Es gelten folgende Verarbeitungsschritte: | ||
| + | |||
| + | * Für Neukunden wird die vom Kunden eingegebene Kreditkartennummer mit dem Aliasing von Datatrans verschlüsselt und auf dem Kunden gespeichert. | ||
| + | * Für bestehende Kunden wird die Kreditkarte nur dann gespeichert, wenn auf dem Kunden noch keine Kreditkarte mit exakt diesem Aliasing und identischem Ablaufdatum besteht. | ||
| + | * Die Zahlungsform des Neukunden resp. bestehenden Kunden wird auf 'Creditcard/Debitcard' gesetzt. | ||
| + | * Die eingegebene Kreditkarten werden in jedem Fall als Hauptkreditkarte gesetzt. | ||
| + | * Wenn während dem Prozess ein Fehler auftritt, so wird automatisch ein Agendaeintrag mit Priorität hoch kreiert mit dem Vermerkt, dass die Kundenkreditkarte nicht auf dem Kunden gespeichert werden konnte. | ||
| + | </module> | ||
| + | |||
| + | == Dossierverarbeitung == | ||
| + | |||
| + | Wurde der Kunden-Datensatz verarbeitet, wird automatisch ein [[Dossier]] erstellt. Es werden dabei die Default-Einstellungen von derjenigen Filiale übernommen welche auf der entsprechenden [[Buchungsquellen|Buchungsquelle]] hinterlegt ist. | ||
| + | |||
| + | * [[Geschäftsbereiche | Geschäftsbereich]] | ||
| + | <release since="3.02"> | ||
| + | * [[Dossierkategorien | Dossierkategorie]] | ||
| + | </release> | ||
| + | * [[Zahlungskondition]] (falls auf der [[Filiale]] 'Rechnung automatisch erstellen' gesetzt ist) | ||
| + | * Der [[Saleschannels | Saleschannel]] wird aus den MIR-Daten übernommen, wobei der 'Externe Code' auf dem Saleschannel übereinstimmen muss mit | ||
| + | ** MPSXML: /travelplan/systemOrder/@SalesChannel | ||
| + | ** Midoco: n/a | ||
| + | |||
| + | Dem Dossier wird eine "Autoimport BF Nummer" aus dem Kunden-Datensatz vergeben. | ||
| + | |||
| + | Wird eine Reservation mit der "Autoimport BF Nummer" an Umbrella.net geschickt, so wird diese direkt in das zuvor erstellte Dossier importiert. | ||
| + | |||
| + | == "Referenz auf Kunde / Dossier erstellen" == | ||
| + | |||
| + | Fulfillment-Filialen können wahlweise "ihre eigenen Daten" gegenüber den anderen Filiale abschotten. Durch Aktivieren des Feldes "Referenz auf Kunde / Dossier erstellen" auf der [[Buchungsquellen|Buchungsquelle]] wird dem Kunden sowie dem Dossier die verwendete Buchungsquelle mitgegeben. Dieser Kunde / dieses Dossier kann dann nur von Mitarbeiter in der entsprechenden Fulfillment-Filialen geladen werden. | ||
| + | |||
| + | Sollen Fulfillment-Kunden und -Dossier dem gesamten Mandanten zur Verfügung stehen, muss "Referenz auf Kunde / Dossier erstellen" deaktiviert werden. | ||
| + | |||
| + | = Dynamix = | ||
| + | <module name="Kuoni"> | ||
| + | |||
| + | [[Image:dynamix_birt_processing.png|thumb|right|Ablauf BIRT Verarbeitung]] | ||
| + | |||
| + | Die Verarbeitung von XHT-Daten in Umbrella.net basiert auf Fulfillment, hat jedoch einige zusätzliche Regeln. XHT-Buchungen werden von Traveltainment in der Form von BIRT-Datensätzen geschickt. Es gibt dabei eine Resale-Sicht (shopping cart) und eine Tour-Operator Sicht. Flüge und Hotels werden als Komponenten bezeichnet, zusätzliche Leistungen wie Transfers oder Versicherungen als "Add ons". | ||
| + | |||
| + | Der Ablauf der Verarbeitung ist: | ||
| + | |||
| + | # Zuerst wird der MPSXML verarbeitet, dieser generiert ein Dossier. Allfällig schon importierte BIRTs werden zurückgehalten. | ||
| + | #* 'Autoimport BF Nummer' entspricht der internen Buchungs-ID | ||
| + | # Anschliessend wird der Retail BIRT (Shoppingcart) verarbeitet. Dieser erstellt die Arrangement-Position. Allfällig schon importierte Komponeten- oder Addon-BIRTs werden zurückgehalten. | ||
| + | # Die restlichen BIRTs werden verarbeitet: | ||
| + | ## Addons erzeugen zusätzliche, neue Dossierpositionen | ||
| + | ## Komponenten erstellen Einkäufe und passen ggf. die Verkaufsposition leicht an | ||
| + | |||
| + | Die Logik zum Zurückhalten der Komponenten/Addons ist: | ||
| + | * Gibt es eine Reservation mit Origin 'Dynamix' welche einer packaged Position zugeordnet ist | ||
| + | |||
| + | == Packaged position / Add-ons == | ||
| + | |||
| + | Komponenten werden als einzelne Leistungen in einem Arrangement verpackt. Um spätere Modifies einzelner Leistungen zu unterstützen wird die [[:Kategorie:Package Builder]] Logik verwendet. | ||
| + | |||
| + | Add ons hingegen werden als einzelne, zusätzliche Positionen abgebildet. | ||
| + | |||
| + | == Einkäufe == | ||
| + | |||
| + | Beim XHT Import wird ein Einkauf pro Komponente bzw. pro Add-on erstellt. Ggf. führt später ein Ticketing-Modify dazu dass der Einkauf der Flugkomponente in mehrere Einkäufe - je 1 Einkauf pro Ticket - aufgeteilt wird. | ||
| + | |||
| + | |||
| + | == Automatische Modfikationen von Dynamix Buchungen == | ||
| + | |||
| + | [[Image:dynamix_modify_amadeus.png|thumb|right|Beispiel Modify Amadeus]] | ||
| + | |||
| + | Dynamix Buchungen können durch Änderung der entsprechenden Komponenten in CETS oder Amadeus modifiziert werden. Dabei gelangt der [[Modify Preview | Standard-Modify-Prozess von Umbrella.net]] zur Anwendung. Im Unterschied zur Standard-Modfiy-Funktion, werden auf Dynamix basierenden Buchungen | ||
| + | |||
| + | * Verkaufspreise werden nie angepasst (also auch nicht neue Preise eingefügt oder obsolete Preispositionen gelöscht) | ||
| + | * Positionstitel werden nie angepasst | ||
| + | |||
| + | == Produkte und Einkaufspreise == | ||
| + | |||
| + | Die Produkte werden aufgrund des Names von Komponentenlieferanten zugewiesen. Der Einkaufspreis wird aufgrund der Marge, die auf dem Produkt erfasst wird, berechnet. | ||
| + | |||
| + | == E-Docs in Dossiers == | ||
| + | |||
| + | E-Docs, welche von Lieferanten per E-Mail gesandt werden, können in einigen Fällen automatisch mit dem Umbrella.net-Dossier verlinkt werden. Die korrekte Zuweisung bedingt, dass die Buchungsnummer (Process-Number) im E-Mail enthalten ist. Stand Dezember 2012 dürfte diese Funktion mit folgenden Lieferanten zur Verfügung stehen: | ||
| + | * "Komet" | ||
| + | * FTI | ||
| + | * SLR (Schauinsland) | ||
| + | |||
| + | |||
| + | </module> | ||
| + | |||
| + | = Technische/Funktionale Details = | ||
| + | |||
| + | == Ablauf B2B-Verarbeitung == | ||
| + | |||
| + | == Reservation Matching == | ||
| + | |||
| + | Es kann im Fulfillment-Prozess vorkommen dass Reservationsrecords zur identischen Buchung aus verschiedenen Datenquellen an Umbrella.net geschickt werden. Dabei zeigt sich dass je nach Datenquelle die BF Nummer leicht unterschiedlich sein kann, zB 18484927 vs. 018484927. Dieser Effekt ist bisher nur für CETS-Buchungen bekannt. Es wird dehalb eine Matching-Heuristik definiert, anhand welcher eine einkommende Reservation mit schon importierten Reservationen verglichen wird: | ||
| + | |||
| + | * Origin muss CETS sein | ||
| + | * Die BF-Nummer must mindestens 6 Zeichen enthalten (bei kürzeren BF Nummern ist die Wahrscheinlichkeit eines 'false positive' zu hoch) | ||
| + | * Filiale und Vendor-Code müssen übereinstimmen | ||
| + | * Von den beiden BF-Nummern welche verglichen werden muss die ein die andere als Suffix enthalten | ||
Version vom 12. April 2013, 11:12 Uhr
Mit Fulfillment werden IBE-basierte Buchungen automatisch in Umbrella.net übernommen, zusammen mit den assozierten Kundendaten. Grundvoraussetzung ist dass die IBE einen Kundenrecord (MPSXML (Online Travel) oder Midoco (Traveltainment)) sowie einen Buchungsrecord in einem bekannten Format schickt.
Inhaltsverzeichnis
Kosten / Abhängigkeiten des Moduls Fulfillment
- Dieses Modul ist kostenpflichtig
Konzept der Fulfillment
Der Kunden-Datensatz enthält eine Quell-ID (auch "Cooperation ID"), anhand deren Umbrella.net die Buchungsquelle bestimmt. Diese Buchungsquelle legt einige Default-Werte für zu erstellende Dossier fest. Mit dem Kunden-Datensatz wird in einem ersten Schritt (#Kundenverarbeitung) ein Kunde angelegt bzw. ein existierender Kunde aktualisiert. Anschliessend wird automatisch ein Dossier erstellt (#Dossierverarbeitung). Sobald eine Reservation mit passender Buchungsnummer bei Umbrella.net eintrifft wird diese automatisch in das neu erstellte Dossier importiert. Der Benutzer wird über all diese Schritte mit entsprechenden Agendaeinträge informiert.
Kundenverarbeitung
Kunden werden anhand der E-Mail Adresse gesucht. Wird so kein Kunde gefunden, so wird ein neuer Kunde angelegt. Wenn auf der Einstellung der Buchungsquelle nicht anderst vermerkt, werden die Default-Einstellungen von derjenigen Filiale übernommen, welche auf der entsprechenden Buchungsquelle hinterlegt ist.
Es werden immer (auch bei einem schon existierenden Kunden) sämtliche Daten aus den Kunden-Datensatz auch den Kunden in Umbrella.net geschrieben:
- Anrede und Namen
- Adressdaten
- Telefonnummern
- Geburtsdatum
Dossierverarbeitung
Wurde der Kunden-Datensatz verarbeitet, wird automatisch ein Dossier erstellt. Es werden dabei die Default-Einstellungen von derjenigen Filiale übernommen welche auf der entsprechenden Buchungsquelle hinterlegt ist.
- Zahlungskondition (falls auf der Filiale 'Rechnung automatisch erstellen' gesetzt ist)
- Der Saleschannel wird aus den MIR-Daten übernommen, wobei der 'Externe Code' auf dem Saleschannel übereinstimmen muss mit
- MPSXML: /travelplan/systemOrder/@SalesChannel
- Midoco: n/a
Dem Dossier wird eine "Autoimport BF Nummer" aus dem Kunden-Datensatz vergeben.
Wird eine Reservation mit der "Autoimport BF Nummer" an Umbrella.net geschickt, so wird diese direkt in das zuvor erstellte Dossier importiert.
"Referenz auf Kunde / Dossier erstellen"
Fulfillment-Filialen können wahlweise "ihre eigenen Daten" gegenüber den anderen Filiale abschotten. Durch Aktivieren des Feldes "Referenz auf Kunde / Dossier erstellen" auf der Buchungsquelle wird dem Kunden sowie dem Dossier die verwendete Buchungsquelle mitgegeben. Dieser Kunde / dieses Dossier kann dann nur von Mitarbeiter in der entsprechenden Fulfillment-Filialen geladen werden.
Sollen Fulfillment-Kunden und -Dossier dem gesamten Mandanten zur Verfügung stehen, muss "Referenz auf Kunde / Dossier erstellen" deaktiviert werden.
Dynamix
Technische/Funktionale Details
Ablauf B2B-Verarbeitung
Reservation Matching
Es kann im Fulfillment-Prozess vorkommen dass Reservationsrecords zur identischen Buchung aus verschiedenen Datenquellen an Umbrella.net geschickt werden. Dabei zeigt sich dass je nach Datenquelle die BF Nummer leicht unterschiedlich sein kann, zB 18484927 vs. 018484927. Dieser Effekt ist bisher nur für CETS-Buchungen bekannt. Es wird dehalb eine Matching-Heuristik definiert, anhand welcher eine einkommende Reservation mit schon importierten Reservationen verglichen wird:
- Origin muss CETS sein
- Die BF-Nummer must mindestens 6 Zeichen enthalten (bei kürzeren BF Nummern ist die Wahrscheinlichkeit eines 'false positive' zu hoch)
- Filiale und Vendor-Code müssen übereinstimmen
- Von den beiden BF-Nummern welche verglichen werden muss die ein die andere als Suffix enthalten
Seiten in der Kategorie «Fulfillment»
Folgende 2 Seiten sind in dieser Kategorie, von 2 insgesamt.
