In diesem Beispiel wird der EPC-QR-Code immer auf der Seite der Rechnung gedruckt, auf der auch der Rechnungsbetrag steht. Wenn es gewünscht sein sollte, dass der QR-Code auf einer anderen Seite gedruckt wird, müssen die für den QR-Code benötigten Daten erst einmal über einen vorgeschalteten Dokumentenprozess aufgesammelt werden. So könnte der QR-Code auf Seite 1 einer mehrseitigen Rechnung stehen, obwohl der Rechnungsbetrag erst auf Seite 3 steht.
EPC-QR / Girocode
Auf vielen Rechnungen insbesondere im B2C-Bereich sind inzwischen QR-Codes eingedruckt, die das Begleichen der Rechnung vereinfachen sollen, indem eine entsprechend ausgerüstete Banking-App diesen QR-Code liest, und damit alle Daten zur Ausführung einer SEPA-Überweisung kennt. Die Zahlung muss nur noch freigegeben werden.
Dieser QR-Code ist technisch ein QR Code Modell 2 und kann daher von print2forms ohne weiteres erzeugt und in eine Rechnung integriert werden.
Lediglich der Inhalt des QR-Codes unterliegt einer vom European Payments Council (EPC) herausgegebenen Spezifikation (in Englisch), um so die Interoperabilität zwischen den beteiligten Kreditinstituten sicherzustellen. Der so spezifizierte QR-Code hat offiziell den Namen EPC-QR-Code. Der EPC-QR-Code wird innerhalb Deutschlands teils GiroCode genannt, eine Marketing-Bezeichnung eines Dienstleisters der Sparkassen.
|
Wenn in print2forms ein Barcode gedruckt werden soll, muss dessen Inhalt in Form einer sogenannten Schablone innerhalb eines Barcodefeldes (Bestandteil eines Formulars) beschrieben werden. Da der Inhalt des Barcodes in den seltensten Fällen konstant ist, wird sich der Inhalt in der Regel aus irgendwelchen Nutzdaten zusammensetzen, die im Barcodefeld selbst oder in Suchfeldern ermittelt wurden. Die Schablone enthält deshalb eine oder mehrere Referenzen auf Nutzdaten.
Diese Rechnung wurde mit Hilfe einer Office-Suite als Text-Dokument erzeugt. Diese Rechnung ist auch die Basis für die beiden Tips XRechnung 3.0.1 und Factur-X 1.0 aka ZUGFeRD 2.2. |
|
Realisierung
Ein erster Schritt zur Realisation ist der, erst einmal den konkreten Inhalt eines EPC-QR-Codes für den eigenen Anwendungsfall zu ermitteln. Dazu werden die in der Spezifikation enthaltenen Tabellen einmal ausgefüllt:
| Feld | Wert | Beschreibung |
|---|---|---|
| Service Tag | 'BCD' | fester Wert |
| Version | '001' | die BIC wird immer mit angegeben |
| Character Set | '2' | wegen besserer Akzeptanz von 'ISO 8859-1' |
| Identification | 'SCT' | fester Wert 'SEPA Credit Transfer' |
| BIC | 'PBNKDEFF' | fester Wert für konkreten Rechnunsaussteller |
| Name | 'Lieferant GmbH' | fester Wert für konkreten Rechnunsaussteller |
| IBAN | 'DE08700901001234567890' | fester Wert für konkreten Rechnunsaussteller |
| Amount | 'EUR75.39' | Währung und Rechnungsbetrag mit zwei Nachkommastellen |
| Purpose | 'GDDS' | fester Wert für die Lieferung von Waren |
| Remittance Reference | wird nicht genutzt wegen nachfolgendem Text | |
| Remittance Text | 'RE 471102 KD 202011' | Verwendungszweck der Überweisung |
| Information | Information für Empfänger, wird nicht genutzt |
Es wird ganz schnell klar, dass ein Grossteil der Inhalte Konstante sind, und eigentlich nur der Rechnungsbetrag und für den Verwendungszweck die Rechnungsnummer, sowie die Kundennummer aus dem zu druckenden Dokument ermittelt werden müssen.
Um diese variablen Daten aus dem Druckdatenstrom abgreifen zu können, ist ein Blick in die von print2forms erstellte Kontrolldatei notwendig. Nachfolgend zum besseren Verständnis zwei Ausschnitte mit den hier interessierenden Abschnitten dieser Datei:
... [01012D0605]Rechnungsnummer [01012D0846]471102 [0101720605]Rechnungsdatum [0101720846]05.06.2018 ... [0102410605]Kundennr [0102410846]202011 ... |
... [010D1A00C6]Rechnungssumme Netto (exkl. USt.) [010D1A0889]63,35 EUR [010D5F00C6]zzgl. 19% Umsatzsteuer [010D5F0889]12,04 EUR [010DA400C6]Rechnungssumme Brutto (inkl. USt.) [010DA40889]75,39 EUR [010E2E00C6]Zahlungsinformation: ... |
Da insgesamt drei Informationen gebraucht werden, müssen auch mindestens drei Felder in ein Formular zum Eindruck des EPC-QR-Codes aufgenommen werden. Eines davon ist in jedem Fall das Barcodefeld selbst, die beiden anderen sind Suchfelder. Im Beispiel hier wird noch ein zusätzliches Textfeld zur Beschreibung des EPC-QR-Codes ergänzt.
|
|
Als erstes wird ein Suchfeld für die Kundennummer angelegt. Dieses Feld sammelt an der entsprechenden Stelle im Druckdatenstrom alle Ziffern am Anfang des Textes ein. Als nächstes wird ein zweites Suchfeld für die Rechnungsnummer angelegt. Auch dieses Feld sammelt an der entsprechenden Stelle im Druckdatenstrom alle Ziffern am Anfang des Textes ein. Das als drittes angelegte Barcodefeld prüft den Rechnungsbetrag. Im Gegensatz zu den beiden vorherigen Feldern ist keine feste Seite als Index angegeben, weil der Rechnungsbetrag bei mehrseitigen Rechnung auf einer der Folgeseiten notiert ist. 1) Ausserdem ist am Index auffällig, dass für die horizontale Position ein Bereich angegeben wird. Dazu muss man sich klar machen, dass beim Ausdrucken der Rechnung die Positionierung des Rechnungsbetrags natürlich von dessen Betragshöhe abhängig ist. Je nach Anzahl der Vorkommastellen variiert demzufolge die als Index ausgelesene horizontale Position. Mit der Angabe eines entsprechenden Bereichs können so auch variabel lange Beträge erkannt und aufgesammelt werden. 2) Am Vergleichsmuster fällt auf, dass der Betrag nach Vor- und Nachkommastellen getrennt aufgesammelt wird. Das hängt damit zusammen, dass der Rechnungsbetrag innerhalb der Rechnung mit einem Komma notiert ist, im Barcode aber mit einem Punkt gebraucht wird. 3) 4) Da der Barcode fest positioniert ist, muss natürlich garantiert sein, dass auf den Folgeseiten einer mehrseitigen Rechnung genau an dieser Position Platz für den EPC-QR-Code ist. Bei neugestalteten Rechnungen wird man den Code in der Nähe des Rechnungsbetrags positionieren, sodass das gestalterisch nicht solche Konsequenzen hat, wie hier im Beispiel. Wichtig für den Barcode ist die Einstellung zur Fehlerkorrektur. Diese soll laut Spezifikation auf dem Level Medium sein. Die Modulweite kann dagegen in weitem Bereich dem verfügbaren Platzangebot entsprechend eingestellt werden. Kritisch hier ist unter Umständen der Zeichensatz. Dieser muss den Angaben innerhalb der Schablone entsprechen, und wurde hier mit dem Hintergrund deutscher Kreditinstitute auf ISO 8859-1 gesetzt. Falls der Einsatz von UTF-8 gewünscht ist, muss unter Zeichensatz der Wert identisch ausgewählt werden. Auf die im nebenstehenden Bild abgeschnittene Schablone für den Barcode wird weiter unten getrennt eingegangen. Das den EPC-QR-Code beschreibende Textfeld muss die gleichen Bedingungen bei der Textauswahl haben wie das Barcodefeld. Grund dafür sind die Gutschriften. Wenn kein Barcode gedruckt wird, wird auch keine Beschreibung ausgegeben. Im Gegensatz zum Barcodefeld kann aber im Vergleichsmuster daruf verzeichtet werden, die Rechnungsbeträge aufzusammeln. |
Schablone im Barcodefeld
In der Schablone des Barcodefeldes versteckt sich im Prinzip dann das ganze Wissen über den EPC-QR-Code. Laut Spezifikation sind die einzelnen Teilbereiche der kodierten Daten als Zeilen zu verstehen. Insofern gibt es natürlich auch einen Zeilentrenner. Hier im Beispiel wird nur ein Linefeed (hexadezimal '\x0A', siehe auch hier unter Schablone) benutzt. Hinter dem letzten Teilbereich darf kein Zeilentrenner stehen.
Variable Bestandteile des Barcodes sind der nach Vor- und Nachkommastellen aufgeteilte Rechnungsbetrag, die Rechnungsnummer und die Kundennummer. Demzufolge erfüllt die - aus Gründen der besseren Verständlichkeit eingefärbte - nachfolgend abgebildete Schablone ihren Zweck: 5)
|
als Schablone im Bracodefeld dann geschrieben als:
BCD\x0a001\x0a2\x0aSCT\x0aPBNKDEFF\x0aLieferant GmbH\x0aDE08700901001234567890\x0aEUR\Rechnungsbetrag:1.\Rechnungsbetrag:2\x0aGDDS\x0a\x0aRE \Rechnungsnummer:1 KD \Kundennummer:1
Hinweise
- Im Beispiel wurden aus Gründen der Übersichtlichkeit die meisten Daten als konstant angesehen. Das ist natürlich bei mehreren Bankverbindungen oder bei Rechnungen für verschiedene Mandanten mitnichten der Fall. Bei solchen Szenarien müssen dann auch diese Informationen mit Hilfe weiterer Suchfelder ermittelt werden. 6)
- Abhängig vom konkreten Anwendungsfall ist auch der Grund der Zahlung variabel. Dann muss gegebenenfalls aus den Purpose-SEPA-Codes ein Wert ermittelt werden.
2)
Das ist eine Folge der Tatsache, dass die Rechnung typographische Schriften nutzt, und der Druckertreiber von Windows wegen des leeren Bereichs vor dem Rechnungsbetrag jeweils neu positioniert.
3)
Bei der Formatierung von Zahlen legt print2forms leider die aktuelle Einstellung des Windows-Systems zugrunde. Das bedeutet, in Deutschland wird ein Komma zur Trennung der Vor- und Nachkommastellen genutzt, sowie ein Punkt als Tausendertrennzeichen. Deshalb lässt sich der Punkt als Trennzeichen zwischen Vor- und Nachkommastellen nicht mit einer direkten Formatierung in der Schablone erzwingen.
4)
Wichtig ist auch, dass im Muster kein Minuszeichen erlaubt ist. Das bedeutet nämlich, dass im Falle eines negativen Rechnungsbetrages (Gutschrift) kein EPC-QR-Code erzeugt wird, was sachlich korrekt ist.
5)
Die Schablone ist als eine lange Zeile einzugeben. Sie ist hier nur aus Platzgründen umgebrochen. Zwischen den Vor- und Nachkommastellen des Rechnungsbetrages wird als Konstante ein Punkt eingefügt. Das ist eine Hilfskonstruktion zum Ersatz des im Deutschen verwendeten Kommas als Trennzeichen.
6)
Natürlich nur, wenn diese Informationen nicht eventuell schon von anderen Text-, Barcode- oder Systemfeldern extrahiert worden sind. Dann können auch diese anderen Felder innerhalb der Schablone für den EPC-QR-Code referenziert werden.