Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 3/2013.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Lernen Sie das Datenmodell für eine flexiblere Bestell-, Liefer- und Rechnungsverwaltung kennen.

Techniken

Datenmodellierung

Voraussetzungen

Access 2000 und höher

Beispieldateien

FlexibleBestellungen.mdb

Shortlink

www.access-im-unternehmen.de/882

Flexible Bestellverwaltung: Datenmodell

André Minhorst, Duisburg

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

pic001.jpg

Abb. 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. Abb. 2). Dieser Schlüssel muss dann auf die KostenstelleID ausgeweitet werden.

pic002.jpg

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

© 2003-2015 André Minhorst Alle Rechte vorbehalten.