SEPA Komponente gesucht

[arnof]

gerade auf heute.de im NEWS Ticker:

"EU verlängert Übergangsfrist für SEPA-Einführung"

Hätte mich auch gewundert erst diese Woche habe ich bei meiner Hausbank einige Bugs festgestellt, angefangen von Kontoauszügen wo die Zahlung per SEPA ankam ...:lol:

[jobo]

Zitat:

Zitat von ele (Beitrag 1242673)

@jobo: Bold-Tags werden in einem Code-Block nicht unterstützt. Dein Beispiel ist deswegen nicht korrekt, denn

Code:

[B]FRST[/B]

ist kein gültiger SequenceType. Korrekt wäre

Code:

FRST

.

Zitat:

Zitat von DeddyH (Beitrag 1242675)

Wahrscheinlich wollte er die Stelle nur in der DP hervorheben, aber der Parser unterstützt das innerhalb von Code-Tags nicht.

So ist es, danke DeddyH!

Meine Kernaussage war eigentlich, dass es pro Lastschrift/Buchung angegeben werden kann.

Zitat:

Zitat von arnof (Beitrag 1242861)

gerade auf heute.de im NEWS Ticker:

"EU verlängert Übergangsfrist für SEPA-Einführung"

Hätte mich auch gewundert erst diese Woche habe ich bei meiner Hausbank einige Bugs festgestellt, angefangen von Kontoauszügen wo die Zahlung per SEPA ankam ...:lol:

Das ist ja der Hit.
Ich sitze hier grad und frag mich, wo man in einer CAMT Datei die IBAN des Buchungssatzes findet. Es wurden gefühlt 10 neue TransaktionsID für die tollsten Infos eingeführt (plus der IBAN selbst), aber CAMT (oder sagen wir die Bank) liefert sie nicht zurück.
Dass man wenigstens eine Zuordnung über eine IBAN machen könnte, ist wohl nicht vorgesehen.
Wer soll auf einer solchen "Basis" denn Buchungen verarbeiten?

[ele]

Zitat:

Zitat von jobo

Meine Kernaussage war eigentlich, dass es pro Lastschrift/Buchung angegeben werden kann.

Nicht nach meinem Verständnis. Das PmtTpInf-Element kann mehrere DrctDbtTxInf-Elemente (Buchungen) enthalten. Deswegen heisst es im ISO2022-Standard für das SequenceType-Element auch

Zitat:

Identifies the direct debit sequence, such as first, recurrent, final or one-off.

Beim CAMT kenne ich mich nicht so genau aus (ich müsste mal den Arbeitskollegen fragen). Aber es kann sehr gut sein, dass die Bank das nicht mitliefert. Wie ich schon erwähnt hatte, trotz Standard gibt es verschiedene Ausprägungen (je nach Land und Bank). Ist eigentlich zum heulen aber anderseits generiert das für uns Arbeit und sichert so unsere Arbeitsplätze :wink:.

[arnof]

Zitat:

Zitat:

Zitat von arnof (Beitrag 1242861)

gerade auf heute.de im NEWS Ticker:

"EU verlängert Übergangsfrist für SEPA-Einführung"

Hätte mich auch gewundert erst diese Woche habe ich bei meiner Hausbank einige Bugs festgestellt, angefangen von Kontoauszügen wo die Zahlung per SEPA ankam ...:lol:

Das ist ja der Hit.
Ich sitze hier grad und frag mich, wo man in einer CAMT Datei die IBAN des Buchungssatzes findet. Es wurden gefühlt 10 neue TransaktionsID für die tollsten Infos eingeführt (plus der IBAN selbst), aber CAMT (oder sagen wir die Bank) liefert sie nicht zurück.
Dass man wenigstens eine Zuordnung über eine IBAN machen könnte, ist wohl nicht vorgesehen.
Wer soll auf einer solchen "Basis" denn Buchungen verarbeiten?

Ja unsere Festellung war, dort wo bei elektronik Banking IBAN und BIC stehen sollte kommt von der Raiffeisenbank noch Kontonr und BLZ, dafür schießen die IBAN und Bic nochmals in den Verwendungszweck :pale: Von den ganzen ID's, die man benutzen könnte mal abgesehen (EndToEnd Id für die Eindeutige Zuweisung von Belegen)


[Update] SEPA Verlängerung beträgt 6 Monate

[jobo]

Zitat:

Zitat von ele (Beitrag 1242869)

Zitat:

Zitat von jobo

Meine Kernaussage war eigentlich, dass es pro Lastschrift/Buchung angegeben werden kann.

Nicht nach meinem Verständnis. Das PmtTpInf-Element kann mehrere DrctDbtTxInf-Elemente (Buchungen) enthalten. Deswegen heisst es im ISO2022-Standard für das SequenceType-Element auch

Zitat:

Identifies the direct debit sequence, such as first, recurrent, final or one-off.

Du hast Recht, ich habe meinen eigenen Code falsch gelesen :oops:

Zitat:

Beim CAMT kenne ich mich nicht so genau aus (ich müsste mal den Arbeitskollegen fragen). Aber es kann sehr gut sein, dass die Bank das nicht mitliefert. Wie ich schon erwähnt hatte, trotz Standard gibt es verschiedene Ausprägungen (je nach Land und Bank). Ist eigentlich zum heulen aber anderseits generiert das für uns Arbeit und sichert so unsere Arbeitsplätze :wink:.

Ich glaub nicht, dass das Sinn macht. Ich bin mir zwar nicht sicher, ob das ein Schweizer Phänomen ist oder das einer Schweizer Bank, aber ich "forsche" nur etwas. Die Kunden wollen Auszüge weiter auf MT940 Basis abwicklen. Da dort ebenfalls "nichts" brauchbares rüberkommt, hab ich mal einen Blick auf CAMT geworfen.

[ele]

Die MT940er sind noch viel schlimmer. Da sind gar keine Felder für solche Informationen vorgesehen, d.h. jede Bank packt die zusätzliche Informationen einfach ins Feld 86, aber jede auf eine andere Art und Weise.

Beim CAMT sind die Felder wenigstens vorgesehen, aber ob eine Bank diese auch wirklich verwendet steht in den Sternen. ISO2022 und SEPA eigentlich eine gute Idee, aber meiner Meinung nach wurde das Ziel einer Vereinheitlichung völlig verfehlt. Der Formate-Dschungel wird nun einfach mit XML fortgeführt.

[arnof]

Ihr Redet ja hier von Schweiz und Co.; Vereinheitlichung, das Format könnten auch Politiker mit Lobbyisten zusammen gestellt haben. Jedes Land macht trotzdem seinen eigenen "scheiss". Wenn man die IBAN Sonder-Regeln in Deutschland anschaut dann könnte man echt "Kotzen".

PS: die Bundesbank hat eben wieder gemailt: "die ab 3. März 2014 gültige Version der Übersicht der IBAN Regeln im ExtraNet der Deutschen Bundesbank zur Verfügung"

Ah ha 3 März, muss man dann nochmals die IBAN berechnen, man sollte ja vorher umgestellt haben! Die sind schon nicht ganz sauber ......

[sh17]

Ist bezüglich der mehrere Sequenzen jetzt schon was angedacht?

Wie sieht es denn Arnof? Komponente erweitern? Den Nutzer selbst die Lastschriften in die 4 Lastschriftarten einordnen lassen oder vor dem Export die Lastschriften entsprechend vorsortieren und die Ausgabe anpassen. Dabei wird aber ggf die Reihenfolge verändert.

[herbstrot]

Moin,

ich hatte das mal in der Komponente verändert, so das verschiednen Typen und Termine in eigene Zahlblöcke gepackt werden. Ist laut Definition eigentlich zulässig, nur die Sparkasse hat mir da einen Strich durch gemacht. Pro Sepa wird nur ein Zahlblock akzeptiert.

Wer hat eigentlich gesagt, mit Sepa wird alles einfacher? :evil:

[sh17]

Da würde ich der Sparkasse mal eine Frist bis August stellen das zu unterstützen :duck: