Home > Artikel > Ausgabe 2/2017 > Lokaler Webshop, Teil III

Lokaler Webshop, Teil III

Achtung: Sie sind nicht angemeldet. Wenn Sie Abonnent sind und sich anmelden, lesen Sie den kompletten Artikel, laden das PDF herunter oder probieren die Beispieldatenbank aus (sofern vorhanden).

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

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

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

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

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.

Der im Entwurf des Berichts unten eingeblendete Gruppen-Dialog

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.

Das Formular frmBestellungen zeigt alle Bestellungen im Überblick

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

Der Bericht zur Bestellbestätigung per E-Mail

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.

Der Aufbau des Bestätigungsberichts gleicht dem der Bestellhistorie

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.

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

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

Übersichtlicher als im Abfrageeditor lässt sich diese Abfrage in der SQL-Ansicht anlegen (siehe Listing 2).

SELECT

tblKunden.ID AS KID, [tblAnreden].[Anrede] & " " & [tblKunden].[Vorname] & " " & [tblKunden].[Nachname] & Chr$(13) & Chr$(10)

& [tblKunden].[Strasse] & " " & [tblKunden].[NrStrasse] & Chr$(13) & Chr$(10) & [tblKunden].[PLZ] & " " & [tblOrte].[Ort]

AS Adresse, tblKunden.Email FROM tblOrte INNER JOIN (tblAnreden INNER JOIN tblKunden ON tblAnreden.ID = tblKunden.IDAnrede)

ON tblOrte.ID = tblKunden.IDOrt;

Listing 2: Die Abfrage qry_Kundenadressen in der SQL-Ansicht

Ohne Filterung würde dieser Bericht dann alle Bestellungen aller Kunden ausgeben. Damit nur genau eine Bestellung zur Bestätigung kommt, ist der Filter gleich in das Open-Ereignis integriert, der einzigen Code-Zeile des Berichts:

Private Sub Report_Open(Cancel As Integer)

     Me.Filter = "BestellID=" & BestID

     Me.FilterOn = True

End Sub

Die BestellID wird mit dem Wert verglichen, der in der globalen Variablen BestID steht. Dieser Wert wurde nämlich beim Abschluss der Bestellung zugewiesen. Die Filterung im Open-Ereignis ist deshalb nötig, weil der Bericht über die Anweisung SendObject als E-Mail versandt wird.

Bearbeitung der Bestellung

Im Vertrieb werden die eingegangenen Bestellungen bearbeitet. Wir können hier kein komplettes Warenwirtschaftssystem abbilden. Unser Bearbeitungsformular frmVertrieb ist deshalb ziemlich einfach gestrickt und zeigt einfach zu jedem Kunden dessen Bestellungen an (siehe Bild 8).

Der Vertrieb arbeitet die eingehenden Bestellungen über dieses Formular ab

Bild 8: Der Vertrieb arbeitet die eingehenden Bestellungen über dieses Formular ab

Sie schalten über die Navigationsschaltflächen zwischen den Kunden und deren Bestellungen hin und her. Eine weitergehende Navigation existiert nicht. Die wesentlichen Daten stehen im Formularkopf, das im Detailbereich eingebaute Unterformular zeigt die Bestellpositionen.

Dennoch gibt es mit dem Filter Bearbeitungsstatus eine Möglichkeit im Formular, die Datenmenge einzuschränken. Aus dieser Combobox könnte der Vertriebler etwa den Status Bestellung aufgegeben auswählen, um nur jene Datensätze angezeigt zu bekommen, die aktuell bearbeitet werden müssen. Die Combobox führt im Ereignis Nach Aktualisierung (After_Update) diesen Code aus:

Me.Filter = "IDStatus=" & Me!cbFilterStatus.Value

Me.FilterOn = True

Nun kann für einen Kunde die Ware kommissioniert werden, wonach im Unterformular für jede Bestellposition jeweils ein Häkchen bei Bearbeitet gesetzt wird.

Sie haben das Ende des frei verfügbaren Teil dieses Artikels erreicht!

Wenn Sie mehr lesen und auf viele weitere Artikel zugreifen möchten, melden Sie sich als Abonnent unter Login an. Falls nicht, bestellen Sie doch einfach ein Jahresabonnement!