Access [basics]

In den Übersichtsformularen für Kunden und Artikel gibt es seit den ersten Artikeln der Reihe eine Schaltfläche zum Löschen. Solange ein Kunde noch keine Rechnung hat, löscht sie den Kunden. Hat er Rechnungen, bleibt der Kunde stehen, ohne dass die Schaltfläche erklärt, warum. Dass das Löschen scheitert, ist gewollt, die fehlende Rückmeldung nicht. Wie wir vor dem Löschen prüfen, ob zu einem Kunden oder Artikel noch Daten gehören, und wie wir Fehler beim Löschen mit einer Fehlerbehandlung abfangen, liest Du in diesem Artikel.

Bei Privatkunden ist der Kunde zugleich der Ansprechpartner. Bei Firmenkunden haben wir es oft mit mehreren Personen zu tun: der Geschäftsführerin, dem Einkäufer oder jemandem aus der Buchhaltung, der die Rechnungen bearbeitet. Diese Personen wollen wir zu jedem Kunden erfassen und im Kundendetailformular auf einen Blick sehen. Eine von ihnen soll als Hauptansprechpartner markiert sein, aber nur eine. Wie wir Tabelle, Formulare und Schaltflächen dafür anlegen und wie wir die Regel mit dem einen Hauptansprechpartner durchsetzen, liest Du in diesem Artikel.

Seit dem letzten Artikel erhält eine Rechnung beim Stellen ihre Rechnungsnummer. Damit ist sie noch nicht vor Änderungen geschützt: Öffnen wir sie erneut, können wir Mengen ändern, Positionen löschen und das Datum überschreiben, obwohl die Rechnung bereits beim Kunden liegt. Das widerspricht dem Zweck einer gestellten Rechnung. Außerdem fehlen zwei Aktionen, die eine Rechnungsverwaltung braucht: Eine gestellte Rechnung muss sich stornieren lassen, und ein Entwurf, den niemand mehr braucht, soll sich löschen lassen. Wie wir das Rechnungsformular abhängig vom Status sperren und die beiden Aktionen im Kundendetailformular unterbringen, liest Du in diesem Artikel.

Bisher entstehen in unserer Rechnungsverwaltung nur Entwürfe: Die Rechnung hat einen Kunden, ein Datum und Positionen, aber keine Rechnungsnummer, und ihr Status lautet „Entwurf“. Irgendwann soll aus dem Entwurf eine echte Rechnung werden, die an den Kunden geht. Genau in diesem Moment braucht sie eine eindeutige, fortlaufende Nummer – und zwar eine, die sich an einem Jahr orientiert und keine Lücken reißt. Wie wir diesen Schritt mit einer eigenen Schaltfläche im Rechnungsformular umsetzen und wie die nächste freie Nummer zustande kommt, liest Du in diesem Artikel.

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.

Die Stammdaten stehen – Artikel und Kunden lassen sich bequem erfassen. Jetzt kommt das Herzstück der Anwendung: das Formular, mit dem eine Rechnung entsteht. Es ist das anspruchsvollste der Reihe, denn hier passiert zum ersten Mal etwas, das die Stammdatenformulare nicht kannten – wir rechnen. Ein Hauptformular nimmt Kunde und Datum auf, ein Unterformular die einzelnen Positionen, und ganz unten sollen Nettosumme, Mehrwertsteuer und Bruttobetrag erscheinen. Dabei zeigt sich ein Stolperstein, an dem selbstgebaute Rechnungen reihenweise scheitern. Wie das Rechnungsformular entsteht und wie wir dabei richtig rechnen, liest Du in diesem Artikel.

Im vorherigen Artikel haben wir die Artikel mit einem Formularpaar aus Übersicht und Detail ausgestattet. Genau dasselbe brauchen die Kunden – und weil die Struktur identisch ist, geht der Aufbau diesmal deutlich schneller. Wir können uns dafür auf die Stellen konzentrieren, an denen Kunden sich von Artikeln unterscheiden: Sie haben Nachschlagefelder für Anrede und Land, sie können Firmen oder Privatpersonen sein, und beim Löschen ist mehr Vorsicht geboten. Wie das Kundenformular entsteht, liest Du in diesem Artikel.

Das Datenmodell steht – jetzt geben wir ihm eine Oberfläche. Wir beginnen mit den Artikeln und bauen dafür ein Gespann aus zwei Formularen, das sich durch die ganze Reihe ziehen wird: eine Übersicht, die alle Artikel auflistet und durchsuchbar macht, und ein Detailformular, das einen einzelnen Artikel zum Bearbeiten anzeigt. Der Reiz liegt im Zusammenspiel der beiden – und in einem kleinen Trick, mit dem das Detailformular der Übersicht mitteilt, ob überhaupt etwas gespeichert wurde. Wie das gelingt, liest Du in diesem Artikel.

Mit diesem Artikel beginnen wir eine neue Reihe. Schritt für Schritt bauen wir eine vollständige Rechnungsverwaltung auf – mit Kunden, Artikeln, Rechnungen und Positionen, später mit Formularen zur Eingabe und Berichten für den Ausdruck. Bevor davon irgendetwas entstehen kann, brauchen wir ein tragfähiges Fundament: die Tabellen. Und gerade bei einer Rechnungsverwaltung ist das Fundament kein Nebenschauplatz, denn hier gelten Regeln, die eine einfache Adressverwaltung nicht kennt. Warum wir welche Tabelle, welches Feld und welchen Datentyp wählen – und warum manche Entscheidung anders ausfällt, als man zunächst denkt -, liest Du in diesem Artikel.