<\/p>\n
Beim Schreiben von Anwendungen, mit denen Rechnungen erstellt werden sollen, stellt sich immer wieder die Frage nach dem korrekten Datenmodell. Davon ausgehend, dass es nicht das perfekte Datenmodell für alle Anwendungsfälle gibt, wollen wir in diesem Beitrag einmal unterschiedliche Ansätze betrachten und diskutieren. Diese haben eines gemein: Die Anwendung mit diesem Datenmodell soll die Möglichkeit bieten, sowohl Bestellungen zu erfassen als auch Rechnungen und Lieferscheine zu erstellen. Wie welche Daten gespeichert werden und welche Möglichkeiten es gibt, schauen wir uns nun an.<\/b><\/p>\nBestellungen erfassen<\/h2>\n
Über bestimmte grundlegende Anforderungen herrscht vermutlich eine einstimmige Meinung: Wenn man Bestellungen erfassen möchte und die Regeln der Normalisierung von Datenmodellen befolgen will, benötigt man mindestens drei Tabellen. Die erste Tabelle enthält die Kundendaten mitsamt einer Kunden-ID und den Daten wie Firma, Anrede, Vorname, Nachname, Straße, PLZ, Ort, Land, Telefon, E-Mail und so weiter.<\/p>\n
In den meisten Fällen liegen die für das Speichern der Anschrift vorgesehenen Felder in zweifacher Ausführung vor, nämlich für die Lieferadresse und die Rechnungsadresse, denn diese können sich unterscheiden. Normalerweise finden wir hier für Liefer- und Rechnungsadresse meist auch noch ein Fremdschlüsselfeld zur Auswahl eines Eintrags einer Anrede-Tabelle – die zählen wir hier aber nicht mit.<\/p>\n
Die zweite Tabelle enthält die grundlegenden Daten einer Bestellung wie die Bestell-ID, das Bestelldatum und ein Fremdschlüsselfeld, mit dem der Kunde ausgewählt werden kann, der diese Bestellung getätigt hat. Auf diese Weise können wir zu jedem Kunden keine, eine oder mehrere Bestellungen anlegen.<\/p>\n
Die dritte Tabelle enthält die Positionen der Bestellung. Diese umfassen eine Bezeichnung der Position, den Einzelpreis, die Menge, die Mehrwertsteuer und gegebenenfalls noch einen Rabatt. Außerdem benötigen wir hier ein Fremdschlüsselfeld, das mit der Bestellungen-Tabelle verknüpft ist, damit wir die einzelnen Bestellpositionen der Bestellung zuordnen können.<\/p>\n
Normalerweise gibt es mindestens noch eine vierte Tabelle, aus der die grundlegenden Daten für die Bestellpositionen stammen. Diese nennen wir üblicherweise Produkt- oder Artikeltabelle. Sie enthält die Produkt- oder Artikelbezeichnung, den Einzelpreis sowie den Mehrwertsteuersatz und weitere Detailinformationen, die für andere Vorgänge wie Warenwirtschaft erforderlich sind – wie die Verwaltung von Beständen et cetera. Wir wollen im Folgenden von Produkten statt von Artikeln sprechen.<\/p>\n
Um die Bestellposition mit dem jeweiligen Produkt zu verknüpfen, enthält die Tabelle der Bestellpositionen meist ein Fremdschlüsselfeld zu der Tabelle der Produkte. Auf diese Weise kann man über die Benutzeroberfläche leicht das zu einer Bestellposition hinzuzufügende Produkt auswählen.<\/p>\n
Der erste Entwurf sieht im Datenbankfenster von Access wie in Bild 1 aus.<\/p>\n
![\"Erster](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_001.png\")
<\/p>\n
Bild 1: Erster Entwurf mit vielen Schwachstellen (V1)<\/span><\/b><\/p>\n Hier gibt es direkt die erste spannende Frage: Wenn ich eine Tabelle mit Bestellpositionen verwende und eine mit den Produkten und in der Tabelle der Bestellpositionen ein Feld ist, mit dem ich das mit dieser Position bestellte Produkt selektieren kann, benötige ich dann überhaupt die ganzen bereits erwähnten Felder? Wenn bereits in der Produkte-Tabelle die Bezeichnung, der Einzelpreis und der Mehrwertsteuersatz gespeichert sind, reicht es dann nicht aus, wenn ich mit einem Fremdschlüsselfeld aus der Bestellpositionen-Tabelle auf den Eintrag aus der Produkte-Tabelle verweise? Und in der Bestellpositionen-Tabelle nur die Felder Menge und Rabatt fülle?<\/p>\n Unter dem Gesichtspunkt, möglichst wenige Daten zu speichern, scheint diese Idee verlockend. Es gibt jedoch ein entscheidendes Problem: Einzelpreise und Mehrwertsteuersätze ändern sich von Zeit zu Zeit. Und es kann sogar vorkommen, dass wir den Namen eines Produktes ändern wollen (auch wenn es sich dann anbieten würde, einen neuen Produktdatensatz zu diesem Zweck anzulegen). Wenn es Bestellungen für ein Produkt gibt, und der Einzelpreis und der Mehrwertsteuersatz nur in der Produkttabelle vorliegen, dann können wir später nicht mehr nachvollziehen, zu welchem Preis und zu welchem Mehrwertsteuersatz der Kunde zuvor bestellt hat. Stattdessen werden wir alle Bestellpositionen immer mit den aktuellen Einzelpreisen und Mehrwertsteuersätzen vorfinden.<\/p>\n Wir können so also nach der Änderung auch nur eines Einzelpreises oder Mehrwertsteuersatzes für ein Produkt in einer Bestellposition einer Bestellung nicht mehr die tatsächlichen Umsätze nachvollziehen.<\/p>\n Den aktuellen Stand des Datenmodells finden Sie in der Beispieldatenbank GrundlagenDatenmodellRechnungsverwaltung_V1.accdb<\/b>.<\/p>\n Was tun? Damit die Änderungen am Produktnamen und an den Einzelpreisen und Mehrwertsteuersätzen eines einzelnen Produkts in der Produkttabelle keine Auswirkungen mehr auf die zum Zeitpunkt der Bestellung gültigen Werte haben, müssen wir diese Daten direkt in der Tabelle mit den Bestellpositionen speichern.<\/p>\n Dazu sehen wir einfach drei Felder mit den gleichen Namen wie in der Produkte-Tabelle vor, also beispielsweise Produkt<\/b>, Einzelpreis <\/b>und Mehrwertsteuersatz<\/b> (siehe Bild 2).<\/p>\n Bild 2: Diese Felder sollen dauerhaft mit der Bestellposition gespeichert werden (V2).<\/span><\/b><\/p>\n Fügen wir in der Benutzeroberfläche einer Bestellposition ein Produkt beispielsweise durch Auswahl eines Nachschlagefeldes hinzu, kopieren wir direkt die Werte der Felder Produkt<\/b>, Einzelpreis <\/b>und Mehrwertsteuersatz <\/b>in die Tabelle der Bestellpositionen.<\/p>\n Diese und die folgende Änderung haben wir in der Beispieldatenbank GrundlagenDatenmodellRechnungsverwaltung_V2.accdb <\/b>hinterlegt.<\/p>\n Auf das Thema Mehrwertsteuersätze <\/b>gehen wir gegen Ende des Beitrags im Detail ein.<\/p>\n Das sind allerdings nicht die einzigen Daten, die Änderungen unterliegen. Auch die Adressen von Kunden ändern sich von Zeit zu Zeit. Das ist auch kein Problem: Wir ändern einfach die Adressdaten in der Kundentabelle und haben jederzeit den aktuellen Stand, um neue Bestellungen korrekt erfassen zu können.<\/p>\n Die Sache hat allerdings einen Haken: Im aktuellen Stand unseres Datenmodells ist die Kundentabelle noch über ein Fremdschlüsselfeld in der Tabelle tblBestellungen <\/b>mit der Bestellung verknüpft. Wenn wir die Daten in der Kunden-Tabelle ändern, dann ändern wir automatisch auch die Adressdaten des Kunden einer Bestellung.<\/p>\n Das bringt wieder Nachteile mit sich, wenn wir einmal von der Region abhängige Auswertungen über unsere Bestelldaten durchführen möchten. Zieht ein Kunde von Duisburg nach München, ändert sich auch die Auswertung, denn nun hat Bayern ein paar Bestellungen und Umsätze mehr auf der Habenseite.<\/p>\n Auch das wollen wir tunlichst vermeiden. Wie können wir das tun? Wir wählen einen ähnlichen Ansatz wie bei den Bestellpositionen und Produkten: Wir legen in der Bestellungen-Tabelle weitere Felder an, in denen wir die Kundenadressen zum Zeitpunkt der Bestellung speichern. Das Fremdschlüsselfeld zum Kunden in der Tabelle tblBestellungen <\/b>sollten wir jedoch beibehalten, denn wir wollen ja gegebenenfalls auch einmal einen Überblick über die Bestellungen eines Kunden und die darin enthaltenen Positionen haben.<\/p>\n Wie in Bild 3 zu sehen, haben wir eine Reihe von Feldern auch in der Tabelle der Bestellungen angelegt. In der Praxis gelingt das übrigens ganz einfach – Sie müssen einfach nur die zu kopierenden Felder im Entwurf der Quelltabelle kopieren und dann in der Zieltabelle einfügen.<\/p>\n Bild 3: Diese Felder sollen dauerhaft mit der Bestellung gespeichert werden (V2).<\/span><\/b><\/p>\n Auch hier müssen wir in der Benutzeroberfläche beim Auswählen des Kunden zu einer Bestellung Code auslösen, der dafür sorgt, dass die Felder der Bestellungen-Tabelle mit den Daten aus der Kundentabelle gefüllt werden.<\/p>\n Theoretisch könnten wir auch noch die beiden Felder EMail <\/b>und Telefon <\/b>zur Tabelle tblBestellungen <\/b>hinzufügen. Dies hätte den Sinn, dass wir später noch reproduzieren könnten, wohin wir E-Mails beispielsweise mit Bestellbestätigungen oder Rechnungen gesendet haben. Allerdings gehen wir davon aus, dass die E-Mails auch archiviert werden und im späteren Verlauf gegebenenfalls eingesehen werden können.<\/p>\n In vielen Datenbanken sehen wir, dass Adressen separat in eigenen Tabellen gespeichert werden. Das könnte man angehen, indem man eine Tabelle für Adressen anlegt und dort Adressen speichert, die man dann über zwei Fremdschlüsselfelder namens LieferadresseID <\/b>und RechnungsadresseID <\/b>referenziert.<\/p>\n Danach würde dieser Teil des Datenmodells wie in Bild 4 aussehen. Wir haben hier im gleichen Zuge noch eine Frage gelöst, nämlich die, ob wir E-Mail und Telefon nur einmal je Kunde benötigen oder ob wir für die Liefer- und die Rechnungsadresse jeweils eigene Felder namens EMail <\/b>und Telefon <\/b>vorsehen sollen.<\/p>\n Bild 4: Ausgliederung der Liefer- und Rechnungsadressen in eine weitere Tabelle (V3).<\/span><\/b><\/p>\n Wir haben die beiden Felder einfach in die Tabelle tblAdressen <\/b>verschoben, wo man diese Daten nun für alle Adressen hinterlegen kann.<\/p>\n Wenn wir entschieden hätten, dass wir nur eine E-Mail-Adresse und eine Telefonnummer benötigen, hätten wir diese Felder in der Tabelle tblKunden <\/b>belassen können.<\/p>\n Es macht jedoch mehr Sinn, hier auf Flexibilität zu setzen, denn es kann beispielsweise passieren, dass ein Kunde ein digitales Produkt ordert, zu dem Daten per E-Mail versendet werden sollen und der für die Rechnungen eine eigene Rechnungs-E-Mail-Adresse verwendet.<\/p>\n Mit dieser Version des Datenmodells sind wir allerdings auf je zwei Adressen pro Kunde beschränkt. Wer zum Beispiel schon einmal bei Amazon bestellt hat, weiß, dass man dort beliebig viele Lieferadressen hinterlegen kann. Wir wollen uns einmal ansehen, wie wir unser Datenmodell verändern müssten, um dies zu implementieren.<\/p>\n Voraussetzung soll jedoch sein, dass wir eine der Adressen als Standardlieferadresse festlegen können und eine als Standardrechnungsadresse. Dazu gibt es zwei Möglichkeiten:<\/p>\n Bild 5: Das Fremdschlüsselfeld KundeID ermöglicht die Zuordnung der Adressdatensätze zu einem Kundendatensatz (V4).<\/span><\/b><\/p>\n Bild 6: Wir können die Beziehung auch komplett umdrehen. Dann müssen wir angeben, welche Adresse die Standardliefer- und Standardrechnungsadresse ist (V5).<\/span><\/b><\/p>\n<\/ul>\n Da scheint es zumindest aus Sicht der Datenintegrität zuverlässiger, Variante V4 <\/b>zu wählen.<\/p>\n Wenn wir wie in V3<\/b>, V4 <\/b>oder V5 <\/b>eine eigene Tabelle zum Speichern der Kundenadressen verwenden, können wir nach wie vor wie in V2 <\/b>die bei Bestellung gültige Liefer- und Rechnungsadresse in die Felder der Tabelle tblBestellungen <\/b>übernehmen.<\/p>\n [<\/p>\n Wir könnten aber auch hier die Adressen in einer oder mehreren Tabellen speichern. Hier haben wir einen etwas einfacheren Fall, als dass wir zu jeder Bestellung nur maximal eine Liefer- und eine Rechnungsadresse speichern müssen. Wir könnten also die Felder der Tabelle tblBestellungen <\/b>wie in Bild 7 in weiteren Tabellen organisieren (siehe GrundlagenDatenmodellRechnungsverwaltung_V6.accdb<\/b>).<\/p>\n Bild 7: Auch beiden Bestellungen könnte man die Adressen wie hier in eigenen Tabellen speichern – hier einmal mit jeweils einer Tabelle für Liefer- und Rechnungsadressen (V6).<\/span><\/b><\/p>\n Hier haben wir einmal einen anderen Ansatz gewählt als in den vorherigen Beispielen, wo wir dem Kunden die Adressen auf verschiedene Arten zugeordnet haben.<\/p>\n In diesem Fall verwenden wir nicht eine Tabelle für alle Adressen, sondern wir haben einmal zwei Tabellen genutzt – eine für die Liefer- und eine für die Rechnungsadressen. Diese haben wir tblBestellungenLieferadressen <\/b>und tblBestellungenRechnungsadressen <\/b>genannt. Beide sind jeweils über das Fremdschlüsselfeld BestellungID <\/b>mit der jeweiligen Bestellung aus der Tabelle tblBestellungen <\/b>verknüpft.<\/p>\n Wir könnten auch hier mit nur einer Adresstabelle arbeiten. Dazu müssten wir dann wieder zwei Fremdschlüsselfelder zur Tabelle tblBestellungen <\/b>hinzufügen, mit denen wir jeweils die Lieferadresse und die Rechnungsadresse für die jeweilige Bestellung hinterlegen können.<\/p>\n Im Gegensatz zur Version V6<\/b> können wir hier, wenn die Liefer- und die Rechnungsadresse gleich sind, einen Datensatz einsparen.<\/p>\n In V6 <\/b>benötigen wir immer zwei Datensätze, je einen in der Tabelle tblBestellungenLieferadressen <\/b>und einen in der Tabelle tblBestellungenRechnungsadressen<\/b>. Die Version mit nur einer Adresstabelle ist in Bild 8 dargestellt (siehe GrundlagenDatenmodellRechnungsverwaltung_V7.accdb<\/b>).<\/p>\n Bild 8: Man könnte auch nur eine Tabelle mit Bestelladressen verwenden, die dann mit zwei Fremdschlüsselfeldern der Tabelle tblBestellungen verknüpft wird (V7).<\/span><\/b><\/p>\n Einen Punkt haben wir noch nicht berücksichtigt: die individuelle Kundennummer. Aktuell haben wir in der Tabelle tblKunden <\/b>nur ein Primärschlüsselfeld namens KundeID<\/b>. Dieses wird von der Autowertfunktion mit aufsteigenden Zahlen gefüllt. Gegebenenfalls kommen die Bestellungen aber aus einem Shopsystem, das einen eigenen Kundennummernkreis pflegt, oder man möchte generell ein anderes Kundennummern-Format nutzen als einfach durchlaufende Zahlen zu verwenden.<\/p>\n In diesem Fall fügt man einfach ein weiteres Feld beispielsweise namens Kundennummer <\/b>hinzu und legt den entsprechenden Datentyp fest – bei Zahlen den Datentyp Zahl <\/b>und wenn man Kombinationen aus Buchstaben und Zahlen verwenden möchte den Datentyp Text<\/b>. Wichtig ist, dass wir dieses Feld mit einem eindeutigen Index versehen, damit keine Kundennummer doppelt vergeben wird. Das Feld Kundennummer haben wir ab V8 <\/b>hinzufügt.<\/p>\n Gleiches gilt für die Nummern von Bestellungen. Auch hier kann es sein, dass Bestellungen von einem oder mehreren Onlineshops importiert werden und\/oder manuell angelegt werden. Dann möchte man gegebenenfalls auch diese Bestellnummern pflegen, wozu sich ein Feld namens Bestellnummer <\/b>zusätzlich zum Primärschlüsselfeld BestellungID <\/b>anbietet.<\/p>\n Auch hier sollten wir einen eindeutigen Index festlegen, um zu verhindern, dass Bestellnummern doppelt angelegt werden.<\/p>\n Schließlich können wir ein solches Feld auch noch für die Produktnummern in der Tabelle tblProdukte <\/b>anlegen.<\/p>\n Als ob das nicht schon genug Varianten wären (und es gibt sicher noch einige weitere), kommen nun noch die Rechnungen ins Spiel.<\/p>\n Eigentlich könnten wir auf Basis der bisher angelegten Daten bereits Rechnungen erstellen. Die Daten liegen in allen Versionen in den enthaltenen Tabellen vor. Der einzige Unterschied besteht in der Art der Verteilung auf die jeweiligen Tabellen und darin, dass – zumindest in den ersten Versionen – Änderungen an den Basisdaten, wie zum Beispiel den Adressen oder Produkten, zu Unterschieden bei der gedruckten oder als PDF erstellten Rechnung führen können.<\/p>\n Für die Erstellung von Rechnungen benötigen wir zusätzlich eigentlich nur noch ein Rechnungsdatum und eine Rechnungsnummer. Können wir diese nicht einfach noch in die Bestellungen-Tabelle einbauen und dann daraus unsere Rechnung generieren?<\/p>\n Technisch ist das möglich. Aber es gibt einige Gründe, warum man Bestellungen und Rechnungen in eigenen Tabellen speichern sollte.<\/p>\n Also schauen wir uns an, wie wir das Datenmodell auch noch um die Tabellen zum Verwalten der Rechnungsdaten ergänzen.<\/p>\n Grundsätzlich können wir die Entwürfe der Tabellen für die Bestellungen und Bestellpositionen genau auf die Tabellen für die Rechnungen übertragen. Dazu fügen wir dem Datenmodell zunächst eine Tabelle namens tblRechnungen <\/b>hinzu. Diese enthält im Wesentlichen die Felder, die wir bereits von der Tabelle tblBestellungen <\/b>her kennen – nur dass wir das Primärschlüsselfeld RechnungID <\/b>nennen und ein Feld namens Rechnungsdatum <\/b>hinzugefügt haben. Statt des Feldes Bestellnummer verwenden wir Rechnungsnummer<\/b>.<\/p>\n Dieses Feld versehen wir mit einen eindeutigen Index. Die Anwendung muss sicherstellen, dass die Rechnungsnummern durchlaufend sind. Das Feld Bestelldatum <\/b>übernehmen wir ebenfalls wie die Felder KundeID<\/b>, LieferadresseID <\/b>und RechnungsadresseID<\/b>. Allerdings verweisen die beiden Fremdschlüsselfelder LieferadresseID <\/b>und RechnungsadresseID <\/b>auf eine weitere neue Tabelle namens tblRechnungsadressen<\/b>. Warum schleifen wir die Lieferadresse mit? Weil wir gegebenenfalls die Lieferadresse in der Rechnung vermerken wollen.<\/p>\n Schließlich enthält die Tabelle tblRechnungen <\/b>noch ein neues Fremdschlüsselfeld namens BestellungID<\/b>, mit dem wir auf den Datensatz aus der Tabelle tblBestellungen <\/b>verweisen, zu dem die Rechnung gehört. Auf diese Weise können wir zu jeder Bestellung mehrere Rechnungen schreiben, was beispielsweise nötig ist, wenn ein oder mehrere Produkte später geliefert werden, weil sie nicht vorrätig sind, und deshalb auch erst später in Rechnung gestellt werden sollen.<\/p>\n Die Tabelle tblRechnungspositionen <\/b>zum Speichern der einzelnen Positionen der Rechnungen ist wiederum fast eine Kopie der Tabelle tblBestellpositionen<\/b>. Sie wird allerdings über das Fremdschlüsselfeld RechnungID <\/b>mit dem entsprechenden Datensatz der Tabelle tblRechnungen <\/b>verknüpft. Außerdem finden wir in dieser Tabelle ein weiteres Fremdschlüsselfeld namens BestellpositionID<\/b>. Damit legen wir eine Verbindung zu der Bestellposition an, zu der diese Rechnungsposition gehört. Auf diese Weise können wir beispielsweise per Abfrage prüfen, welche Bestellpositionen noch nicht in Rechnung gestellt wurden und dementsprechend noch in einer weiteren Rechnung abgerechnet werden müssen.<\/p>\n Die Änderungen finden wir in Bild 9 (siehe auch GrundlagenDatenmodellRechnungsverwaltung_V8.accdb<\/b>).<\/p>\n Bild 9: Erweiterung des Datenmodells um die Tabellen zum Speichern der Rechnungsdaten – inklusive Verknüpfungen zu den Tabellen mit den Bestellungen und Bestellpositionen (V8)<\/span><\/b><\/p>\n Mit diesem Fremdschlüsselfeld ermöglichen wir auch noch, dass wir zu einer Bestellposition nicht nur eine, sondern mehrere Rechnungspositionen anlegen können. Wozu das? Es kann nicht nur passieren, dass ein Produkt gar nicht mehr lieferbar ist, sondern auch, dass ein Produkt nicht mehr in der bestellten Menge vorrätig ist. Dann können wir zunächst die vorrätige Menge an den Kunden versenden und diese in Rechnung stellen. Wir können dann wiederum per Abfrage ermitteln, welche Menge der jeweiligen Bestellposition bereits versendet wurde.<\/p>\n Weiter oben haben wir als einen der Gründe, warum wir neben den Bestelltabellen auch noch Rechnungstabellen anlegen wollen, die Möglichkeit genannt, dass wir auch Positionen aus mehreren Bestellungen in einer Rechnung abrechnen können. Das heißt, wir wollen nicht nur mehrere Rechnungen zu einer Bestellung stellen, sondern auch noch mehrere Bestellungen in einer Rechnung erfassen können. Das schreit nach einer m:n-Beziehung, aber wie genau soll diese aussehen?<\/p>\n Wenn wir jede Rechnung mit jeder Bestellung kombinieren können wollen, benötigen wir eine m:n-Verknüpfungstabelle, welche die Primärschüsselfelder der beiden Tabellen tblBestellungen <\/b>und tblRechnungen <\/b>miteinander verknüpft.<\/p>\n Aber was geschieht mit den beiden Tabellen tblRechnungspositionen <\/b>und tblBestellpositionen <\/b>sowie deren Verknüpfung? Können wir diese so beibehalten? Ja, das können wir – es ist ja nach wie vor so, dass wir jede Rechnungsposition genau einer Bestellposition zuweisen können wollen, auch wenn die Menge der in der Rechnungsposition genannten Produkte nicht der Menge der Produkte in der Bestellposition entsprechen muss.<\/p>\n Die Änderungen am Datenmodell sind in Bild 10 dargestellt und markiert.<\/p>\n Bild 10: Umstellen der Verknüpfung zwischen den Rechnungen und Bestellungen von 1:n auf m:n (V8a)<\/span><\/b><\/p>\n Für die Tabelle zum Herstellen der m:n-Beziehung zwischen den Tabellen tblBestellungen <\/b>und tblRechnungen <\/b>legen wir einen eindeutigen, zusammengesetzten Schlüssel an. Dieser sorgt dafür, dass jede Rechnung nur einmal jeder Bestellung zugeordnet werden kann (siehe Bild 11).<\/p>\n Bild 11: Zusammengesetzter, eindeutiger Index für die beiden Fremdschlüsselfelder der Tabelle<\/span><\/b><\/p>\n Der nächste Bereich einer Bestellung, den wir im Datenmodell abbilden müssen, ist die Auslieferung. Im Optimalfall beispielsweise eines Onlineshops, der nur digitale Produkte verkauft, die logischerweise immer vorrätig sind, könnte man naiverweise in der Version V1 weiter oben einfach ein Feld namens Lieferdatum <\/b>zur Tabelle tblBestellungen <\/b>hinzufügen und dort das gleiche Datum wie für das Feld Bestelldatum <\/b>eintragen.<\/p>\n Sobald wir aber auch nur ein Produkt im Shop haben, das nicht immer sofort ausgeliefert werden kann, ist es sinnvoll, auch für die Auslieferung noch einen weiteren Satz an Tabellen anzulegen.<\/p>\n Das Ergebnis sehen wir in Bild 12.<\/p>\n Bild 12: Erweiterung des Datenmodells um die Tabellen zum Speichern der Lieferdaten – inklusive einer Tabelle mit den Versanddienstleistern (V9)<\/span><\/b><\/p>\n Nachfolgend haben wir die folgenden neuen Tabellen aufgelistet, die weitgehend wie die Tabellen für die Rechnungen aufgebaut sind:<\/p>\n Je nach Geschäftsmodell und Verkaufsbedingungen kann es sein, dass Stornierungen auftreten.<\/p>\n Dafür kann es verschiedene Gründe geben:<\/p>\n Daneben gibt es unterschiedliche Auswirkungen:<\/p>\n Und es gibt auch noch verschiedene Zeitpunkte, zu denen Stornierungen oder Änderungen einer Bestellung auftreten. Hier kommt es noch darauf an, in welcher Reihenfolge nach der Bestellung die Auslieferung und die Rechnungsstellung erfolgen.<\/p>\n Um hier ausreichend flexibel zu sein, sollten wir allen betroffenen Tabellen ein Feld namens Stornierungsdatum <\/b>hinzufügen. Je nachdem, ob nach der Bestellung bereits Rechnungen gestellt oder Lieferungen eingetragen wurden, kann man diese dann als storniert in den Tabellen vermerken:<\/p>\n Der Ausgangspunkt ist immer die Bestellung beziehungsweise die Bestellposition. Wird eine komplette Bestellung storniert, können wir das Feld Stornierungsdatum <\/b>in der Tabelle tblBestellungen <\/b>mit dem Stornierungsdatum füllen.<\/p>\n Dies würden wir dann auf bereits bestehende Datensätze zu dieser Bestellung in den Tabellen tblRechnungen <\/b>und tblLieferungen <\/b>übertragen. Außerdem sollte sich dies auch auf die verknüpften Datensätze der Tabellen tblBestellpositionen<\/b>, tblRechnungspositionen <\/b>und tblLieferpositionen <\/b>auswirken.<\/p>\n Wenn nur eine oder mehrere Bestellpositionen storniert werden sollen, füllen wir nur das Feld Stornierungsdatum <\/b>für die entsprechenden Datensätze in der Tabelle tblBestellpositionen <\/b>und nachfolgend in den Tabellen tblRechnungspositionen <\/b>und tblLieferpositionen<\/b>.<\/p>\n Hier müsste man jedoch Mechanismen in der Geschäftslogik einbauen, die prüfen, ob überhaupt storniert werden kann – wenn Rechnungen bereits versendet und bezahlt wurden, müsste man gegebenenfalls erst die Rückzahlung veranlassen und dann eine Korrekturrechnung schicken.<\/p>\n Die Einbeziehung dieser Abläufe würde jedoch den Rahmen des vorliegenden Beitrags sprengen.<\/p>\n Ein wichtiges Thema haben wir uns bis zum Schluss aufbewahrt. Dabei handelt es sich um die Mehrwertsteuer. Bisher taucht diese in den folgenden Tabellen auf:<\/p>\n In den Produkten haben wir dazu bisher ein einfaches Währungsfeld <\/b>mit dem Format Prozentzahl <\/b>vorgesehen (dadurch wird der Wert mit dem Datentyp Decimal <\/b>gespeichert, der keine Probleme beim Runden erzeugt wie Gleitkommazahlen).<\/p>\n In einer perfekten Welt, in der sich die Mehrwertsteuersätze nicht ändern, wäre dies ausreichend. Selbst eine zusätzliche Tabelle, welche die Mehrwertsteuersätze speichert, wäre nicht nötig, weil sich diese ja nicht ändern. Okay, in einer wirklich perfekten Welt gäbe es vielleicht nur einen Mehrwertsteuersatz (oder gar keinen), aber wir müssen mit dem arbeiten, was uns die Gesetze vorgeben.<\/p>\n Schauen wir uns also an, was bezogen auf dem Mehrwertsteuersatz an zusätzlichen Anforderungen entsteht, die wir bisher noch nicht berücksichtigt haben.<\/p>\n Die erste Feststellung dazu ist: In Deutschland gibt es zwei Mehrwertsteuersätze:<\/p>\n Die Bezeichnungen sind derzeit das Einzige, was wir als konstant bezeichnen können, und auch hier kann man natürlich nie ausschließen, dass es nicht auch einmal einen weiteren Mehrwertsteuersatz gibt – immerhin gibt es Länder, die nur einen einzigen Mehrwertsteuersatz verwenden und auch solche, die noch einen dritten Nutzen haben. Und diese Auflistung ist vermutlich auch nicht vollständig.<\/p>\n Nicht konstant ist der tatsächlich verwendete Mehrwertsteuersatz. Dieser wurde im Laufe der Jahre gelegentlich erhöht, und in 2020 wegen der Corona-Krise für ein Jahr vermindert. All dies müssen wir in einer Anwendung zur Verwaltung von Bestellungen natürlich berücksichtigen, und zwar so, dass der Benutzer damit möglichst wenig Arbeit hat.<\/p>\n Das heißt, dass wir optimalerweise nur einmal beim Anlegen eines Produkts festlegen müssen, ob für ein Produkt der reguläre oder der reduzierte Mehrwertsteuersatz gilt. Den Rest sollte die Datenbankanwendung erledigen – also zum Beispiel beim Hinzufügen eines Produkts als Position einer Bestellung den tatsächlichen derzeit gültigen Mehrwertsteuersatz in die Tabelle tblBestellpositionen <\/b>zu übertragen.<\/p>\n Im einfachsten Fall verwenden wir dazu eine Tabelle namens tblMehrwertsteuersaetze<\/b>, die zwei Felder enthält:<\/p>\n Aus der Tabelle tblProdukte <\/b>entfernen wir nun das Feld Mehrwertsteuersatz <\/b>und fügen eines namens MehrwertsteuersatzID <\/b>hinzu, das als Nachschlagefeld zur Auswahl eines der Einträge der Tabelle tblMehrwertsteuersaetze <\/b>verwendet werden kann (oder für Puristen auch als einfaches Fremdschlüsselfeld).<\/p>\n Das Ergebnis sieht wie in Bild 13 aus (siehe GrundlagenDatenmodellRechnungsverwaltung_V11.accdb<\/b>). Der Mehrwertsteuersatz muss beim Anlegen einer Bestellposition von der Anwendung aus dem richtigen Datensatz der Tabelle tblMehrwertsteuersaetze <\/b>ausgelesen und in das Feld Mehrwertsteuersatz <\/b>der Tabelle tblBestellpositionen <\/b>eingetragen werden.<\/p>\n Bild 13: Erweiterung der Verarbeitung des Mehrwertsteuersatzes (V11)<\/span><\/b><\/p>\n Dies funktioniert nur, wenn die Tabelle tblMehrwertsteuersaetze <\/b>an dem Tag, an dem wir eine Bestellung anlegen, den korrekten Mehrwertsteuersatz für diesen Datumsbereich aufweist.<\/p>\n Sicherer wäre es, wenn wir in der Tabelle tblMehrwertsteuersaetze <\/b>noch zwei zusätzliche Felder namens GueltigVon <\/b>und GueltigBis <\/b>aufnehmen, die den Zeitraum enthalten, in dem dieser Mehrwertsteuersatz gültig ist. Dann müsste der Mechanismus, der beim Anlegen einer Bestellposition nach der Auswahl des Produkts ausgelöst wird, den für das aktuelle Datum gültigen Mehrwertsteuersatz ermitteln und diesen in das Feld tblBestellpositionen <\/b>eintragen.<\/p>\n Wichtig ist allein, dass wir in der Tabelle tblBestellpositionen <\/b>sowie dann später auch in der Tabelle tblRechnungspositionen <\/b>den tatsächlichen, zum Bestellzeitpunkt gültigen Mehrwertsteuersatz vermerken und nicht etwa ein Fremdschlüsselfeld mit einem Verweis auf die Tabelle tblMehrwertsteuersaetze<\/b>. Auch wenn es attraktiv erscheint, dies zu tun, da man durch die Angabe von Gültigkeitsbereichen eigentlich immer den gültigen Mehrwertsteuersatz erhalten sollte, ist das Eintragen des konkreten Wertes sicherer.<\/p>\n Wir haben in diesem Beitrag nur die Erstellung von Rechnungen berücksichtigt, jedoch nicht die daraus resultierenden nachfolgenden Aufgaben. Schließlich sollte auch der Rechnungseingang noch verfolgt und dokumentiert werden – und daran schließt sich auch noch ein Erinnerungs- beziehungsweise Mahnwesen an, das nochmals einige weitere Tabellen erfordert.<\/p>\n Wenn wir schon ein Datenmodell zusammenstellen, darf ein Blick auf die referenzielle Integrität für die Definition der Beziehungen zwischen den Tabellen und die Funktion der Löschweitergabe nicht fehlen.<\/p>\n Referenzielle Integrität haben wir stillschweigend für alle Beziehungen innerhalb der Datenbank aktiviert. Erfahrene Access-Entwickler haben das direkt an der Art der Beziehungspfeile im Datenmodell erkannt. Die große Frage ist jedoch: Für welche Beziehungen aktivieren wir die Löschweitergabe und für welche nicht? Löschweitergabe bedeutet, dass wenn wir einen Datensatz aus der Tabelle, die mit dem Primärschlüsselfeld an der Beziehung beteiligt ist, löschen, alle Datensätze der Tabelle gelöscht werden, die über das Fremdschlüsselfeld mit dieser Tabelle verknüpft sind.<\/p>\n Das macht an einigen Stellen Sinn, an anderen wiederum nicht. Im Falle der Bestellverwaltung sollte man jedoch überall ohne Löschweitergabe arbeiten. In manchen Fällen könnte man dies nach Rückfrage an den Benutzer erlauben beziehungsweise einen Hinweis darauf geben, dass dieser zunächst alle verknüpften Datensätze löschen muss, bevor der Hauptdatensatz gelöscht werden kann. Also haben wir in dieser Beispieldatenbank alle Löschweitergaben deaktiviert (diesen Schritt haben wir erst in V12 <\/b>durchgeführt – in den vorherigen Versionen sind noch aktivierte Löschweitergaben enthalten).<\/p>\n Bild 14 zeigt alle Tabellen und Beziehungen, die wir im Rahmen dieses Beitrags angelegt haben, in einer Übersicht an.<\/p>\nProduktdaten mit den Bestellpositionen speichern?<\/h2>\n
Änderungen von Einzelpreis und Mehrwertsteuersatz behandeln<\/h2>\n
![\"Diese](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_002.png\")
<\/p>\nÄnderungen von Adressdaten behandeln<\/h2>\n
![\"Diese](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_003.png\")
<\/p>\nAdressen separat speichern<\/h2>\n
![\"Ausgliederung](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_004.png\")
<\/p>\nBeliebige Anzahl an Adressen<\/h2>\n
\n
![\"Das](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_005.png\")
<\/p>\n![\"Wir](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_006.png\")
<\/p>\nEigene Adresstabellen in Bezug auf Bestellungen<\/h2>\n
![\"Auch](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_007.png\")
<\/p>\n![\"Man](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_008.png\")
<\/p>\nKundennummern<\/h2>\n
Bestellnummern<\/h2>\n
Rechnungen<\/h2>\n
\n
Rechnungstabellen<\/h2>\n
![\"Erweiterung](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_009.png\")
<\/p>\nBestellpositionen aus mehreren Bestellungen in einer Rechnung<\/h2>\n
![\"Umstellen](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_010.png\")
<\/p>\n![\"Zusammengesetzter,](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_011.png\")
<\/p>\nAuslieferung der Bestellung<\/h2>\n
![\"Erweiterung](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_012.png\")
<\/p>\n\n
Stornierungen oder Änderungen von Bestellungen<\/h2>\n
\n
\n
\n
Die Mehrwertsteuer<\/h2>\n
\n
\n
\n
![\"Erweiterung](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_013.png\")
<\/p>\nAusblick Rechnungsverwaltung<\/h2>\n
Referenzielle Integrität und Löschweitergabe<\/h2>\n
Datenmodell in der Übersicht<\/h2>\n
![\"Das](\"..\/fileadmin\/_temp_\/2023_06\/pic_1459_014.png\")
<\/p>\n