expertenaustausch > etc.finanz.* > etc.finanz.banken+broker

Erwin Uchmann (10.07.2018, 17:17)
Die Sparkassen unterstützen ab heute die Sofortüberweisung, auch bekannt
als Instant Payment oder SCT INST.

Ging ja durch alle Medien. Die DKB wurde auch zum heutigen Tag angekündigt,
sie ist ja eine Art verkappte Sparkasse (Tochter der BayernLB) und auch am
Rechenzentrum der Sparkassen angeschlossen. Leider aber wird bei der DKB
bis auf Weiteres Instant Payment nur eingehend unterstützt. Ausgehende
Zahlungen sind weiterhin nur als Standardüberweisung möglich.

Ich finde das etwas Schade, aber hoffe auf die Welle im November 2018, wenn
die Geno-Banken und andere wie Deutsche Bank (einschließlich der
Zweitmarken Postbank und Norisbank) auf den Zug aufspringen. Ich frage mich
schon lange, weshalb die Bankcomputer am Wochenende nicht arbeiten - mit
Instant Payment gehört dieser Anachronismus endlich der Vergangenheit an.

Was noch stört ist der niedrige Betrag von max. 15000 EUR, aber auch diese
Grenze soll wohl mal entfallen.
Jens Bock (10.07.2018, 19:42)
Erwin Uchmann <eruch> wrote:
> Die Sparkassen unterstützen ab heute die Sofortüberweisung, auch bekannt
> als Instant Payment oder SCT INST.


Die 1822direkt bepreist jede "Echtzeit-Überweisung" mit 99 Cent.
Mir fallen nur extrem wenig Anwendungsfälle ein, in denen mir eine etwas
schnellere Überweisung von maximal 15k Euro 99 Cent Zusatzkosten wert
wären. (Normale SEPA-Überweisungen sind kostenfrei.)

Gruß,
Jens
Erwin Uchmann (10.07.2018, 21:17)
Am Tue, 10 Jul 2018 19:42:03 +0200 schrieb Jens Bock:

> Die 1822direkt bepreist jede "Echtzeit-Überweisung" mit 99 Cent.
> Mir fallen nur extrem wenig Anwendungsfälle ein, in denen mir eine etwas
> schnellere Überweisung von maximal 15k Euro 99 Cent Zusatzkosten wert
> wären.


Die lokale Sparkasse hier nimmt dafür kein Entgelt. Wie dem Vernehmen nach
die meisten Institute. Ist in meinen Augen auch Schwachsinn.
Jens Bock (10.07.2018, 23:24)
Erwin Uchmann <eruch> wrote:
> Am Tue, 10 Jul 2018 19:42:03 +0200 schrieb Jens Bock:
> Die lokale Sparkasse hier nimmt dafür kein Entgelt. Wie dem Vernehmen nach
> die meisten Institute. Ist in meinen Augen auch Schwachsinn.


Ich frage mich halt, ob der Aufpreis eine Nutzung in größerem Umfang
verhindern soll (Abschreckung) oder ob tatsächlich jemand bei den Banken
glaubt, so nennenswerte Zusatzerträge generieren zu können.
Für mich persönlich bedeutet so ein Aufpreis schlicht, dass ich dieses
Verfahren im Alltag niemals nutzen werde.

Gruß, Jens
Ludger Averborg (12.07.2018, 12:43)
On Tue, 10 Jul 2018 17:17:05 +0200, Erwin Uchmann
<eruch> wrote:

[..]
>Instant Payment gehört dieser Anachronismus endlich der Vergangenheit an.
>Was noch stört ist der niedrige Betrag von max. 15000 EUR, aber auch diese
>Grenze soll wohl mal entfallen.


Fragt sich, ob die Sparkassen/Banken da nicht deutlich zu
spät kommen und ob die alternativen "Züge" wie Paypal oder
Amazon Payment nicht längst soweit weg sind, dass sie nicht
mehr eingeholt werden. Insbesondere sehe ich nicht,
wie/dass von den Banken her eine derartig bequeme
Intergation der neuen Verfahren in den Kaufprozess angeboten
wird, wie das z. B. mit "Paypal direct" erfolgt: Mit
email-adr und Paypal passwd wird dem Händler ganz
automatisch die Anschrift für die Lieferung übermittelt.
Sowas ist "Digitalisierung" ohne einen einzigen mm
Glasfaser.

Derzeit überweise ich viele Arzt- und Klinik-Rechnungen.
Wieso ist da nicht generell ein QR-Code drauf, aus dem mein
Bankprogramm vollautomatisch eine Überweisung erstellt?

Eine Pflicht, dass sowas generell Bestandteil einer
ordentlichen Rechnung ist, wäre auch Digitalisierung, die
kaum was kostet und viel nützt.

l.
Erwin Uchmann (12.07.2018, 19:18)
Am Thu, 12 Jul 2018 12:43:03 +0200 schrieb Ludger Averborg:

> Derzeit überweise ich viele Arzt- und Klinik-Rechnungen.
> Wieso ist da nicht generell ein QR-Code drauf, aus dem mein
> Bankprogramm vollautomatisch eine Überweisung erstellt?


Zumal der GiroCode ziemlich einfach aufgebaut ist.
Georg Schwarz (13.07.2018, 21:04)
Ludger Averborg <ludger_averborg> wrote:

> Derzeit überweise ich viele Arzt- und Klinik-Rechnungen.
> Wieso ist da nicht generell ein QR-Code drauf, aus dem mein
> Bankprogramm vollautomatisch eine Überweisung erstellt?
> Eine Pflicht, dass sowas generell Bestandteil einer
> ordentlichen Rechnung ist, wäre auch Digitalisierung, die
> kaum was kostet und viel nützt.


die kostet den Anbieter sehr wohl. Er müsste seine Software und seine
Prozesse umstellen.

QR-Codes sind im Krücken, um einen Medienbruch weniger drastisch zu
machen (stellen aber immer noch einen Medienbruch dar). Konsequente
Digitalisierung wären elektronische Rechnungen.
Ludger Averborg (13.07.2018, 21:42)
On Fri, 13 Jul 2018 21:04:37 +0200, georg.schwarz
(Georg Schwarz) wrote:

>Ludger Averborg <ludger_averborg> wrote:
>die kostet den Anbieter sehr wohl. Er müsste seine Software und seine
>Prozesse umstellen.
>QR-Codes sind im Krücken, um einen Medienbruch weniger drastisch zu
>machen (stellen aber immer noch einen Medienbruch dar). Konsequente
>Digitalisierung wären elektronische Rechnungen.


Ich vermute, das kann man in einer nicht 100 %ig digitalen
Gesellschaft nicht machen.

Wobei elektronische Rechnungen auch die
überweisungsrelevanten Daten nicht in einem
standardisierten, an das bankingprg einfach zu übergebendem
Päckchen vorhalten.

l.
Matthias Hanft (14.07.2018, 09:20)
Georg Schwarz schrieb:
> die kostet den Anbieter sehr wohl. Er müsste seine Software und seine
> Prozesse umstellen.


Mich hat das nur einen Nachmittag gekostet, um das wie in dem Beispiel
auf einzubauen.

> QR-Codes sind im Krücken, um einen Medienbruch weniger drastisch zu
> machen (stellen aber immer noch einen Medienbruch dar). Konsequente
> Digitalisierung wären elektronische Rechnungen.


PDF-Rechnungen werden inzwischen ja schon verbreitet verschickt, aber
die muss ja immer noch jemand abtippen (wobei es anscheinend schon
Lösungen gibt, die versuchen, ähnlich wie bei OCR die nötigen Daten
automatisiert aus einem PDF auszulesen - keine Ahnung, wie gut das
funktioniert). So *richtig* konsequent wären nur unmittelbar maschinen-
lesbare Rechnungen, und auch da gibts ja ältere (EDIFACT) und neuere
(ZUGFeRD) Lösungen, aber die sind schon wieder so komplex als eier-
legende Wollmilchsau konzipiert, dass man für eine Implementierung
eher ein Jahr als einen Nachmittag brauchen würde... :-(

Gruß Matthias.
Martin Τrautmann (14.07.2018, 10:03)
On Sat, 14 Jul 2018 09:20:47 +0200, Matthias Hanft wrote:
> Georg Schwarz schrieb:
>> die kostet den Anbieter sehr wohl. Er müsste seine Software und seine
>> Prozesse umstellen.

> Mich hat das nur einen Nachmittag gekostet, um das wie in dem Beispiel
> auf einzubauen.


Zu welchem Zweck? Welcher Kunde hat eine Bank, die die Daten eines
QR-Codes übernehmen kann?

> So *richtig* konsequent wären nur unmittelbar maschinen-
> lesbare Rechnungen, und auch da gibts ja ältere (EDIFACT) und neuere
> (ZUGFeRD) Lösungen, aber die sind schon wieder so komplex als eier-
> legende Wollmilchsau konzipiert, dass man für eine Implementierung
> eher ein Jahr als einen Nachmittag brauchen würde... :-(


Meine Bank hat es ja nicht einmal geschafft, die SEPA-Textzeilen
sinnvoll zu formatieren: Da stecken Leerzeichen mitten im Wort, andere
Wörter werden hart am Zeilenende umgebrochen und die Transaktionscodes
stehen nackt drinnen, statt z.B. die als Zeilenumbruch zu benutzen und
die relevanten Infos hinter Z+ oder OTHR in Fettschrift darzustellen.

Schönen Gruß
Martin
Alexander Goetzenstein (14.07.2018, 11:11)
Hallo,

Am 14.07.2018 um 09:20 schrieb Matthias Hanft:
> PDF-Rechnungen werden inzwischen ja schon verbreitet verschickt, aber
> die muss ja immer noch jemand abtippen (wobei es anscheinend schon
> Lösungen gibt, die versuchen, ähnlich wie bei OCR die nötigen Daten
> automatisiert aus einem PDF auszulesen - keine Ahnung, wie gut das
> funktioniert).


es gibt die Möglichkeit, andere Dateien in PDFs einzubetten, etwa die
Ursprungsdatei des erzeugenden Programms, um das Ganze editierbar zu
machen. Wenn man sich auf ein Format einigen kann, wäre so auch eine
vollautomatisierte elektrische Rechnung per PDF denkbar. Im Grunde
müsste man nur einen Standard festlegen.
Matthias Hanft (14.07.2018, 12:13)
Martin ?rautmann schrieb:
> Zu welchem Zweck? Welcher Kunde hat eine Bank, die die Daten eines
> QR-Codes übernehmen kann?


Z.B. alle Sparkassenkunden :-)


VR-Bank-Werbung dafür hab' ich aber auch schon gesehen. Also rein
technisch ist das wohl schon oft implementiert - ohne dass es der
Anwender weiß. Wird seltsamerweise auch kaum Werbung dafür gemacht.

> Meine Bank hat es ja nicht einmal geschafft, die SEPA-Textzeilen
> sinnvoll zu formatieren: Da stecken Leerzeichen mitten im Wort, andere
> Wörter werden hart am Zeilenende umgebrochen und die Transaktionscodes
> stehen nackt drinnen, statt z.B. die als Zeilenumbruch zu benutzen und
> die relevanten Infos hinter Z+ oder OTHR in Fettschrift darzustellen.


Ja nun, das liegt daran, dass es bei SEPA-Überweisungen halt gar
keine Textzeilen gibt - der Verwendungszweck einer Überweisung
sind einfach 140 (unformatierte) Zeichen, und gut is'. Viele
Banken brechen das in 4 Zeilen zu je 35 Zeichen um, und/oder
machen zwischen diese 4 Zeilen noch jeweils ein Leerzeichen.
Und ganz schlimm wird es, wenn man seine Kontoauszüge im
MT940-Format abholt (was im Prinzip alle heutigen HBCI-Programme
machen): Da wird der Verwendungszweck in (bis zu 15) separate
Felder zu je 27 (!) Zeichen gepresst. Dass bei dem Kuddelmuddel
"1 x 140 - 4 x 35 - 15 x 27" hinten nix gutes mehr rauskommen
kann, ist eh klar...

Gruß Matthias.
Matthias Hanft (14.07.2018, 12:47)
Alexander Goetzenstein schrieb:
> es gibt die Möglichkeit, andere Dateien in PDFs einzubetten, etwa die
> Ursprungsdatei des erzeugenden Programms, um das Ganze editierbar zu
> machen. Wenn man sich auf ein Format einigen kann, wäre so auch eine
> vollautomatisierte elektrische Rechnung per PDF denkbar. Im Grunde
> müsste man nur einen Standard festlegen.


Den gibts mit "ZUGFeRD" ja schon (da wird eine XML-Datei mit der Rech-
nung als PDF-Attachment eingebettet). Aber für eine simple Rechnung
"10 Kästen Bier, netto 100 EUR, 19% Mwst., zu zahlen 119 EUR" ist
das XML, das man dafür erzeugen müsste, viiiiiiel zu komplex.

Klar, sie wollten halt alle nur denkbaren Eventualitäten (z.B. unter-
schiedliche Mwst., Skontoabzug, Anzahlungen usw. usf.) mit ihrem
Standard erschlagen (so ähnlich wie bei dem XML für die eBilanz: da
gibts auch nur ein einziges XML-Schema vom nebenberuflichen 1-Personen-
Bauchladen-Unternehmer bis zum weltumspannenden Großkonzern mit
Milliardenumsätzen). Aber dieses ganze XML-Zeug skaliert halt
einfach nicht gut. Für das obige Rechnungsbeispiel würde ein
zehnzeiliges XML (inhaltlich) ausreichen; das ZUGFeRD-Beispiel
namens "Einfach" (mit ähnlichem Inhalt) braucht (wenn man den
Kommentar weglässt) schon 113 Zeilen mit 5½ KB Größe und sieht
ausschnittsweise so aus:

[...]
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:ferd:CrossIndustryDocument:invoice:1p0 :basic</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:SpecifiedExchangedDocumentContext>
<rsm:HeaderExchangedDocument>
<ram:ID>471102</ram:ID>
<ram:Name>RECHNUNG</ram:Name>
[...]

von komplexeren Rechnungen gar nicht erst zu reden. Dazu gibts
eine insgesamte 300-seitige Dokumentation, was ja sehr lobens-
wert ist; aber jemand, der sowas implementieren will, wird halt
erst mal davon erschlagen.

Und überhaupt: Das Zeug muss in eine "PDF/A-3"-konforme Datei
rein. Sowas kann meines Wissens keine von den "üblichen" Linux-
PDF-Bibliotheken erzeugen. Um überhaupt Attachments in PDFs
reinzukriegen, muss man offenbar Software zwischen $199 und
$399 kaufen. Und "pdftk" (was anscheinend das kostenlose
Standard-Tool für PDF-Bearbeitung ist) lässt sich angeblich
nur mit dem uralten und nirgendwo mehr installierten gcc 5
übersetzen - das deutet darauf hin, dass das auch schon
länger nicht mehr gewartet wird.

Also: Aus Händler- und Programmierersicht (ich bin beides)
find' ich das alles jetzt nicht sooo prickelnd, als dass
ich sofort vollständig begeistert mit der Programmierung
anfangen würde...

Gruß Matthias.
markus philippi (14.07.2018, 17:42)
Matthias Hanft <mh> wrote:
> Martin ?rautmann schrieb:
>> Zu welchem Zweck? Welcher Kunde hat eine Bank, die die Daten eines
>> QR-Codes übernehmen kann?

> Z.B. alle Sparkassenkunden :-)
>


Und in diverse Banking Apps kann man Girocode direkt einlesen, z.b.
Banking4i - ist also Bankunabhängig.
Wenn ich eine Rechnung mir Girocode übernehme ich die Daten so, recht
praktisch.
Ludger Averborg (14.07.2018, 17:57)
On Sat, 14 Jul 2018 08:03:37 -0000 (UTC), Martin ?rautmann
<t-usenet> wrote:

>> Mich hat das nur einen Nachmittag gekostet, um das wie in dem Beispiel
>> auf einzubauen.

>Zu welchem Zweck? Welcher Kunde hat eine Bank


oder eine Homebanking-Software

>, die die Daten eines
>QR-Codes übernehmen kann?


Ex-Quicken / Lexware Finanzmanager kann es offenbar nicht.
Dort wird ein Verfahren angeboten, wo die ganze (digitale)
Rechnung eingelesen wird und sich die Software dann dort
(soviel wie möglich) rauspickt, was für die Überweisung
nötig ist.

Meine Alt-Version hat einen Vorläufer: Quickpay.
Da füllst du per copyandpaste die Rechnung (bzw den
relevanten Teil) in ein Textfeld ein, markierst dort Stellen
und wählst aus, wo sie in der Überw. hin sollen.
Das ist bequem und nützlich und das verwende ich oft.

l.

Ähnliche Themen