Das Kundendetailformular zeigt bisher nur die Stammdaten eines Kunden – Name, Anschrift, Kontaktdaten. Was fehlt, ist der Blick auf das Geschäft: Welche Rechnungen hat dieser Kunde eigentlich erhalten? Diese Frage beantworten wir, indem wir dem Formular ein Unterformular hinzufügen, das genau die Rechnungen des gerade angezeigten Kunden auflistet. Das Prinzip dahinter kennen wir bereits aus dem Rechnungsformular – Verknüpfen von und Verknüpfen nach -, nur wenden wir es diesmal auf eine andere Beziehung an. Und ganz nebenbei wird dabei sichtbar, wozu die historisierten Felder aus dem Datenmodell gut sind. Außerdem legen wir von hier aus neue Rechnungen an und öffnen vorhandene zum Bearbeiten. Wie das gelingt, liest Du in diesem Artikel.
Beispieldatenbank
Die Beispiele dieses Artikels findest Du in der Datenbank Rechnungsverwaltung_RechnungenEinesKundenAnzeigen.accdb. Sie setzt die Reihe fort und enthält die Formulare der vorherigen Artikel bereits.
Warum die Rechnungen ins Kundenformular gehören
Wer mit einem Kunden telefoniert, will häufig zweierlei gleichzeitig sehen: seine Stammdaten und das, was zwischen ihm und uns bisher gelaufen ist. Bisher liegen diese beiden Dinge in getrennten Formularen. Die Anschrift steht in frmKundendetail, die Rechnungen erreicht man nur über frmRechnung – und dort muss man sie erst suchen.
Bequemer ist es, die Rechnungen dorthin zu holen, wo der Kunde ohnehin schon auf dem Bildschirm steht. Genau dafür sind Unterformulare da: Sie zeigen zu einem Datensatz des Hauptformulars die zugehörigen Datensätze der n-Seite. Beim Rechnungsformular waren das die Positionen zu einer Rechnung, hier sind es die Rechnungen zu einem Kunden. Die Beziehung ist eine andere, das Verfahren ist dasselbe.
Das Unterformular anlegen
Wir erstellen über Erstellen|Formulare|Formularentwurf ein neues Formular und binden es über die Eigenschaft Datensatzquelle an die Tabelle tblRechnungen. Gespeichert wird es unter dem Namen sfmKundeRechnungen.
Weil es später als Liste innerhalb eines anderen Formulars erscheinen soll, stellen wir seine Standardansicht auf Datenblatt. Damit zeigt es seine Datensätze zeilenweise untereinander, so wie wir es schon von den Übersichtsformularen der Artikel und Kunden kennen (siehe Bild 1).
Bild 1: Der Entwurf von sfmKundeRechnungen mit der Standardansicht Datenblatt
Welche Felder gehören hinein?
Nun ziehen wir die Felder aus der Feldliste in den Detailbereich. Für eine Rechnungsübersicht sind das die Angaben, an denen man eine Rechnung wiedererkennt: die Rechnungsnummer, das Rechnungsdatum, das Faelligkeitsdatum und das Nachschlagefeld RechnungsstatusID, das den Status im Klartext anzeigt.
Zwei weitere Felder nehmen wir hinzu, und die verdienen eine Erklärung: Kundennummer und KundeFirma. Auf den ersten Blick sind sie überflüssig – wir wissen doch, welchen Kunden wir gerade ansehen, schließlich steht er darüber im Hauptformular. Warum also die Angaben wiederholen?
Der Grund liegt im Datenmodell. Diese beiden Felder gehören zu den historisierten Feldern in tblRechnungen. Sie stammen nicht aus tblKunden, sondern sind Kopien, die beim Anlegen der Rechnung dort hineingeschrieben wurden. Sie zeigen also nicht, wie der Kunde heute heißt, sondern wie er hieß, als die Rechnung angelegt wurde.
Damit wird die Historisierung zum ersten Mal sichtbar. Benennt sich ein Kunde um – aus einer Einzelfirma wird eine GmbH -, dann ändern wir seinen Stammdatensatz, und das Hauptformular zeigt sofort den neuen Namen. Die alten Rechnungen im Unterformular tragen aber weiterhin den alten. Genau so soll es sein: Eine gestellte Rechnung ist ein Dokument, das sich nicht rückwirkend ändert. Wer diese Spalten nicht braucht, kann sie natürlich weglassen – als Anschauungsobjekt für das Prinzip sind sie aber lehrreich.
Unser exklusives Angebot für Dich!
(Das Abo ist jederzeit monatlich kündbar)
Hier geht’s weiter →Die ersten 4 Wochen kostenlos testen – voller Zugriff auf alle Artikel, vollständigen Code und Beispieldatenbanken. Kein Risiko: Wenn es nicht passt, kündigst Du einfach innerhalb der ersten vier Wochen.
Oder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?
Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?
In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.
Jetzt kostenloses Access-Audit anfordern →![Access [basics]](https://access-basics.de/wp-content/uploads/2021/02/logo400.png)
