Lokaler Webshop, Teil III

Die Auswahl der Artikel ist getätigt, der Warenkorb gefüllt, der Kassenvorgang abgeschlossen und eine Bestellbestätigung versandt worden. Welche Vorgänge nun noch für den in Access fingierten Webshop zu vollziehen sind, findet sich hier im letzten Beitrag zur Reihe. Vornehmlich hat der Vertrieb nun das Wort, damit die Ware zum Versand kommt.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1702_WebshopIII.zip.

Der Beitrag setzt die Serie aus den Ausgaben 08/2016 und 10/2016 fort.

Alte Bestellungen einsehen

Beim Öffnen des zentralen Shop-Formulars frmShop wird, wie früher bereits ausgeführt, aus einem Cookie die ID des Kunden ausgelesen, der den Shop zuletzt besuchte. Das übernimmt die vom Beim Laden-Ereignis (Form_Load) aufgerufene Funktion LoadTempVar:

LoadTempVar "KundeID"

Sie liest aus der Datei cookie.txt im Datenbankverzeichnis die beim letzten Schließen des Shops abgelegte ID, um sie in der TempVar “KundeID” zwischenzuspeichern. Diese ID steht forthin für die Dauer der Sitzung allen weiteren Operationen zur Verfügung.

Sie wirkt sich etwa aus, wenn in der rechten oberen Ecke des Shops der Button Meine Bestellungen… angeklickt wird. Der für das Click-Ereignis hinterlegte Code findet sich in Listing 1. Zunächst erfolgt hier eine Überprüfung, ob die TempVar überhaupt schon gefüllt ist, was genau dann nicht der Fall ist, wenn sich ein Kunde zum ersten Mal im Shop bewegt. Ihr Wert beträgt dann 0. In diesem Fall erscheint das Dialog-Formular für einen Login, das nach Beendigung die TempVar KundeID selbst setzt, falls die Aktion nicht abgebrochen wird.

Private Sub cmdBestellungen_Click()
     If TempVars("KundeID") = 0 Then
         DoCmd.OpenForm "frmLogin", , , , , acDialog
     Else
         If MsgBox("Neu einloggen", vbQuestion Or vbYesNo, sLogo) = vbYes Then
             DoCmd.OpenForm "frmLogin", , , , , acDialog
         End If
     End If
     If TempVars("KundeID") = 0 Then Exit Sub
     ShowKunde
     DoCmd.OpenForm "frmBestellungen", , , "KundeID=" & TempVars("KundeID")
Private Sub ShowKunde()
     Dim sKunde As String
     
     sKunde = DLookup("[Vorname] & ' ' & [Nachname]", _
         "tblKunden", "ID=" & TempVars("KundeID"))
     Me!LblKunde.Caption = "Hallo, " & sKunde
     Me!LblKunde.Visible = True
End Sub

Listing 1: Aufruf der getätigten Bestellungen über den Button cmdBestellungen

Andernfalls kommt es zur Nachfrage nach einem neuen Login. Das könnte dann Sinn machen, falls der Kunde sich mit einer anderen E-Mail-Adresse anmelden möchte.

Wie auch immer: Nach dem Schließen der Dialoge kann KundeID immer noch den Wert 0 besitzen, worauf die Routine sang- und klanglos verlassen wird. Sonst aber öffnet sich das Formular für die Bestellungen. Zuvor allerdings wird noch ein Label im Shop-Formular über die Prozedur ShowKunde mit dem Namen des Users beschrieben, wofür eine DLookup-Funktion zum Einsatz kommt (siehe Bild 1).

Bild 1: Im Kopf des Shop-Forumlar frmShop blendet sich eine Begrüßungformel mit dem Namen des Kunden ein

Das über die OpenForm-Anweisung geladene Bestellungen-Formular frmBestellungen wird gleich im Aufruf über den optionalen Parameter WhereCondition nach der ID des Kunden gefiltert. Die Datenbasis für dieses Formular ist direkt die Tabelle tblBestellungen.

Allerdings spielt dies nur eine untergeordnete Rolle, denn das Formular selbst zeigt gar keine Daten an. Dies übernimmt ein im Detailbereich eingebetteter Unterbericht mit der Herkunft rptBestellungen in Berichtsansicht (siehe Bild 2).

Bild 2: Die Entwurfsansicht des Berichts zur Einsicht in die getätigte Bestellungen

Lediglich die Verknüpfung von Formularfeld KundeID zum Berichtsfeld KundeID ist vorzunehmen. Natürlich hätte man statt des Berichts auch ein Unterformular verwenden können, doch ersterer gestattet mehr Gestaltungsspielraum. Schließlich geht es hier nur um die passive Darstellung von Daten, wofür ein Bericht in der Regel die erste Wahl ist.

Der Bericht enthält im Detailbereich die Felder für die Artikelnummer (ArtNr), das Produkt, die Anzahl und den Bruttopreis einer Bestellposition. Das alles wird jedoch nach der Bestellung über deren Merkmal BestellID gruppiert, wie der Gruppen-Dialog des Berichts in Bild 3 zeigt.

Bild 3: Der im Entwurf des Berichts unten eingeblendete Gruppen-Dialog

Außerdem sortieren dessen Einstellungen noch die Bestellungen nach dem Bestelldatum (BestellDat). Im Fußbereich wird zu jeder Bestellung noch die Gesamtsumme über den hinterlegten Ausdruck Summe([Brutto]) ausgegeben.

Im Ergebnis finden wir also alle Bestellungen des eingeloggten Kunden in der Reihenfolge der Bestellungen nach Datum absteigend angezeigt.

In Bild 4 finden Sie die Bestellhistorie mit dem Bericht im Formular dargestellt. Sowohl Bericht, wie auch Formular, kommen ohne jeglichen VBA-Code aus. Lediglich die Schaltfläche zum Schließen des Formulars (Zurück zum Shop) ist mit einer Close-Anweisung hinterlegt.

Bild 4: Das Formular frmBestellungen zeigt alle Bestellungen im Überblick

Selbstverständlich sind alle Felder des Berichts schreibgeschützt. Der Status einer Bestellung steht in einem Kombinationsfeld auf Basis der Tabelle tblBearbeitungsStati, gebunden an das Datenfeld IDStatus.

Nach Abschluss des Kassenvorgangs hat der Shop hier automatisch den Wert 1 für Bestellung aufgegeben eingesetzt. Die Aufgabe des Vertriebs ist es dann, diesen Wert zu ändern.

Bestellbestätigung

Bevor wir zu diesen Vorgängen kommen, fehlt noch der Bestätigungsbericht rptBestaetigung, der nach Abschluss der Bestellung per Outlook an den Kunden versandt wurde (siehe Bild 5).

Bild 5: Der Bericht zur Bestellbestätigung per E-Mail

Sein Entwurf (siehe Bild 6) ähnelt mit den Gruppierungsebenen im Prinzip jedem des Berichts für die Bestellhistorie, doch hier kommt zusätzlich noch die Kundenadresse ins Spiel, die im Seitenkopf ihren Platz findet.

Bild 6: Der Aufbau des Bestätigungsberichts gleicht dem der Bestellhistorie

Die Datenherkunft des Berichts (Abfrage qry_Kundenbestellung) kommt entsprechend komplexer daher. Bild 7 zeigt die Abfrage mit ihren vier verknüpften Tabellen. Genaugenommen sind es nur drei, denn die Adresse des Kunden kommt selbst aus einer Abfrage qry_Kundenadressen, welche die Aufgabe hat, aus Namen, Strasse PLZ und Ort den kompletten Adressblock per String-Verkettung zu bilden.

Bild 7: Die Datenherkunfsabfrage für den Bestätigungsbericht benötigt eine weitere Abfrage qry_Kundenadressen

Benutzername oder E-Mail-Adresse: