Rechnungsstellung mit QR-Codes

In einem meiner letzten Artikel zum Thema Rechnungsstellung habe ich erwähnt, dass manche Kundenüberweisungen aufgrund von Zahlendrehern bei den Rechnungsnummern nicht automatisiert zuordenbar sind. Dazu habe ich mir auch mögliche Alternativen überlegt, wie ich die Zuordnungsquote erhöhen kann.

Projektbeginn

Eines Tages las ich zufälligerweise einen Artikel über QR-Codes, die vor allem im Paymentbereich in der Schweiz sehr verbreitet sind und eine Menge Vorteile bieten. Da kam mir die Idee, die QR-Code-Technologie ebenfalls für die Weiterentwicklung meines Rechnungsprogramm einzusetzen und so die Rechnungen automatisch mit QR-Codes auszustatten. Beim Einscannen des Codes aus der BankingApp heraus werden alle Daten ins Überweisungsformular automatisch übernommen, sodass die Überweisung nur noch zu kontrollieren und freizugeben ist. Davon würden beide Seiten profitieren – meine Kunden könnten sich das Abtippen oder Kopieren der Überweisungsdaten sparen und ich hätte dann keine Zuordnungsprobleme bei Überweisungen.

Auch hier stand ich dann vor dem Start vor der Überlegung, ob ich eine der verfügbaren freien Bibliotheken für die Erzeugung von QR-Codes nutzen möchte. Man sagt ja, es gibt keinen Grund, das Rad nochmal zu erfinden:-). Und normallerweise stimme ich dem auch zu, es sei denn, man betrachtet das ganze aus einer anderen Perspektive – kurz gesagt, getrieben vom Forschungsdrang entschied ich mich dafür, den QR-Code-Generator selbst zu programmieren.

Informationsbeschaffung

Bei der Recherche zum Thema QR-Codes wurde schnell klar, dass viele Webseiten es relativ oberflächlich behandeln und nur einen groben Überblick über die Struktur, Aufbau und Funktionsweise geben, ohne jedoch stark in die Tiefe zu gehen. Es war also absehbar, dass ich für die komplexeren Teilgebiete, wie zum Beispiel Fehlerkorrektur von QR-Codes ganz andere Informationstiefe benötige. Dazu bin ich erst im englischsprachigen Raum fündig geworden (www.thonkey.com). In diesem Tutorial QR Code Tutorial – Thonky.com habe ich alles gefunden, wonach ich gesucht habe.

Architektur und Technologie

Obwohl ich den QR-Code-Generator eigentlich nur für den Einsatz in der ACCESS-Rechnungsdatenbank (also in der VBA-Welt) vorgesehen habe, entschied ich mich, diesen nicht als ein VBA-Modul oder Add-In, sondern als eine Klassenbibliothek mit C# zu entwickeln. Eine allgemeine Klassenbibliothek hätte den Charme, dass sich diese auch in eine Consolen- oder auch in eine GUI-Anwendung integrieren ließe. Auch die geplante Verwendung aus der VBA-Welt heraus wäre durch die COM-Technologie ebenfalls möglich.

Implementierung

Am Anfang des Projektes habe ich relativ schnell die ersten Erfolge erzielt und die statische Grundstruktur und Funktionalität aufgebaut. So war die Klasse in der Lage, anhand des übergebenen Textes und des gewählten Korrekturlevels die benötigte Matrixgröße zu errechnen und die ganzen Pattern (Finderpattern, Alignmentpattern, Timingpattern) in der Matrix abzubilden und dann als ein Bild zu visualisieren. Mathematisch und programmiertechnisch war dies relativ einfach zu bewerkstelligen.

Das nächste Teilgebiet hingegen forderte mich so richtig heraus. Es ging dabei um die Erzeugung von Fehlerkorrekturcodes. QR-Codes können nämlich auch dann eingescannt und dekodiert werden, wenn ein gewisser Teil des Codes nicht lesbar oder einfach nur verschmutzt ist. Bei dem höchsten Fehlerkorrkturlevel können bis zu 30% des QR-Codes verschmutzt sein, ohne dass es zum Problem beim Dekodieren kommt. Diese Fehlerkorrekturen werden, aus meiner Sicht als Nichtmathematiker, nach einem sehr komplizierten Verfahren, namens Reed-Solomon-Verfahren (benannt nach zwei Überfliegern von der MIT) generiert. Für die interessierten Leser habe ich den entsprechenden Wikipedia-Artikel hier verlinkt. Reed-Solomon-Code – Wikipedia

Ohne die ausführlichen und für die Nichtdoktoren der Mathematik aufbereiteten Informationen aus dem oben genannten Tutorial hätte ich, glaube ich, dieses Teilgebiet nicht umsetzen können. Allerdings auch die vereinfacht dargestellte Logik in den Code zu gießen, war nicht ohne – wie oft hat man schon als Anwendungsentwickler eine Methode für die Polynomdivision zweier Gleichungen 78en Grades zu programmieren 🙂

Das letzte Teilgebiet mit der Darstellung der kodierten Daten in der Matrix und deren Maskierung für ein besseres maschinelles Einscannen war dann wiederum verglichen mit dem vorherigen Teil schon fast einfach. Das hat mich auch richtig motiviert, dass ich den komplizierten Teil schon hinter mir habe und kurz vor der Fertigstellung stehe.

Und dann kam das Testen:-)

Testen

Einem QR-Code sieht man mit unbewaffnetem Auge in der Regel nicht an, ob es richtig aufgebaut ist. Für den Schnelltest nutzte ich dabei mein Handy – beim Einscannen hatte ich dann direkt die Rückmeldung, ob der QR-Code richtig war oder zumindest eingescannt werden konnte. Wenn jedoch der erzeugte QR-Code nicht lesbar war, dann ging die Suche nach dem Fehler erst richtig los. Einen richtig guten Dienst hat mir dabei diese Webseite geleistet. Creating a QR Code step by step (nayuki.io). Im Gegensatz zu anderen Webseiten, wo man selbst QR-Codes generieren kann, erlaubt der Autor hier auch einen Blick unter die Oberfläche. So ist es zum Beispiel möglich, sich die generierten Korrekturwörter oder die Penalyscores der einzelnen Masken anzeigen zu lassen. Dadurch war es mir möglich, zumindest ganz grob den Fehler zu lokalisieren und dann in den unzähligen Stunden mit dem Debugger ausfinden zu machen und zu reparieren. Der Löwenanteil aller Fehler lag in der Klasse für die Erzeugung der Fehlerkorrekturcodes – war bei deren Komplexität auch nicht weiter verwunderlich, aus sprachlicher Sicht dennoch amüsant:-) Alle anderen Klassen waren da deutlich robuster und wiesen kaum Fehler auf.

Projektergebnis

Herausgekommen ist aus diesem Projekt wie erwähnt eine Klassenbibliothek. Ein Objekt der Klasse wird durch den Konstruktor erzeugt. Diesem übergibt man den zu verschlüsselnden Text sowie den Fehlerkorrekturlevel. Anschließend stehen 4 Ausgabemethoden zur Verfügung.

  1. GetQRCodeMatrix() – Die Ausgabe des QR-Code als Matrix
  2. SaveAsSVG() – Die Ausgabe des QR-Codes als SVG-Datei (Vektorgrafik)
  3. SaveAsJpeg() – Die Ausgabe des QR-Codes als JPEG-Datei (Pixelgrafik)
  4. GetJpegAsByteArray() – Die Ausgabe des QR-Codes als JPEG-Byte-Array

Um diese Klasse auch unter ACCESS nutzen zu können, war es erforderlich, diese in eine weitere Klasse zu packen, welche die COM-Schnittstelle implementiert.

Die Anbindung an das ACCESS-Rechnungsprogramm sieht so aus, dass bei der Erstellung der Rechnung, der zu verschlüsselnde Inhalt an den Konstruktor übergeben wird. Der Inhalt hat einen vordefinierten Aufbau, der vom EPC-QR definiert wird EPC-QR-Code – Wikipedia. Darin ist meine IBAN, mein Name, sowie der Rechnungsbetrag und die Rechnungsnummer enthalten. Sobald ein Objekt mit Hilfe dieses Inhaltes fertig ist, ruft das Rechnungsprogramm die 4. Methode auf. Diese Methode liefert als Output den JPEG-Bild in Form eines ByteArray zurück, welches dem Bildcontainer (dem Attribut pictureData um genau zu sein) im Rechnungsbericht zugewiesen wird. Diese Zuweisung bewirkt, dass auf der Rechnung der QR-Code dargestellt wird

Die anderen Methoden werden momentan für das ACCESS-Rechnungsprogramm nicht gebraucht – jedoch sind die für andere Einsatzzwecke sinnvoll, wenn es beispielsweise darum geht, QR-Codes aus anderen Programmen heraus zu erzeugen. Die Klassenbibliothek lässt sich auch von einer Consolenanwendung oder von einer GUI-Anwendung aufrufen.

1 thought on “Rechnungsstellung mit QR-Codes

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.