===== EPC-QR / Girocode ===== ~~NOCACHE~~ 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 (p2f) ohne weiteres erzeugt und in eine Rechnung integriert werden. Lediglich der Inhalt des QR-Codes unterliegt einer vom European Payments Council (EPC) herausgegebenen [[https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-06/EPC024-22v2.10%20Standardisation%20of%20QR-codes%20for%20MSCTs.pdf|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 (p2f) 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. \\ \\ Als Basis für diesen Tip dient ein in der Free-Edition von (p2f) als **Testfall** enthaltener Druckdatenstrom für eine Rechnung mit dem Namen **Girocode**. Diese Rechnung wurde mit Hilfe einer Office-Suite als Text-Dokument erzeugt. Diese Rechnung ist auch die Basis für die beiden Tips [[print2forms:tips:tip92|XRechnung 3.0.1]] und [[print2forms:tips:tip94|Factur-X 1.0 aka ZUGFeRD 2.2]]. {{ print2forms:tips:0098-1.png?recache|Ausschnitt einer Rechnung mit eingedrucktem EPC-QR}} \\ ==== 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 (p2f) 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. {{print2forms:tips:0098-2.png|Das Formular 'Girocode'}} 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 **Rechnungs(-)nummer** 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 **Rechnungs(-)betrag**. Im Gegensatz zu den beiden vorherigen Feldern ist keine feste Seite als //Index// angegeben, weil der Rechnungs(-)betrag bei mehrseitigen Rechnung auf einer der Folgeseiten notiert ist. ((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.\\ \\ )) 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 Vorkomma(-)stellen 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. ((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.\\ \\ )) 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. ((Bei der Formatierung von Zahlen legt (p2f) 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 [[print2forms:tips:tip61|Formatierung in der Schablone]] erzwingen.\\ \\ )) ((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.\\ \\ )) 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 //Fehler(-)korrektur//. 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 Kredit(-)institute 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 Rechnungs(-)beträ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 [[print2forms:objekte:ovl:barval|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: ((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.\\ \\ )) \\ \\ | BCD(red)\x0a(blk)\\ 001(red)\x0a(blk)\\ 2(red)\x0a(blk)\\ SCT(red)\x0a(blk)\\ PBNKDEFF(red)\x0a(blk)\\ Lieferant GmbH(red)\x0a(blk)\\ DE08700901001234567890(red)\x0a(blk)\\ EUR(blu)\Rechnungsbetrag:1(blk).(blu)\Rechnungsbetrag:2(blk)(red)\x0a(blk)\\ GDDS(red)\x0a\\ \x0a(blk)\\ RE (blu)\Rechnungsnummer:1(blk) KD (blu)\Kundennummer:1(blk) | \\ 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. ((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.\\ \\ )) * Abhängig vom konkreten Anwendungsfall ist auch der Grund der Zahlung variabel. Dann muss gegebenenfalls aus den [[https://wiki.windata.de/index.php?title=Purpose-SEPA-Codes|Purpose-SEPA-Codes]] ein Wert ermittelt werden. \\ \\