Rechnungsverwaltung: Das Rechnungsformular

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.

Beispieldatenbank

Die Beispiele dieses Artikels findest Du in der Datenbank Rechnungsverwaltung_DasRechnungsformular.accdb.

Der Aufbau: Haupt- und Unterformular

Eine Rechnung besteht aus zwei Ebenen: dem Rechnungskopf mit Kunde, Datum und Status – das ist ein Datensatz aus tblRechnungen – und den einzelnen Positionen darunter, die aus tblRechnungspositionen stammen.

Genau diese Struktur bilden wir mit einem Haupt- und einem Unterformular ab: Das Hauptformular zeigt den Kopf, das Unterformular die Positionen.

Wie das grundsätzlich funktioniert, zeigt der Artikel Formulare [basics]: 1:n-Daten in Haupt- und Unterformular (www.access-basics.de/648). Der Benutzer wählt oben den Kunden und trägt unten Position für Position ein (siehe Bild 1).

Bild 1: Das fertige Rechnungsformular mit Kopfdaten, Positionsliste und Summenbereich

Das Hauptformular

Wir legen ein Formular frmRechnung an und binden es an tblRechnungen. In den Detailbereich ziehen wir die Kopffelder: das Nachschlagefeld KundeID, das Rechnungsdatum, das Faelligkeitsdatum und das Nachschlagefeld RechnungsstatusID. Die Rechnungsnummer zeigen wir ebenfalls an – sie bleibt vorerst leer, denn eine Rechnung im Entwurf hat noch keine Nummer.

Auch hier profitieren wir von den Nachschlagefeldern aus dem Datenmodell: KundeID und RechnungsstatusID erscheinen automatisch als Kombinationsfelder. Beim Kundenfeld ist das besonders angenehm – der Benutzer wählt den Kunden aus einer Liste, statt eine ID einzutippen (siehe Bild 2).

Bild 2: Auswahl des Kunden per Kombinationsfeld

Kunden komfortabel auswählen

Hier ist allerdings noch ein wenig Nacharbeit nötig. In der Tabellendefinition haben wir das Feld KundeID so angelegt, dass das Nachschlagefeld an das Feld KundeID der Tabelle tblKunden gebunden ist und den Wert des Feldes Firma anzeigt.

Das ist nicht immer hilfreich, denn es kann auch Kunden geben, für die keine Firma hinterlegt ist. Hier haben wir beispielsweise die folgenden Alternativen:

• Wir prüfen, ob eine Firma vorhanden ist. Falls ja, zeigen wir diese an, falls nicht, zeigen wir den Vornamen und Nachnamen des Kunden.
• Oder wir liefern immer den Namen des Kunden und, falls vorhanden, dahinter den Namen der Firma in Klammern.

In diesem Fall entscheiden wir uns für die erste Variante. Dazu bearbeiten wir die Eigenschaft Datensatzherkunft des Kombinationsfeldes. Am einfachsten gelingt das über die Schaltfläche mit den drei Punkten rechts neben der Eigenschaft: Sie öffnet den Abfrage-Generator, in dem wir die folgende Abfrage zusammenstellen:

SELECT tblKunden.KundeID, Nz([Firma],[Nachname] & ", " & [Vorname])     AS Kunde FROM tblKunden;

Die Abfrage prüft mit der Funktion Nz, ob das Feld Firma den Wert Null enthält, also leer ist. Ist das nicht der Fall, wird der Wert des untersuchten Feldes zurückgegeben, andernfalls der Wert des zweiten Parameters der Nz-Funktion (siehe Bild 3).

Bild 3: Einrichten des Kombinationsfeldes zur Auswahl des Kunden

Nun kann es allerdings sein, dass wir die Eigenschaft Leere Zeichenfolge für das Feld Firma aktiviert haben oder hatten und dass sich nicht nur Null-Werte, sondern auch leere Zeichenfolgen im Feld Firma befinden. Ist das der Fall, liefert unser Ausdruck eine leere Zeichenfolge und nicht den Namen des Kunden. Um dies zu umgehen, erweitern wir den Ausdruck wie folgt: