Hallo Raimund,
Zitat geschrieben von Raimund Sichmann
Wenn ich eins gelernt hab Im elektronischen Zahlungsverkehr: Probleme machen doch nicht die 99,9% bei denen alles schön glatt läuft - spannend sind nur die 0,1%, die irgendwelche Besonderheiten aufweisen
Full ACK, aus über 35 Programmierer-Jahren kann ich dir nur sagen "Ist nicht auf den Zahlungsverkehr begrenzt."
M.E. ist es bei der Programmierei generell so das die 0,1% ca. 90% der Zeit verursachen
Ansonsten schließe ich mich deiner Null-Toleranz-Denke natürlich nicht an. (nicht böse gemeint).
Bei uns laufen bei ca. 80 Anwendern monatlich > 100.000 Lastschriften durch.
Das wird noch einige Diskussionen im Anwender-Support geben.
Was mich aber am meisten stört:
*WARUM wird das nicht einheitlich geregelt*
Seit Oktober 2013 erstellen wir bei (wenigen) Anwendern SEPA.XML-Dateien im Echtbetrieb.
Und da war "verspätet" kein Thema.
Ich bin doch nicht auf die Idee gekommen, dass das Thema unterschiedlich gehandhabt wird, obwohl ich mich bereits 1 1/2 Jahre mit SEPA beschäftige.
Nun bin ich wieder unter Zeitdruck "TARGET-2-gerechte Bankarbeitstage" zu berücksichtigen/programmieren.
Genau so wie ich letzte Woche feststellen mußte das der Transportweg "HBCI" nicht erlaubt mehrere Sammler in einer Datei zu haben.
Obwohl die SEPA.XML-Formal in Ordnung ist.
Nachdem ich die notwendigen Aufteilungen der Erst/Folge/Termin-Kriterien in einzelne Dateien programmiert habe, bekommt ein Anwender von uns plötzlich 14(!) SEPA.XML die alle einzeln - zum richtigen Zeitpunkt - jeweils mit eigener TAN - eingereicht werden müssen.
Da gab es früher nur eine DTAUS-Datei.
Glaubst du die Anwender rufen "Hurra wir haben SEPA".
Hab ich noch nicht gehört.
Ich wünsche dir noch einen schönen Sonntag.
mfg
Wolfgang