<\/p>\n
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.<\/p>\n
Die Beispiele dieses Artikels findest Du in der Datenbank Rechnungsverwaltung_DasRechnungsformular.accdb<\/b>.<\/p>\n
Eine Rechnung besteht aus zwei Ebenen: dem Rechnungskopf mit Kunde, Datum und Status – das ist ein Datensatz aus tblRechnungen<\/b> – und den einzelnen Positionen darunter, die aus tblRechnungspositionen<\/b> stammen.<\/p>\n
Genau diese Struktur bilden wir mit einem Haupt- und einem Unterformular ab: Das Hauptformular zeigt den Kopf, das Unterformular die Positionen.<\/p>\n
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).<\/p>\n
Bild 1: Das fertige Rechnungsformular mit Kopfdaten, Positionsliste und Summenbereich<\/p>\n Wir legen ein Formular frmRechnung<\/b> an und binden es an tblRechnungen<\/b>. In den Detailbereich ziehen wir die Kopffelder: das Nachschlagefeld KundeID<\/b>, das Rechnungsdatum<\/b>, das Faelligkeitsdatum<\/b> und das Nachschlagefeld RechnungsstatusID<\/b>. Die Rechnungsnummer<\/b> zeigen wir ebenfalls an – sie bleibt vorerst leer, denn eine Rechnung im Entwurf hat noch keine Nummer.<\/p>\n Auch hier profitieren wir von den Nachschlagefeldern aus dem Datenmodell: KundeID<\/b> und RechnungsstatusID<\/b> 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).<\/p>\n Bild 2: Auswahl des Kunden per Kombinationsfeld<\/p>\n Hier ist allerdings noch ein wenig Nacharbeit nötig. In der Tabellendefinition haben wir das Feld KundeID <\/b>so angelegt, dass das Nachschlagefeld an das Feld KundeID <\/b>der Tabelle tblKunden <\/b>gebunden ist und den Wert des Feldes Firma <\/b>anzeigt.<\/p>\n 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:<\/p>\n In diesem Fall entscheiden wir uns für die erste Variante. Dazu bearbeiten wir die Eigenschaft Datensatzherkunft <\/b>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:<\/p>\n Die Abfrage prüft mit der Funktion Nz<\/b>, ob das Feld Firma <\/b>den Wert Null <\/b>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<\/b>-Funktion (siehe Bild 3).<\/p>\n Bild 3: Einrichten des Kombinationsfeldes zur Auswahl des Kunden<\/p>\n Nun kann es allerdings sein, dass wir die Eigenschaft Leere Zeichenfolge <\/b>für das Feld Firma <\/b>aktiviert haben oder hatten und dass sich nicht nur Null<\/b>-Werte, sondern auch leere Zeichenfolgen im Feld Firma <\/b>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:<\/p>\n Wir holen also mit Nz <\/b>entweder den Namen der Firma oder, wenn dieser Null <\/b>ist, eine leere Zeichenfolge. Sollte Firma <\/b>selbst eine leere Zeichenfolge sein, liefert Nz <\/b>diese als Ergebnis. Das Ergebnis vergleichen wir mit einer leeren Zeichenfolge („“<\/b>). Ist der Vergleich wahr, ist das Feld Firma <\/b>entweder leer oder eine leere Zeichenfolge – in diesem Fall soll der Kunde als [Nachname] & „, “ & [Vorname] <\/b>zurückgegeben werden. Anderenfalls erhalten wir den Namen der Firma zurück – zum Beispiel wie in Bild 4.<\/p>\n Bild 4: Firma oder Name des Kunden<\/p>\n Die Positionen zeigt ein Unterformular in der Datenblattansicht. Wir erstellen ein Formular sfmRechnungspositionen<\/b>, binden es an tblRechnungspositionen<\/b> und nehmen die Felder auf, die eine Position ausmachen: Positionsnummer<\/b>, das Nachschlagefeld ArtikelID<\/b>, Positionsbezeichnung<\/b>, Menge<\/b>, EinzelpreisNetto<\/b> und Umsatzsteuersatz<\/b>.<\/p>\n Das Feld ArtikelID<\/b> und die Positionsbezeichnung<\/b> stehen dabei bewusst nebeneinander – warum, klärt sich gleich. Die Standardansicht des Formulars stellen wir auf Datenblatt<\/b>. Eine Spalte fehlt noch, und sie ist die erste, die berechnet wird: der Positionsbetrag. Menge mal Einzelpreis ergibt den Nettowert der Zeile. Diesen Wert speichern wir nicht – er lässt sich jederzeit aus Menge und Preis errechnen. Die Felder RabattProzent und RabattBetragNetto aus tblRechnungspositionen lassen wir dabei vorerst außen vor – Rabatte behandeln wir in einem späteren Artikel der Reihe. Wir fügen dem Unterformular dafür ein ungebundenes Textfeld txtPositionsbetrag<\/b> hinzu und tragen als Steuerelementinhalt ein:<\/p>\n Für dieses Feld legen wir außerdem noch die Eigenschaft Format auf Währung fest.<\/p>\n Das Unterformular sieht nun wie in Bild 5 aus.<\/p>\n Bild 5: Berechnung des Positionsbetrags<\/p>\n Warum wollen wir den Positionsbetrag nicht speichern? Weil ein gespeicherter Wert veralten kann. Ändert jemand die Menge, müsste man daran denken, auch den gespeicherten Betrag nachzuführen – vergisst man es, stehen falsche Zahlen in der Datenbank. Ein berechneter Wert kann gar nicht veralten, weil er in dem Moment entsteht, in dem man ihn anschaut. Diese Überlegung zieht sich durch den ganzen Artikel: Wir speichern keine Summen, wir berechnen sie.<\/p>\n Das Unterformular ziehen wir nun in den Detailbereich von frmRechnung<\/b>. Access erkennt die Beziehung zwischen tblRechnungen<\/b> und tblRechnungspositionen<\/b> über das Feld RechnungID<\/b> und trägt Verknüpfen von<\/b> und Verknüpfen nach<\/b> selbständig ein (siehe Bild 6). So zeigt das Unterformular immer nur die Positionen der gerade angezeigten Rechnung.<\/p>\n Bild 6: Einfügen des Unterformulars in das Hauptformular<\/p>\n Damit das Unterformular seine Größe anpasst, wenn wir das Hauptformular vergrößern, stellen wir seine Eigenschaften Horizontaler Anker <\/b>und Vertikaler Anker <\/b>auf Beide <\/b>ein. Für das Bezeichnungsfeld müssen wir diese Eigenschaften anschließend wieder auf Links <\/b>und Oben <\/b>einstellen.<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>![\"Das](\"..\/tl_files\/images\/pic_722_012.png\")
<\/a><\/p>\nDas Hauptformular<\/h2>\n
<\/a><\/p>\nKunden komfortabel auswählen<\/h2>\n
\n
SELECT tblKunden.KundeID, Nz([Firma],[Nachname] & \", \" & [Vorname]) AS Kunde FROM tblKunden;<\/pre>\n
<\/a><\/p>\nKunde: Wenn(Nz([Firma];\"\")=\"\";[Nachname] & \", \" & [Vorname];[Firma])<\/pre>\n
<\/a><\/p>\nDas Unterformular mit den Positionen<\/h2>\n
=[Menge]*[EinzelpreisNetto]<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t