Kategorie: Lösungen

Eine Rechnung enthält nicht nur Angaben zum Kunden und zu den Positionen. Sie nennt auch den Absender mit Anschrift, die Steuernummer, die Bankverbindung, das Zahlungsziel und einen abschließenden Text. Diese Angaben stehen bisher nirgends in der Datenbank, und das Zahlungsziel von 14 Tagen ist fest im Code eingetragen. Für den Ausdruck der Rechnung, den wir in den folgenden Artikeln aufbauen, brauchen wir sie. Wie wir die Angaben in einer Tabelle mit genau einem Datensatz speichern, in einem Formular pflegen und für das Zahlungsziel verwenden, liest Du in diesem Artikel.

Die Rechnungen unserer Rechnungsverwaltung existieren bisher nur auf dem Bildschirm. Ein Formular eignet sich zum Erfassen, aber nicht für das Dokument, das der Kunde erhält. Dafür brauchen wir einen Bericht, der die Angaben des Absenders, die Anschrift des Kunden, die Positionen und die Summen je Steuersatz zu einem Rechnungsdokument zusammenstellt. Wie wir die Datensatzquelle dafür aufbauen und den Bericht Schritt für Schritt gestalten, liest Du in diesem Artikel.

Eine gestellte Rechnung soll den Kunden erreichen. Außerdem wollen wir sie als Datei ablegen, die sich nicht versehentlich ändern lässt. Beides leistet eine PDF-Datei. Wie wir den Bericht aus dem letzten Artikel per VBA-Prozedur als PDF-Datei mit der Rechnungsnummer im Dateinamen speichern und eine E-Mail mit dieser Datei als Anhang vorbereiten, 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.

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.

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.

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.

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.

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.

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.