Die üblichen Beispiele zum Thema Bestellverwaltung gehen vereinfachend davon aus, dass immer alle Artikel vorhanden sind und dementsprechend auch in Rechnung gestellt werden können. In der Realität sieht dies anders aus: Natürlich ist nicht immer gewährleistet, dass alle angebotenen Artikel auch verfügbar sind. In diesem Fall lassen sich Lieferungen und Rechnungen nur schwer organisieren. Also kümmern wir uns nochmals um die entsprechenden Tabellen, Formulare und natürlich auch um die Berichte.
Die Nordwind-Datenbank und Konsorten machen es vor: Bestellungen werden in einer Tabelle namens tblBestellungen verwaltet, die den Kunden referenziert und weitere Daten wie etwa das Bestell- und das Lieferdaten enthält.
Die Bestellungen und die in einer Tabelle wie tblArtikel gespeicherten Artikel werden über eine Verknüpfungstabelle namens tblBestellpositionen zusammengeführt. Auf diese Weise wird die Bestellung erfasst, was kein Problem ist – hier wirken sich Fehlbestände noch nicht aus.
Interessant wird es beim Erstellen von Lieferscheinen oder Rechnungen. Wenn eine Bestellung einen Artikel A und einen Artikel B enthält, aber nur A lieferbar ist, darf natürlich nur Artikel A auf dem Lieferschein erscheinen. Artikel B wird dann später hinterhergeschickt.
Alternativ wartet man, bis beide Artikel verfügbar sind, und liefert diese in einer Sendung.
Um die Außenstände im Rahmen zu halten, soll der Kunde natürlich schnell seine Rechnung erhalten. Bevor Artikel B nicht beim Kunden angekommen ist, kann man diesen aber wohl kaum in Rechnung stellen – also schickt man zunächst eine Rechnung über Artikel A oder versendet alternativ die Rechnung mit allen Positionen nach Versendung aller bestellten Artikel.
Hier gehen wir vorsichtig davon aus, dass eine Bestellposition später einer Rechnungsposition entspricht. Auch dies ist nicht unbedingt gegeben: Wenn ein Kunde 100 Stück eines bestimmten Artikels bestellt und nur 50 Stück lieferbar sind, muss man gegebenenfalls selbst eine einzige Position auf zwei Lieferschein- und Rechnungspositionen aufteilen können.
Dies kann man noch weiter ausarbeiten. In manchen Branchen schicken Kunden nicht nur eine Bestellung in einem bestimmten Zeitraum, sondern ordern schnell noch mal einen oder mehrere Artikel nach.
Hier sollte man die Möglichkeit vorsehen, nicht für jede Bestellung eine eigene Rechnung zu schicken, sondern mehrere Bestellungen zusammenzufassen.
Und um dem Ganzen die Krone aufzusetzen: Wenn ein Kunde zwei Bestellungen aufgibt, bei denen beide nicht sofort komplett bearbeitet werden können, weil nicht alle Artikel vorliegen, sollte man auch mehrere Artikel aus verschiedenen Bestellungen in einer einzelnen Rechnung zusammenfassen können.
Und schließlich ließe sich die Abrechnung auch noch nach Zeiträumen definieren: So könnten Sie beispielsweise, unabhängig davon, wie viele Bestellungen der Kunde getätigt hat, eine Rechnung etwa pro Woche oder pro Monat schicken, die alle bis dahin gelieferten Artikel berücksichtigt.
Sie sehen: Es gibt mehr Möglichkeiten als die übliche 1:1-Abbildung von Bestellung und Rechnung. Schauen wir uns also an, wie sich dies auf das Datenmodell auswirkt und wie sich die Daten in Formularen und Berichten bearbeiten und ausgeben lassen.
Standard: Bestellung = Rechnung
Im einfachsten Fall sieht das Datenmodell wie in Bild 1 aus. Jede Bestellung bezieht sich auf einen Kunden und enthält einen oder mehrere Artikel, für die in der Tabelle tblBestelldetails ein individueller Preis festgelegt werden kann. Außerdem landen dort die Anzahl und gegebenenfalls noch ein Rabatt.
Bild 1: Datenmodell, wenn für jede Bestellung eine Rechnung verschickt wird
Aber dort ist keine einzige Tabelle zu sehen, die Informationen zur Rechnung liefert Doch: Die Rechnungsinformationen werden direkt aus den zum Speichern der Bestelldaten verwendeten Tabellen entnommen. In diesem Fall wäre jede zusätzliche Tabelle, in der die Bestelldaten erneut als Rechnungsdaten aufgeführt werden, unnötig.
Die Flexibilität geht allerdings gegen Null. Es ist hier noch nicht einmal möglich, eine einzelne Bestellposition nachvollziehbar zu stornieren. Also erweitern wir das Datenmodell so, dass wir alle eingangs erwähnten Möglichkeiten abdecken können. Anschließend kümmern wir uns um die Möglichkeiten der Dateneingabe und der Berichtserstellung.
Erweiterung: Kostenstelle
Der Kunde verarbeitet oder versendet die gelieferten Artikel möglicherweise weiter und muss diese dazu verschiedenen Kostenstellen zuordnen können. Daher sollte die Tabelle tblBestelldetails um ein Feld namens Kostenstelle ergänzt werden.
Da dieses je Kunde anders aussehen kann, verwenden wir hier vorerst ein reines Textfeld. Sollte man die Bezeichnung der Kostenstellen in eine eigene Tabelle ausgliedern und dann per Fremdschlüsselfeld darauf verweisen Wenn wir flexibel bleiben wollen, lautet die Antwort ja.
Außerdem ist eine weitere änderung an der bestehenden Tabelle tblBestelldetails nötig. Es kann ja durchaus geschehen, dass der Kunde in einer Bestellung den gleichen Artikel für mehrere Kostenstellen ordert. Aktuell enthält die Tabelle tblBestelldetails jedoch einen zusammengesetzten Primärschlüssel über die Felder BestellungID und ArtikelID (s. Bild 2). Dieser Schlüssel muss dann auf die KostenstelleID ausgeweitet werden.
Bild 2: Die Tabelle tblBestelldetails in der Entwurfsansicht
Nebenher erhalten wir natürlich einen weitaus höheren Komfort, wenn eine von vielen Kostenstellen eines Kunden ausgewählt werden kann und nicht jedesmal manuell eingetippt werden muss. Die Tabelle zum Speichern der Kostenstellen sieht wie in Bild 3 aus. Neben dem Primärschlüsselfeld und der Bezeichnung der jeweiligen Kostenstelle enthält die Tabelle auch noch ein Feld namens KundeID.
Bild 3: Tabelle zum Speichern der Kostenstellen
Dieses erlaubt die Zuordnung der Kostenstellen zu den Kunden, damit beim Anlegen einer neuen Bestellung direkt alle zum Kunden gehörenden Kostenstellen verfügbar sind. Damit eine Kostenstelle nicht doppelt angelegt werden kann, fügen Sie noch einen zusammengesetzten eindeutigen Primärschlüssel für die beiden Felder KundeID und Kostenstelle zur Tabelle hinzu.
Positionen statt Bestelldetails
Die Tabelle tblBestelldetails benennen wir im Rahmen der Umgestaltung des Datenmodells gleich in tblBestellpositionen um.
Außerdem erhält die Tabelle einen nur aus einem Feld bestehenden Primärschlüssel namens BestellpositionID. Das Fremdschlüsselfeld zur Auswahl einer Kostenstelle heißt KostenstelleID und wird als Nachschlagefeld ausgelegt. Es soll die Daten der Tabelle tblKostenstellen zur Auswahl anbieten.
Damit in jeder Bestellung jeder Artikel nur in einer Position je Kostenstelle eingegeben werden kann, fügen Sie der Tabelle einen eindeutigen Index über die drei Felder BestellungID, ArtikelID und KostenstelleID hinzu (s. Bild 4).
Bild 4: Die neue Tabelle tblPositionen
Die Auswahl der Kostenstelle muss später in den Formularen natürlich derart eingeschränkt werden, dass nur die Kostenstellen des Kunden der Bestellung angezeigt werden.
Standardkostenstelle
Wenn Sie die Positionen einer Bestellung für einen Kunden anlegen, möchten Sie je nach Anzahl der Positionen nicht jedesmal die Kostenstelle auswählen. Also fügen wir der Tabelle tblKostenstellen ein Feld namens IstStandard hinzu, mit dem Sie die aktuelle Kostenstelle für den Kunden festlegen können – Bild 5 zeigt die beteiligten Tabellen zum Festlegen von Kostenstelle und Standardkostenstelle im Überblick.
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