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
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
