Bestellverwaltung

Zusammenfassung

Sie erweitern die Artikelverwaltung um Funktionen zur Eingabe von Bestellungen und zum Drucken von Bestellscheinen.

Techniken

Access, Abfragen, 1:1-Beziehungen, Formulare, Unterformulare, Berichte, VBA

Voraussetzungen

Access 2000 oder höher

André Minhorst, Duisburg

In den vorherigen beiden Ausgaben haben Sie die Artikelverwaltung kennen gelernt, mit der Sie Artikel und Inventurdaten verwalten können. Damit haben Sie bereits die Voraussetzungen für die Musterlösung dieses Beitrags geschaffen – für die Bestellverwaltung. Damit können Sie Bestellungen eingeben und Bestellscheine drucken.

Die Bestellverwaltung schlägt die Brücke zwischen der Artikelverwaltung und den im Beitrag Kunden und Kontakte verwalten (Ausgabe 4/2005, Shortlink 293) vorgestellten Funktionen. Die Bestellverwaltung bietet folgende Erweiterungen:

  • Formular zur Eingabe von Bestellungen
  • Bericht zur Ausgabe von Bestellscheinen
  • Das Formular bietet die Möglichkeit, Bestellungen einzugeben und zu bearbeiten. Dazu ist das Auswählen eines Kunden und dessen Liefer- und Rechnungsanschrift sowie die Eingabe beliebig vieler Positionen möglich.

    Zu jeder Position lässt sich ein individueller, vom ursprünglichen Preis abweichender Preis festlegen.

    Der Bericht gibt einen Bestellschein mit Bestell- und Lieferdatum, den Anschriften für Rechnung und Lieferung sowie die einzelnen Positionen aus.

    Alle Tabellen der Bestellverwaltung sind bereits in der Artikelverwaltung enthalten – wenn Sie die Bestellverwaltung “nachbasteln” möchten, brauchen Sie zumindest keine neuen Tabellen hinzuzufügen.

    Bild 1 zeigt den Ausschnitt des Datenmodells, der für die Bestellverwaltung interessant ist.

    Betrachten Sie das abgebildete Datenmodell im Uhrzeigersinn: Die Tabelle tblArtikel enthält Informationen über die Artikel, wobei im Folgenden vor allem die Felder Bezeichnung, EinheitID, Mehrwertsteuersatz und Verkaufspreis eine Rolle spielen werden. Hinter dem Feld EinheitID verbirgt sich noch eine Lookup-Tabelle, die aber hier aus Platzgründen nicht abgebildet ist.

    Dann folgen zwei Tabellen namens tblBestandsaenderungen und tblPositionen. Die beiden Tabellen sind per 1:1-Beziehung miteinander verknüpft und enthalten die Informationen, die in der Nordwind-Datenbank durch die Tabelle Bestelldetails abgebildet werden. Hier sind die Informationen auf zwei Tabellen verteilt, weil ein Bestelldetail auch immer eine Bestandsänderung verursacht und diese in der Datenbank in einer eigenen Tabelle gespeichert wird – etwa um leicht Inventuren durchführen zu können.

    Bild 1: Datenmodell der Bestellverwaltung

    Prinzipiell können Sie diese beiden Tabellen aber wie eine einzige behandeln – was in der Anwendung durch den Einsatz einer entsprechenden Abfrage auch geschieht.

    Am anderen Ende dieser beiden Tabellen hängt die Tabelle tblBestellungen – sie enthält die Informationen der Bestellung selbst, also den Kunden, das Bestell- und Lieferdatum und die Liefer- und Rechnungsadresse des Kunden.

    Wenn man den Zusammenhang zwischen diesen vier Tabellen (oder drei, wenn man die mittleren beiden als eine betrachtet) verstanden hat, steht der Programmierung einer Bestellverwaltung nichts mehr im Wege: Die mittleren beiden Tabellen sind nicht mehr und nicht weniger als die Verknüpfungstabellen einer m:n-Beziehung zwischen den Tabellen tblArtikel und tblBestellungen. Damit kann man jeder Bestellung jeden Artikel zuweisen und legt dabei in den Tabellen tblBestandsaenderungen und tblPositionen fest, welche Anzahl des Artikels die Bestellung enthält und wie der Preis und die Mehrwertsteuer für diese Bestellung lauten.

    Der doppelte Preis

    Warum nun soll der Preis in den Bestelldetails nochmals auftauchen, obwohl dieser doch schon in den Artikeldaten enthalten ist Ganz einfach: Weil das der einzige Weg ist, um einen Artikel auch einmal zu einem anderen Preis zu verkaufen, und vor allem, um sicherzustellen, dass bei einer Preisänderung eines Artikels die Werte aller bereits aufgenommenen Bestellungen automatisch geändert werden.

    Das Gleiche gilt für die Mehrwertsteuer: Wenn sich diese einmal ändert, soll sich das natürlich nicht rückwirkend auf alle bereits vorhandenen Bestellungen auswirken. Deshalb werden diese Daten separat in den Bestelldetails gesichert.

    Bestellungen und Kunden

    Jede Bestellung ist genau einem Kunden zugeordnet. Jeder Kunde kann aber eine oder mehrerer Liefer- und Rechnungsadressen besitzen.

    Daher werden in der Tabelle tblBestellungen nicht nur die KundenID, sondern auch noch die ID der Bestelladresse und der Lieferadresse für diese Bestellung eingetragen.

    Auf diese Weise lässt sich später genau nachvollziehen, wohin Bestellung und Rechnung gegangen sind.

    Und wenn der Kunde einmal umzieht, legt man einfach je einen neuen Datensatz in den Tabellen tblLieferadresse und tblRechnungsadresse an – dann bleiben trotz weiterer Bestellungen die bestehenden Bestellungen unberührt.

    Warum die Tabellen mit den Adressdaten in der Art aufgeteilt sind, wie es das Datenmodell darstellt, erfahren Sie im Beitrag Kunden und Kontakte verwalten (Shortlink 293).

    Für den gesamten unteren Zweig des Datenmodells aus Bild 1 ist die Erweiterung der Artikelverwaltung aus dem oben genannten Beitrag verantwortlich.

    Die Pflege der Artikel wurde bereits in den beiden Beiträgen Artikelverwaltung mit Inventurfunktion, Teil 1 (Heft 2/2005, Shortlink 273) und Teil 2 (Heft 3/2005, Shortlink 281) beschrieben.

    Bleiben noch die Tabellen tblBestellungen, tblPositionen und tblBestandsaenderungen.

    Die Pflege dieser Daten ist identisch mit dem Anlegen von Bestellungen und kann in einem einzigen Formular samt Unterformular abgewickelt werden.

    Hauptformular

    Das Hauptformular hat als Datenherkunft die Tabelle tblBestellungen. Damit der obere Teil des Formulars so wie in Bild 2 aussieht, ziehen Sie einfach die fünf dargestellten Felder aus der Feldliste in die Entwurfsansicht des Formulars.

    Bild 2: Das Bestellformular mit Unterformular in der Entwurfsansicht

    Die drei Kombinationsfelder erfordern noch ein wenig Nacharbeit. Das erste dient der Auswahl des Kunden und soll den Kunden wie in Bild 3 anzeigen. Dazu stellen Sie die Datensatzherkunft des Kombinationsfeldes wie folgt ein:

    SELECT tblKunden.KundeID, [Nachname] & IIf(Not IsNull([Nachname]) And Not IsNull([Vorname]),", ","") 
    & [Vorname] AS Kunde FROM tblKunden;

    Mit diesem Ausdruck sorgen Sie dafür, dass das Komma zwischen Nach- und Vorname nur angezeigt wird, wenn auch beide Felder gefüllt sind.

    Bild 3: Auswahl von Kunden

    Liefer- und Rechnungsadressen anzeigen

    Die übrigen beiden Kombinationsfelder zur Anzeige von Lieferadressen und Rechnungsadressen sollen bei der Auswahl möglichst viele Daten anzeigen, damit man die richtige Adresse auswählen kann.

    Das aufgeklappte Kombinationsfeld soll daher wie in Bild 4 aussehen. Nachname, Vorname und Firma sind dabei platzsparend zusammengefasst und werden auch in eingeklapptem Zustand angezeigt; die übrigen Daten sind in weiteren Feldern enthalten.

    Bild 4: Auswahl einer Rechnungsadresse

    Die Datensatzherkunft des Kombinationsfeldes basiert in diesem Fall auf einer Abfrage, die beim öffnen und Aktualisieren des Formulars zugewiesen wird. Die Abfrage fasst die beiden per 1:1-Beziehung verknüpften Tabellen tblAdressen und tblRechnungsadressen zusammen und erzeugt außerdem den in Bild 4 erkennbaren Ausdruck <Nachname>, <Vorname> (<Firma>). Die dazu notwendige Funktion ist in Bild 5 nicht zu erkennen und daher nachfolgend separat aufgeführt:

    Bild 5: Datensatzherkunft des Kombinationsfeldes cboRechnungsadressen

    Lieferadresse: [Nachname] & Wenn(Nicht IstNull([Nachname]) Und Nicht IstNull([Vorname]);", ";"") 
    & [Vorname] & Wenn(Nicht IstNull([Firma]);" (";"") & [Firma] & Wenn(Nicht IstNull([Firma]);")";"")

    Lieferadressen

    Das Kombinationsfeld zur Auswahl der Lieferadressen ist genauso aufgebaut wie das zur Auswahl der Rechnungsadressen und soll daher nicht gesondert erläutert werden.

    Abhängigkeit der Kombinationsfelder

    Die beiden Kombinationsfelder zur Anzeige von Liefer- und Rechnungsadresse sind von der Auswahl des Kunden im oberen Kombinationsfeld des Formulars abhängig.

    Sie sollen jeweils alle Liefer- und Rechnungsadressen zu dem oben ausgewählten Kunden zur Auswahl anbieten.

    Das bedeutet, dass mit jeder neuen Auswahl im Kombinationsfeld KundeID auch die Datensatzherkunft der beiden Kombinationsfelder LieferadresseID und RechnungsadresseID aktualisiert werden muss.

    Um dies zu realisieren, gibt es zwei Möglichkeiten:

    Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

    den kompletten Artikel im PDF-Format mit Beispieldatenbank

    diesen und alle anderen Artikel mit dem Jahresabo

    Schreibe einen Kommentar