Die elektronische Rechnungsstellung ist ein entscheidender Schritt in Richtung moderner und effizienter Unternehmensprozesse. Mit vbaXrechnung können Softwareentwickler ihre VBA-Anwendung dafür fit machen.
Wie das geht demonstriere ich anhand der Umstellung meiner eigenen Anwendung. Dabei zeige ich praxisnah, wie die Integration funktioniert, und gebe Tipps, um den Einstieg zu erleichtern.
Vorbereitung
Die Umstellung auf elektronische Rechnungen erfordert eine sorgfältige Vorbereitung, um Enttäuschungen und Frustration zu vermeiden. Auch wenn die Vorteile schnell überzeugen und alles einfach erscheint, zeigt sich in der Praxis, dass das Thema komplexer ist.
Ich selbst habe mehr als sechs Monate damit verbracht, mich intensiv mit der Elektronischen Rechnung im Allgemeinen und der XRechnung im Besonderen auseinanderzusetzen. Dieses Wissen möchte ich nun mit Ihnen teilen, um Ihnen den Einstieg zu erleichtern. Der wichtigste Schritt dabei ist, sich auf die elektronische Rechnung einzulassen und deren Grundkonzept wirklich zu verstehen. Sobald dieses Verständnis vorhanden ist, werden die weiteren Schritte deutlich einfacher.
Nach der Einarbeitung in die Grundlagen steht die Entwicklung eines strukturellen Konzepts an. Dies legt den Grundstein für eine erfolgreiche Integration der elektronischen Rechnungsstellung in Ihre Anwendung. Gehen wir diesen Weg gemeinsam!
Elektronische Rechnung
Grundkonzept
Die Elektronische Rechnung ist eine xml-Datei, die entweder der Syntax Cross Industry Invoice (CII) oder der Syntax Universal Business Language (UBL) entspricht. Die notwendigen Elemente wurden in der Europäischen Norm EN 16931 festgelegt. Für die Spezifikation XRechnung wurden die Vorgaben der EN 16931 spezifiziert.
Struktur
Bei der Entwicklung von vbaXrechnung habe ich mich an der Spezifikation Standard XRechnung orientiert. Ich empfehle jedem ganz dringend, sich mit dem Dokument – zumindest oberflächlich – vertraut zu machen. Bei der Umstellung Ihrer Anwendung müssen Sie dort manchmal reinschauen.
Die Lesehilfe in Kapitel 7 (Seite 16 ) ist ein Muss für das weitere Verständnis. Für die Entwicklung wird es dann ab Seite 25 interessant.
Abbildung 9.1 in Kapitel 9 vermittelt einen Eindruck über die Struktur
Die Struktur ähnelt einem Datenbankschema. Die Begriffe INVOICE, SELLER, BUYER etc. entsprechen dabei Tabellen, die in einer Beziehung zueinander stehen.
Die Beziehung zwischen den jeweiligen Objekten ist durch die Kardinalitäten definiert, die in der Lesehilfe in Kapitel 7 beschrieben wurde.
- 0..* – es kann unendlich viele Details geben
- 1 – es muss genau ein Detail geben
- 1..* – es muss mindestens ein Detail geben
- 0..1 – es kann genau ein Detail geben
Abbildung 9.2 ist der Versuch einer Gesamtabbildung einer XRechnung. Sie ist sehr unübersichtlich, dehalb verzichte ich auf das Bild.
vbaXrechnung
Struktur
Bei vbaXrechnung gibt es für jedes Objekt aus der Struktur eine Klasse, die alle Daten zu dem Objekt aufnehmen kann. Die Klasse für INVOICE bildet somit eine komplette Elektronische Rechnung ab. Dieses Objekt INVOICE kann über Adapter in andere Objekte konvertiert werden, z.B. ein Cross Industry Invoice kompatibles xml-DOM.
Die Klassen können alle mit VBA anprogrammiert und mit Daten gefüllt werden. Die Werte aus den Klassen können über Adapter auch in passende Tabellen gespeichert oder umgekehrt aus den Tabellen ins Klassenmodell geladen werden.
Konventionen
Bei der Entwicklung von vbaXrechnung und der Beispieleanwendung habe ich mich an einige Namenkonventionen gehalten, damit die Orientierung innerhalb der ganzen Objekte einfacher ist.
- alle Objekte von vbaXrechnung beginnen mit dem Präfix vbax_
Dadurch sollen Namenskonflikte beim Einsatz in anderen Anwendungen verhindert werden. - Feldnamen in Tabellen haben immer einen Präfix mit drei Buchstaben, der sich immer auf die jeweilige Tabelle bezieht.
Derselbe Präfix darf nicht in zwei verschiedenen Tabellen verwendet werden. Dadurch kann man am Feldnamen erkennen aus welcher Tabelle er kommt. - Jede Tabelle hat standardmäßig folgende vier Spalten: TBL_ID, TBL_CREATE, TBL_UPDATE, TBL_DELETE
Für vbaXrechung werde sie zwar nicht unbedingt benötigt, aber ich habe mich an diese Aufbau gewöhnt. - Eine Fremdschlüssel in einer Tabelle bekommt als Namen den Präfix der eigenen Tabelle veknüpft mit dem Primärschlüssel der anderen Tabelle.
Auf Drittkomponenten wird weitestgehend verzichtet, um möglichst keine Abhängigkeiten zu anderen Projekten zu haben. Zur Laufzeit wird lediglich ADODB benötigt. Beim Konvertieren von Dateien in einen Base64 codierten String kann eine eigene Methode verwendet werden. Die ist nicht allzu performant, daher gibt es den zusätzlichen Weg über die MSXML.dll.