Rechnungsstellung mit Access programmieren

Meine Selbstständigkeit als Softwareentwickler bringt neben dem Spaß und der Erfüllung, etwas geschaffen zu haben, naturgemäß ein paar weitere Aspekte, die nicht immer Spaß machen, jedoch zwingend notwendig sind. Die Rede dabei ist von Rechnungsstellung.

Ausgangslage

Eine Rechnung stellen zu dürfen, halte ich definitiv für eine feine Sache. Denn es bedeutet, dass ich einem Kunden Mehrwert geliefert und dadurch Umsatz generiert habe. Die tatsächliche Organisation und die Verwaltung der Rechnungen hingegen macht mir deutlich weniger Spaß. Am Anfang meiner Selbstständigkeit habe ich für das Schreiben von Rechnungen eine simple Wordvorlage genutzt, die ich dann jedes Mal neu mit den Daten befüllt habe.

Die Angaben zum Kunden mussten eingefügt, eine neue eindeutige Rechnungsnummer vergeben, sowie die ganzen Rechnungspositionen inklusive der Dauer aufgelistet werden. Anschließend habe ich dann, mit Excel bewaffnet, die Gesamtsumme ausgerechnet und das Zahlungsdatum festgelegt. Nach diesen Schritten war die Rechnung fertig. Vor dem Versand habe ich diese noch ins PDF-Format umgewandelt, per Email an den Kunden verschickt und für die Steuererklärung dann im jeweiligen Kundenordner auf dem Rechner abgelegt.

Alles in einem waren es viel zu viele manuelle Schritte, die gemacht werden mussten. Dabei lautet ja meine Philosophie und mein Anspruch, dass ich meinen Kunden helfe, ihre manuellen Prozesse möglichst komplett zu automatisieren. Dabei bin ich selber inkonsequent und habe noch bei meinen Prozessen in der Rechnungsstellung einiges zu verbessern. Das ist dann sowas ähnliches, wie wenn ein Schuster die schlechtesten Schuhe hat:-)

So war mir klar, dass das kein Dauerzustand sein konnte. Die wahrscheinlich schnellste und bequemste Lösung wäre es, auf eine Standardsoftware für die Rechnungsstellung zu setzen. Aber warum den einfachen Weg nehmen, dachte ich mir. Die Überlegung dahinter war, das Nützliche mit dem Spannenden zu verbinden und selber ein Programm zur Rechnungsstellung zu entwickeln.

Meine Anforderungen an das Programm zur Rechnungsstellung

Im Wesentlichen hatte ich drei Anforderungen an die zu entwickelnde Software:

• Kundenverwaltung (Adress- und Kommunikationsdaten, sowie Zahlungsmodalitäten
• automatisierter Prozess der Rechnungsstellung
• Verwaltung von Rechnungen und automatische Überwachung des Zahlungseingänge

Technische Vorüberlegungen

Aufgrund dieser Anforderungen stand die Architektur des Programms eigentlich schon fest – es sollte datenbankbasiert sein. Denn nur so würden sich die ganzen aktuellen und die künftigen Anforderungen mit vertretbaren Aufwand und technologisch sinnvoll realisieren lassen. Für mich wäre, glaube ich, nichts frustrierender, als eine relationale Datenhaltung ohne SQL, nur mit Excel zu programmieren.

Da ich ein Freund von einfachen Lösungen bin, habe ich mich gegen eine serverseitige Architektur entschieden und beschloss, dieses Programm mit Microsoft Access zu entwickeln.

Eine Herausforderung bestand darin, dass ich zwar im Studium relativ viel über Datenbanken gelernt und einige auch aufgebaut habe – jedoch nie mit Access. Aber was man noch nicht kann, kann man lernen. Also habe ich da 70 Euro in die Hand genommen, mir Access 2019 bei Microsoft bestellt, ein paar richtig gute Tutorials herausgesucht und schon konnte es losgehen.

Insgesamt hat es rund 2 Monate gedauert, bis das Programm soweit fertig war, dass ich darin alle Kundendaten erfassen und die mit Word geschriebenen Rechnungen migrieren konnte. Die lange Entwicklungszeit ergab sich zum einen aus der Tatsache, dass ich einige Sachen erst lernen musste. Zum anderen habe am Programm nur zwischen meinen Aufträgen arbeiten können, immer dann, wenn etwas Zeit da war. In einigen Wochen konnte ich so nur wenige Features fertigstellen.

Datenmodell der Datenbank

Um ein Gefühl für die Datenhaltung und die Datenorganisation zu bekommen, ist das Datenmodell echt hilfreich. Die Experten unter den Lesern mögen mir bitte verzeihen, dass ich mich während der Entwicklung nicht immer strikt an die 3. Normalform des Datenbankdesigns gehalten habe 🙂 Mittlerweile habe ich bereits einige Neuerungen realisiert und das Datenmodell deutlich weiterentwickelt. Dennoch habe ich noch nicht das Gefühl fertig zu sein – meine OneNote-Liste mit den ToDo’s (neue Features und Verbesserungen bestehende Features) wird gefühlt mit jeder Version immer länger.

Rechnungsbeispiel

In diesem Kapitel möchte ich kurz zeigen, wie nun eine konkrete Rechnung aussieht. Hierzu habe ich auf der Testumgebung einen neuen fiktiven Kunden angelegt – vielleicht erkennt man dies schon an der Namensgebung – und eine Rechnung für ihn erfasst.

Die Rechnungsstellung mit meinem neuen Programm ist wirklich denkbar einfach. Ich wähle den Kunden in der Auswahlmaske aus, für den die Rechnung gelten soll. Anschließend hinterlege die einzelnen Rechnungspositionen sowie deren Dauer. Dieser Schritt lässt sich nun wirklich nicht automatisieren. Das Programm kann ja nicht wissen, wie lange ich an was gearbeitet habe:-). Im Screenshot sind diese einzugebenden Daten blau hervorgehoben.

Alle anderen Angaben, die mit dem roten Rahmen markiert sind, werden entweder aus der Datenbank gezogen, bzw. automatisch berechnet. Dazu gehören die Kundenanschrift, die eindeutige Rechnungsnummer, die Beträge für die einzelnen Positionen sowie deren Gesamtsumme und das Zahlungsdatum. Die nicht umrahmten Daten sind in jeder Rechnung fest hinterlegt und brachen nicht eintippt zu werden.

Die fertige Rechnung wird im Programm im PDF-Format angezeigt. Die überfliege ich kurz, ob alles soweit passt und drücke dann einfach auf den Knopf zum Versenden. Dazu brauche ich die Emailadresse des Kunden nicht herauszusuchen, genauso wenig mein Outlook zu starten. Im Rechnungsprogramm wird dies alles im Hintergrund automatisch erledigt. Sobald die Rechnung verschickt ist, stellt das Programm den Rechnungsstatus vom „Entwurf“ auf „versendet“ um und sperrt somit die Rechnung für die weitere Bearbeitung – diese öffnet sich ab jetzt nur noch im PDF-Format.

Überwachung des Geldeingangs

Jedes Mal, wenn das Rechnungsprogramm geöffnet wird, ermittelt es im Hintergrund, welche Rechnungen noch nicht beglichen wurden. Anschließend liest das Programm die aktuelle Camt53-XML-Datei meines Kontos ein(die ich regelmäßig aus meiner BankingApp heraus ins OneDrive exportiere), ob zu den offenen Rechnungen bereits Zahlungen eingetroffen sind. Dabei fungiert die Rechnungsnummer als Referenz, nach der die Buchungen durchsucht werden.

Konnte zu einer offenen Rechnung die Buchung ermittelt werden, so springt der Status der Rechnung dann auf „bezahlt“ um. Liegt nach dem Ablauf der Zahlungsfrist immer noch keine Überweisung vor, springt der Status auf „überfällig“ um, sodass ich mir diese Fälle dann näher anschaue. Bisher lag es zum Glück immer daran, dass der Geldeingang zwar schon da war, jedoch nicht der passenden offenen Rechnung zugeordnet werden konnte. In diesen Fällen gab es in der Regel einen Zahlendreher bei der Kundenüberweisung.

An der Stelle werde ich mir eine schlaue Lösung überlegen, wie diese Fälle automatisiert erkennen kann. Eine mögliche Lösung könnte sein, dass das Programm nicht nur nach der Rechnungsnummer „schaut“, sondern auch Beträge und Kundennamen mit einbezieht. Da die Beträge eigentlich immer unterschiedlich und krumm sind, sind die in Verbindung mit dem Kundennamen als eindeutig zu betrachten. So kann das Programm diese für die Zahlungszuordnung zu den noch offenen Rechnungen verwenden.

Zeitersparnis und besseres Handling

Ein Vorteil des neuen Programms liegt darin, dass alle Rechnungen aller Kunden sich in diesem Programm befinden, welches aus einer einzigen Access-Datei besteht (um genau zu sein, sind es zwei Dateien, nämlich eine Frontend- und eine Backenddatei). So lässt sich die Datenbank sehr einfach und bequem sichern. Es ist deutlich bequemer, als bisher, wo ich die Rechnungen in Kundenverzeichnissen abgelegt habe.

Der letzte wichtige Punkt ist die enorme Zeitersparnis und die Eliminierung Fehlerquellen (wenn man sich beim Zusammenrechnen vertippt oder beim Datenübertragen nicht aufpasst). Natürlich habe ich für die Entwicklung des Programms viel Zeit investiert und es dauert vermutlich echt lange, bis ich dies durch die Zeitersparnis wieder kompensiert habe. Aber ich habe nicht vor, diese Entwicklungszeit gegen die Zeitersparnis aufzuwiegen, denn es war eine Investition, oder auch wenn man so will ein „Research And Development-Projekt“ und darüber hinaus auch Spaß gemacht – was will man mehr 🙂