„Diskussion:EPC-QR-Code“ – Versionsunterschied
MAbW (Diskussion | Beiträge) |
K →Beispiel fehlerhaft: Datum der Erstellung eingefügt, da nichts dazu sichtbar war |
||
Zeile 57: | Zeile 57: | ||
=== Version === |
=== Version === |
||
3. Jan. 2023 |
|||
Im Beispiel ist als Version 001 angegeben, was aber falsch ist, da Zeile 10 "Remittance (Reference)" leer ist und Zeile 11 "Remittance (Text)" ausgefüllt ist. |
Im Beispiel ist als Version 001 angegeben, was aber falsch ist, da Zeile 10 "Remittance (Reference)" leer ist und Zeile 11 "Remittance (Text)" ausgefüllt ist. |
||
Version vom 28. August 2024, 21:05 Uhr
Girocode.de
Kann man diesen Code auch ohne diese komische Seite girocode.de (Anmeldezwang und Kosten für ihre "Lösungen") nutzen? Wenn nein, sollte das im Artikel erwähnt werden. Alle Banken verweisen nur darauf. --195.192.206.114 19:18, 20. Jan. 2018 (CET)
- Das Datenformat ist öffentlich und es gibt Open-Source-Lösungen sowohl zum Generieren (Wordpress-Plugin für Bezahlcodes) als auch zum Scannen (zbar Barcode Scanner, auch für QR-Codes) von QR-Codes. Somit besteht keine zwingende Abhängigkeit von Angeboten auf girocode.de. ---- mhi Noch Fragen? 12:33, 5. Jan. 2019 (CET)
BezahlCode
Von den Machern von iOutBank (Stoeger IT) gab es mal etwas mit dem Namen "BezahlCode". Können wir davon ausgehen, dass das ein zum EPC QR Code inkompatibler Standard ist? --Holger Engelke (Diskussion) 17:58, 2. Feb. 2020 (CET)
- Ich habe hier eine Rechnung auf der ein "Bezahlcode" ist. Zumindest der ist ein EPC-QR-Code.User:mborm (ohne (gültigen) Zeitstempel signierter Beitrag von Mborm (Diskussion | Beiträge) 11:02, 16. Jul. 2020 (CEST))
- Bezahlcode und EPC QR Code sind unterschiedlich und nicht kompatibel (habe beide implementiert). Inzwischen wurde der Bezahlcode eingestellt, da sich der EPC QR Code durchgesetzt hat. --Machajdik (Diskussion) 11:34, 4. Mär. 2023 (CET)
Fragen über Fragen
1. Die Version. Was bezweckt sie/verursacht sie an Formatänderungen? Antwort: In der Spec EPC069-12 ist klar zu sehen, dass bei Version 001 die Zeile 10 "Remittance (Reference)" ausgefüllt wird und bei Version 002 die Zeile 11 "Remittance (Text)". (reichhart)
2. Die Zeichenkodierung. Erlaubt sie die Benutzung der entsprechenden Zeichen, und wenn ja, werden sie ordentlich umgesetzt (ggf. lt. Standard?)
3. Der Zweck. Sind 4 Zeichen frei definierter Buchstabensalat?
Nebenbei die Frage, wie ein Handy als Überweisungsmedium dienen soll, wenn es doch schon als 2FA-Faktor dient. --Ghettobuoy (Diskussion) 03:09, 2. Apr. 2020 (CEST)
- Einen Kommentar zur Versionsnummer habe ich gerade beim BIC ergänzt, das ist der einzige Unterschied zwischen 001 und 002.
- Inwieweit die Zeichencodierung implementiert ist, bleibt letztlich der lesenden App überlassen, die EPC äußert sich nicht. Wenn die Bank, der Zahlungsdienstleister oder der Clearer den Zeichensatz einschränkt, kann die App da letztlich wenig ausrichten.
- Kommentar zum Zweck gibt es schon, das ist der SEPA-Purpose-Code.
- Gruß, — ThomasO. 21:29, 3. Aug. 2021 (CEST)
Warum nicht als URL?
Der EPC-QR-Code ist ja ganz nett, wenn man eine Rechnung im Papierformat verschickt.
Wenn man aber eine Rechnung per E-Mail verschickt, dann ist das mächtig kompliziert.
Man schaut also auf die Rechnung in seiner E-Mail-App im Handy. Wie soll man nun den QR-Code scannen? Mit einem zweiten Handy? Klar, ich bin vom Fach und mache einen Screenshot.
Aber das ist irgendwie zu kompliziert.
Warum nicht einfach ein neues URL-Schema:
sepa://IBAN/EMPFÄNGER/BETRAG/BETREFF
Auf das Protokoll kann sich dann die Banking-app registrieren, und der Nutzer muss nur auf den Link klicken und es öffnet sich die Banking-App.
Das wäre doch super einfach. Oder gibt es so etwas schon? (nicht signierter Beitrag von 2003:CA:6F4D:8800:C85:4883:98DB:2A34 (Diskussion) 12:01, 3. Apr. 2021 (CEST))
- Sehr gute Frage, die bisher kaum diskutiert wird. Der Bezahlcode konnte das übrigens. Derzeit gibt es so etwas leider nicht. Die EPC entwickelt derzeit einen neuen QR Code (https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/standardisation-qr-codes-mscts), dieser basiert auf einer URL und könnte - theoretisch - so verwendet werden. Ist aber bisher nicht Teil der Diskussion. --Machajdik (Diskussion) 11:36, 4. Mär. 2023 (CET)
Gibts hier auch Zahlen zur Nutzung?
Wie häufig wird das genutzt? Kann man auch schon sagen, wie häufig es Verbraucher (B2C) und Geschäftskunden (B2B) nutzen? Gibts hier Statistik für Deutschland? --2A01:C22:CD2E:1D00:CD85:143D:C9C7:3CF4 10:17, 15. Nov. 2022 (CET)
Beispiel fehlerhaft
Das Beispiel hat ZWEI Fehler.
Version
3. Jan. 2023 Im Beispiel ist als Version 001 angegeben, was aber falsch ist, da Zeile 10 "Remittance (Reference)" leer ist und Zeile 11 "Remittance (Text)" ausgefüllt ist.
Laut https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2022-09/EPC069-12%20v3.0%20Quick%20Response%20Code%20-%20Guidelines%20to%20Enable%20the%20Data%20Capture%20for%20the%20Initiation%20of%20an%20SCT_0.pdf ist das Verwenden von "Remittance (Text)" aber die Version 002.
Daran ändert auch nichts, dass viele Generatoren in dieser Hinsicht "defekt" sind - sogar die Generatoren der Genossenschaftsbanken.
Letzte Zeile
Nach der Zeile 11 "Remittance (Text)" folgt noch eine Leerzeile und somit ein Zeilenende (=Separator). Die Spec ist hier aber eindeutig:
"The last populated element is not followed by any character or element separator."
Der erste Punkt ist, dass generell kein Separator am Ende zu finden sein darf. Und der zweite und wichtigere Punkt ist "last POPULATED": Die letzten Zeilen sind laut Spec optional. Dies lässt sich auch ganz einfach an den Beispiel-QR-Codes aus der Spec erkennen: Das Beispiel für Version 001 hat 10 Zeilen und das Beispiel für Version 002 hat 11 Zeilen (mit "Information" jeweils leer bzw. nicht genutzt).
(reichhart)
Geschichte
Der QR Code wurde, soweit mir bekannt ist, nicht von der EPC entwickelt, sondern um 2011 von der österreichischen STUZZA (bzw. dem Austrian Payments Council) (siehe zB https://zv.psa.at/de/download/qr-code/archiv-1/128-qr-code-und-btd-definitionen/file.html). Die EPC hat das dann auf Vorschlag übernommen. Oder hat da jemand andere Informationen? --Machajdik (Diskussion) 11:43, 4. Mär. 2023 (CET)
(German) Umlauts?
"der Name und die IBAN eines SEPA-Zahlungsempfängers bei einer jeden Zahlungsanweisung verbindlich dem realen Namen des empfangenden Kontoinhabers sowie seiner IBAN entsprechen." Im Beispiel ist es schon angedeutet: "Wikimedia Foerdergesellschaft" Die heißen bestimmt "...Förder...". Wäre gut zu wissen, ob das so geregelt ist, daß man Umlaute ersetzen darf. Oder "o" statt "ö" etc. denn man weiß ja ggf. gar nicht, wie die Ersatzschreibweise bspw. von "Ø" aussieht oder ob es eine gibt. Und welcher Chinese etc. kann ein "ä" schreiben? --MAbW (Diskussion) 10:31, 26. Jul. 2024 (CEST)
- Nachtrag: Nicht einmal deutsche Banken können Umlaute beim Namen. So zum Beispiel die N26. Keine Ahnung, ob das Standard ist oder Marotte. Aber irgendwie traurig angesichts von Jahrzehnten mit UTF-8 etc. Vermutlich sitzt da irgendwo noch in einer Bank oder beim Gremium eine IBM 701 :-) --MAbW (Diskussion) 09:40, 30. Jul. 2024 (CEST)