Moin,

eine vielleicht ganz dumme Frage: Wie komme ich eigentlich an den "Payment Status Report" (pain.002. ...), der z.B. nach Senden von SEPA-Basisastschriften (pain.008. ...) »die Nachricht der 1. Inkassostelle an den Zahlungsempfänger über die vor Fälligkeit zurückgewiesenen Lastschriften« enthält?

Also wenn ich z.B. eine SEPA-XML mittels FinCmd via HBCI/FinTS an die Bank sende, kommt die pain.002 dann gleich als Antwort von der Bank zurück, oder muß ich die dann erst noch irgendwie "abholen"?

Gruß,
Stefan

Sehr gute Frage. Gibt es überhaupt schon Banken, die diese Nachrichten erzeugen? Vor Fälligkeit kann ja nur wegen falscher Angaben sein. Und da buchen nach meinem Kenntnisstand die Banken bisher noch direkt gegen auf dem Einreicherkonto, das wars. Oder wird diese Nachricht nur nach einem Rückruf des Einreichers erzeugt?

Der Abruf von pain 002 ist in FinTS nicht mal spezifiziert. D.h. hier gibt es derzeit absolut keine Möglichkeit.

Schade - da hat man SEPA bei FinTS offenbar nur "halbherzig" umgesetzt...

Das hat mit halbherzig nichts zu tun, sondern eher eine Frage der Zielgruppe. Über Camt / Umsatzinformationen im allgemeinen und dem Statusprotokoll hat man heute schon die Instrumente, die mit der pain002 erst geschaffen werden müssten.

Viele Grüße

Holger

Tja, ja, HBCI, FinTS vs ISO 20022 vs SEPA …

In FinTS-4.0 sind camt und pain durchaus vorgesehen,
aber obwohl FinTS-4.0 auch schon nicht mehr ganz jung ist,
werden wird es wohl auch noch nicht so schnell bei unseren Banken sehen.

Bei FinTS-3.0 braucht man auf camt und pain sicher nicht mehr zu warten.
Jedenfalls nicht darauf, dass das dann auch noch von unseren Banken angeboten wird.

Die Finanz-Industrie ist halt etwas schwerfällig und braucht ihre Zeit für Innovationen.

Geschäftskunden, denen camt und pain wichtig sind, können sie ja über EBICS von ihren Banken bekommen.

~J

Was sind denn das für seltsame Behauptungen??

Sowohl PAIN als auch CAMT werden transparent in HBCI und FinTS eingestellt. Insofern ist die Version völlig wurscht. Was meinst Du denn, wie sonst Sammenzahlungen über HBCI 2.x und 3.0 übertragen werden?

Weiterhin gibt es durchaus Institute, die Umsätze über HBCI auch (!) in CAMT ausliefern können. Allen voran ist da FI, das RZ der Sparkassen zu nennen.

Auch dieser aufgewärmte Beitrag war über ein Jahr alt!

Uiii, werden hier Dinge durcheinander geworfen.

von pains spricht man bei den Formaten, mit denen SEPA Zahlungen oder Einzüge bzw. Reports zu diesen Aufträgen einereicht oder abgerufen werden können.
Damit kann jede Bank, die SEPA Zahlungen oder Lastschriften über HBCI und FinTS anbietet zwangsweise pains

pain 002, der Statusreport ist etwas anderes. Die sind üblicherweise erst bei großen Sammlern von Bedeutung, daher zunächst für EBICS relevant. Inzwischen sind auch für FinTS die pain 002 spezifiziert. Deren sinnvolle Einsatzfelder sind aber durchaus begrenzt,

Zu camt :
letztendlich transportieren die camt Formate auch nur Umsatzinformationen. Wenn man nicht spezielle Informationen aus den SEPA Formaten benötigt, ist es egal ob camt oder MT940

Zu FinTS 4.0 ist nicht nur nicht mehr ganz jung, sondern veraltet. im 4er Bereich ist FinTS 4.1 der aktuelle Standard.

Viele Grüße

Holger

Ich habe mir kürzlich das camt.052 (BankToCustomerAccountReport) von Postbank und Berliner Sparkasse genauer angeschaut.

Bezüglich SEPA-Unterstützung:
Da gibt es diese Felder, die auftauchten, seit von SEPA die Rede ist und von denen man denken könnte, dass sie einen konkreten ISO-20022-Bezug haben:

• Creditor ID – eigentlich: <CdtrSchmeId>
  
• Mandat – eigentlich: <MndtId>
  
• Kundenreferenz, Referenz, EREF – eigentlich <EndToEndId>
  
• Einreicherreferenz, KREF – eigentlich <PmtInfId>
  
• ABWA, initiating party – eigentlich <InitgPty>
  
• ABWE, ultimate creditor – eigentlich <UltmtCdtr>
  
• ABWS, ultimate debitor – eigentlich <UltmtDbtr>
  

Aber die beiden genannten Banken stecken alle SEPA-Spezialitäten, die sie überhaupt unterstützen,
in unstrukturierte Verwendungszweckfelder (<RmtInf><Ustrd>...);
ich ringe um eine angemesse Formulierung für diese "Unterbringung",
mir kommt leider nur "sehr beschämend" in den Sinn – aber wie formuliert man das ohne die begleitende Verve?

Eigentlich würde ich das den Verantwortlichen und Entwicklern der beiden Banken gerne mal vorhalten,
allein um eine Verbesserung zu erreichen.

(An verschiedenen Stellen halten sich beide Banken übrigens auch nicht an Längenbeschränkungen, die in den camt.052-XSDs definiert sind.
Übrigens durchaus verschiedener Jahrgänge!)

Hat jemand eine Idee, wie man mit den jeweiligen Verantwortlichen und Entwicklern in einen fruchtbaren Dialog eintreten kann?

~J

naja, das ist natürlich das Dilemma, das Holger meinte, für passende "SEPA-Felder" braucht es CAMT, alles in MT940 ist - natürlich - irgendwie konvertiert worden. Was anderes kann die Bank nicht tun.
Ich hab jetzt keine Ahnung, was die beiden genannten Banken konkret anbieten, aber wenn die Felder für dich wichtig sind, könnte sich EBICS lohnen.

Gruß
Raimund

Na ja, es ist ja dokumentiert, wie Banken die SEPA-Felderr auf MT940 abbilden sollen. Da gibt's ja die entsprechenden Kürzel zur Kennzeichnung (MREF+, SVWZ+, usw.) In der Praxis schieben die Banken die SEPA-Felder wie ausgewürfelt in das MT940. Und ändern das teilweise gefühlt alle 2 1/2 Tage. Da fragt man sich schon, wie das passieren kann.

schönen Gruß

Christian

...naja, man hat manchmal das Gefühl, als ob jetzt der SEPA-Einführungsstress ein wenig abebbt und man nun anfängt, optisch "nachzubessern". Das kann dann im worst case wohl zu den Änderungen gefühlt alle 2 1/2 Tage führen...

Diese Erfahrungswerte über alle Bankengruppen hinweg sind aber wohl auch ein gutes Zeichen, warum bei den Kandidaten, die es brauchen, ein Umstieg von DTI auf camt.054 z.B. schwierig sein dürfte - wenn man eine Schnittstelle versucht, auf den aktuellen Stand anzupassen, kann dieser 1. bei jedem Institut anders aussehen und 2. spontanen Nachbesserungen unterworfen sein. Das macht dann sicher wenig Spaß...

Hat jemand eigentlich aktuell schon Erfahrungswerte, inwiefern die CAMT-Formate schon im großen Stil weiterverarbeitet werden? Gefühlt werden in den Kundensystemen doch eigentlich immer noch MT940 & Co verarbeitet, haben wir es hier wieder mit einem Henne-Ei-Problem zu tun? Was machen eigentlich die großen RZ, so wie z.B. DATEV - wären die camt.053-ready?

Aber ich schrieb über das camt.052 der beiden Banken.
Auch genau dort stecken sie all die genannten Felder wie gehabt in gewöhnliche Verwendungszweckfelder.

Ob ich deren camt.052 mal versuchsweise aus dem jeweiligen Portal downloade oder via EBICS, das dürfte keinen Unterschied machen.
Oder denkst du, sie bieten jeweils unterschiedliches camt.052 an?

Schönen Gruß
~J

Unmöglich ist nichts....

Die Deutsche Bank z.B. liefert via HBCI für Konten, die als Geschäftskonten geschlüsselt sind, ein MT940 aus, das korrekt mit strukturiertem Feldinhalt belegt ist aus.

Für Privatkonten hingegen wird nur unstrukturierte Feldbelegung ausgeliefert. Nicht mal der Zahlungsgegnername ist in einem Namen-Feld untergebracht, es gibt nur "Zeilen".

Hintergrund: Bei den Geschäftskonten berechnet man das extra...

Nachdem jetzt die Postbank inzwischen ja der Deutschen Bank gehört.... wer weiß

das war mir so gar nicht klar, aber erklärt natürlich die Probleme etwas. Der schöne XML-Vorteil wird ja dadurch ziemlich absurd...

Gruß
Raimund