Ticketsystem, Teil 1

Wenn Sie ein Abonnement des Magazins 'Access im Unternehmen' besitzen, können Sie sich anmelden und den kompletten Artikel lesen.
Anderenfalls können Sie das Abonnement hier im Shop erwerben.

Ticketsystem, Teil 1

Wer Access-Anwendungen entwickelt, erledigt dies in der Regel für seine Kunden oder Benutzer. Ob es nun einer, wenige oder viele Benutzer sind: Früher oder später meldet sich der eine oder andere mit Fehlermeldungen oder Verbesserungswünschen. Davon ausgehend, dass Sie diese auch berücksichtigen möchten, ist hier ein funktionierendes System zur Erfassung und Abarbeitung der Anforderungen gefragt, gegebenenfalls auch für mehrere Benutzer. Wir gehen in diesem Fall von einer reinen E-Mail-Schnittstelle aus und wollen dazu Microsoft Outlook nutzen.

Aufgaben des Ticketsystems

Das Ticketsystem soll eine ganze Reihe von Aufgaben erleichtern. Die erste Aufgabe ist, die per E-Mail eingehenden Anfragen halbautomatisch zu erfassen. Halbautomatisch deshalb, weil eine vollautomatische Erfassung voraussetzen würde, dass alle derartigen Anfragen zumindest an eine eigens dafür vorgesehene E-Mail-Adresse gerichtet sind – was nicht unbedingt immer der Fall ist, wie etwa beim Autor dieser Zeilen.

E-Mails, die eine Anfrage enthalten, die mit dem Ticket-System verarbeitet werden soll, soll der Benutzer in Outlook in einen speziell dafür vorgesehenen Outlook-Ordner verschieben. Diesen statten wir natürlich per VBA-Code so aus, dass die E-Mail dann automatisch weiterverarbeitet wird und in der Datenbank des Ticketsystems landet.

E-Mails, die Bedingungen erfüllen, die auf eine Support-Anfrage hindeuten, können natürlich automatisch per Outlook-Regel erfasst und in den dafür vorgesehenen Outlook-Ordner verschoben werden, von wo aus die Mail wie oben beschrieben weiterverarbeitet wird.

Wenn eine E-Mail in Form eines Tickets im Ticketsystem angelegt wurde, sollen verschiedene Schritte erfolgen: Zum Beispiel muss die E-Mail so ausgewertet werden, dass sich ein Kunde daraus ableiten lässt. Die Kunden speichert das Ticketsystem in einer eigenen Tabelle, wobei wir uns hier auf die Daten Anrede, Vorname und Nachname beschränken wollen – und natürlich die E-Mail-Adresse. Hier wird es interessant, denn ein Kunde kann durchaus mehr als eine E-Mail-Adresse verwenden. Also müssen wir die E-Mail-Adressen separat in einer eigenen Tabelle verwalten.

Sobald einmal ein Kundendatensatz für eine E-Mail-Adresse angelegt wurde, sollen eingehende E-Mails mit dieser Absenderadresse automatisch dem Kunden zugeordnet werden.

Bei der Bearbeitung eines Tickets können verschiedene Aufgaben anfallen:

  • das Erstellen einer Notiz,
  • das Erstellen einer Aufgabe oder
  • das Beantworten der E-Mail.

Notizen haben lediglich informativen Charakter und sollen dafür sorgen, dass Informationen nicht verloren gehen. Aufgaben sollen sortiert und bearbeitet werden können, damit man sieht, welche Teilschritte zum Fertigstellen eines Tickets nötig und welche bereits erledigt sind. E-Mail-Antworten enthalten beispielsweise Rückfragen oder aber die Mitteilung, ob und wie das Problem gelöst werden konnte. Die jeweils erste Antwort zu einem Ticket soll im Betreff mit einer eindeutigen ID ausgestattet werden, die der Kunde in seiner Antwort weiterverwenden soll. Auf diese Weise braucht man nicht mehr die E-Mail-Adresse der Antworten heranzuziehen, um die Antwort zuzuordnen, sondern kann diese direkt dem Ticket zuweisen.

Um auch dem Autor dieses Beitrags den Alltag zu erleichtern, wollen wir für die Antworten auf die Kundenanfragen auch einige Textbausteine vorsehen, die häufiger vorkommende Anfragen beantworten. Diese Textbausteine sollen natürlich mit Platzhaltern versehen und mit den Daten des Kunden gefüllt werden.

Und wenn Sie schon Kundenanfragen annehmen und diese mit einem Ticketsystem verwalten wollen, können Sie auch gleich die Reaktionszeiten tracken und entsprechende Statistiken ausgeben lassen.

Den Rahmen eines einzigen Beitrags sprengt diese Lösung bei Weitem, daher finden Sie die einzelnen Elemente auf verschiedene Beiträge aufgeteilt. Wir verweisen von diesem Hauptbeitrag aus auf weiterführende Beiträge.

E-Mails und Tickets

Den Ausgangspunkt für ein Ticket bildet eine E-Mail-Anfrage (diese kann beispielsweise direkt per Mail oder auch über ein Kontaktformular erstellt worden sein – wichtig ist, dass diese als E-Mail in Outlook eingeht und dort im entsprechenden Ordner für die Verarbeitung von E-Mail-Anfragen landet).

Die E-Mail-Anfrage liefert uns einige Daten: die Absender-E-Mail-Adresse, gegebenenfalls den Vor- und den Nachnamen des Kunden sowie einen Text, der die Beschreibung des Problems enthält. Aus diesen Informationen möchten wir folgende Aktionen ableiten:

  • Erstellen eines Kundendatensatzes, sofern dieser noch nicht vorhanden ist, oder
  • Auswählen des Kundendatensatzes, welcher der E-Mail-Adresse des Absenders zugeordnet werden kann,
  • Anlegen eines Tickets als neuen Datensatz in einer Ticket-Tabelle – inklusive Verweis auf die Ursprungs-E-Mail, den Kundendatensatz sowie mit einer Bezeichnung und dem Inhalt des Tickets.

Datenmodell

Das Datenmodell sieht bis hierher wie in Bild 1 aus. Die Tabelle tblKunden ist über das Feld AnredeID mit der Tabelle tblAnreden verknüpft. Jedem Kunden können beliebig viele E-Mail-Adressen zugeordnet werden, also gibt es eine Tabelle namens tblEMailAdressen, die über das Fremdschlüsselfeld KundeID mit der Tabelle tblKunden verknüpft ist.

Datenmodell für den ersten Teil der Beitragsreihe

Bild 1: Datenmodell für den ersten Teil der Beitragsreihe

Zu jedem Kunden kann es natürlich auch beliebig viele Tickets geben. Daher ist die Tabelle tblTickets ebenfalls über ein Fremdschlüsselfeld, wieder namens KundeID, mit der Tabelle tblKunden verknüpft.

Diese Tabelle enthält neben dem Primärschlüsselfeld und dem Fremdschlüsselfeld KundeID noch folgende weitere Felder:

  • Ticketbezeichnung: Nimmt die Bezeichnung des Tickets auf.
  • Ticketinhalt: Ist ein Memofeld mit Formatierung Rich-Text, um den Inhalt des Tickets zu beschreiben.
  • AngelegtAm: Datum, an dem das Ticket angelegt wurde.
  • ErledigtAm: Datum, an dem das Ticket abgeschlossen wurde.
  • MailItemID: Fremdschlüsselfeld zu einem Eintrag der Tabelle tblMailItems. Speichert den Bezug zu der E-Mail, auf deren Basis das Ticket entstanden ist.

Die Tabelle tblMailItems kennen Sie vielleicht bereits: Wir haben diese im Beitrag Outlook-Mails nach Empfang archivieren (www.access-im-unternehmen.de/1007) vorgestellt. Wir werden auch die dort erläuterten Techniken zum halbautomatischen Einlesen von E-Mails in diese Tabelle in abgewandelter Form verwenden.

Fehlt noch die Tabelle tblNotizen, die wir in diesem Teil noch nicht erläutern werden, aber die zum Speichern von Notizen zum jeweiligen Ticket verwendet wird. Im Beitrag HTML-Liste mit Access-Daten (www.access-im-unternehmen.de/1029) erfahren Sie schon einmal, wie die Notizen später dargestellt werden sollen.

Kunden und E-Mail-Adressen

Wir schauen uns zuerst das Formular an, mit dem wir die Kunden und deren E-Mail-Adressen verwalten. Dieses sieht im Entwurf wie in Bild 2 aus und verwendet die Tabelle tblKunden als Datenherkunft. Da das Formular nur jeweils einen Datensatz zum Bearbeiten anzeigen soll beziehungsweise zum Anlegen eines neuen Kunden verwendet werden soll, stellen Sie die Eigenschaften Datensatzmarkierer, Navigationsschaltflächen, Trennlinien und Bildlaufleisten auf den Wert Nein ein. Außerdem erhält Automatisch zentrieren den Wert Ja.

Entwurf des Formulars frmKundeDetail

Bild 2: Entwurf des Formulars frmKundeDetail

Die E-Mail-Adressen zum jeweiligen Kunden steuert das Unterformular sfmEMailAdressen bei. Als Datenherkunft dient hier die Tabelle tblEMailAdressen. Das Formular soll seine Daten in der Datenblattansicht darstellen, also verwenden Sie für die Eigenschaft Standardansicht den Wert Datenblatt.

Wenn Sie das Unterformular sfmEMailAdressen aus dem Navigationsbereich in den Entwurf des Hauptformulars frmKundeDetail ziehen, sollte Access die Eigenschaften Verknüpfen von und Verknüpfen nach des Unterformular-Steuerelements automatisch jeweils auf den Wert KundeID einstellen – falls nicht, holen Sie dies manuell nach.

Beim Öffnen der Kundendetails

Das Formular frmKundeDetails soll entweder zum Anlegen eines neuen Datensatzes oder zum Bearbeiten eines vorhandenen Datensatzes geöffnet werden.

Im Falle des Anlegens sollen gleich ein paar Standardwerte gesetzt werden; außerdem gehen wir hier davon aus, dass der Benutzer gleich die E-Mail-Adresse des zu erstellenden Benutzers übergibt – und zwar mit OpenArgs-Parameter.

Der Aufruf würde dann etwa so aussehen:

DoCmd.OpenForm "frmKundeDetail", DataMode:=acFormAdd, OpenArgs:="andre@minhorst.com"

Das Formular sollte sich dann wie in Bild 3 präsentieren: Die übergebene E-Mail-Adresse ist bereits im Unterformular eingestellt, die Anrede ist mit Herr vorbelegt, das Kombinationsfeld aber für eine mögliche Änderung bereits geöffnet.

Das Formular frmKundeDetail beim Anlegen eines neuen Kunden

Bild 3: Das Formular frmKundeDetail beim Anlegen eines neuen Kunden

Damit dies geschieht, sind ein paar Zeilen Code notwendig. Diese finden Sie in Listing 1. Die dortige Prozedur wird durch das Ereignis Beim Laden des Formulars ausgelöst. Die Prozedur prüft zunächst anhand der nicht dokumentierten Eigenschaft DefaultEditing, in welchem Modus das Formular geöffnet wurde, also mit welchem Wert für den Parameter DataMode der OpenForm-Methode. Hat diese Eigenschaft den Wert 1, wurde die Konstante acFormAdd verwendet, das Formular soll also zum Hinzufügen eines neuen Datensatzes genutzt werden.

Dies war die Leseprobe dieses Artikels.
Melden Sie sich an, um auf den vollständigen Artikel zuzugreifen.

Bitte geben Sie die Zeichenfolge in das nachfolgende Textfeld ein

Die mit einem * markierten Felder sind Pflichtfelder.

Ich habe die Datenschutzbestimmungen zur Kenntnis genommen.