Hallo,

ich möchte gerne die eingehenden Buchungen auf meinem Konto automatisiert meinen Geschäftspartnern zuordnen. Dazu kann man prima den Eintrag "Gegenkonto" und "Gegenkonto BLZ" im CSV-exportierten Kontoauszug benutzen. Allerdings ist mir aufgefallen, das einige Umsatzzeilen keinen Wert enthalten. Bisher hatte ich das nicht so ernst genommen, weil das ja nur ein paar waren.

Heute ist mir allerdings aufgefallen, das das genau die sind, deren Verwendungszweck mit "SVWZ+" anfängt. Ich vermute mal, das es sich um Überweiser handelt, die Ihrerseits SEPA für Überweisungen nutzen. Irgendwie ist es ja auch ein bisschen logisch, das ich keine Kontonummer angezeigt bekomme, weil diese Leute ja gar keine mehr haben, sondern nur noch eine IBAN.

Meine Frage also: Ist es möglich, die IBAN des Gegenkontos zu empfangen und diese entweder in das Kontonummer-Feld zu schreiben oder dafür ein eigenes Feld bereitzustellen? Sonst ist die Möglichkeit der automatischen Zuordnung ab Februar futsch.

Thomas

Derzeit ist der Standard für Kontoauszüge MT940. Das ist aber nicht für SEPA geeignet, daher sieht man im Verwendungszweck auch die ganzen Feldkürzel die für das neue Format gedacht sind. Und dieses neue Format nennt sich camt. Aber es gibt bislang weder Banken noch Software, die das im Regelbetrieb nutzen/unterstützen.

Mit etwas Glück ist das bis Februar in der Praxis geregelt. Bis dahin musst du eine andere Zuordnungsmöglichkeit finden.

Also ich habe mir mal den MT940 Standard angesehen ("Spezifikation der Datenformate" - "Version 2.6 vom 18.06.2012 (Final Version)"). Da steht im Feld 31 durchaus die IBAN. Das scheint also nicht ganz abgeschrieben zu sein (ohne das ich mir jetzt die Unterschiede im Detail angesehen habe und abgeschätzt habe, was man da noch alles für ändern muss).

In der Fußnote dort steht:


Wenn ich da in den nächsten Wochen Zeit zu habe, werde ich da mal meine Volksbank ausquetschen, was die sich da so denken.

Ich nehme mal an, das ein angepasstes Feld im bisherigen Format für Hibiscus den kleinsten Aufwand der Implementierung darstellt.

Mal eine Frage dazu: Habe ich das richtig verstanden, das im Prinzip HBCI4Java per HBCI (quasi als Transportprotokoll) eine MT940-Datei empfängt und diese dann parst?

Thomas

Dauerauftrag Netbank --> Ziraatbk
Alle Daten stehen im Verwendungszweck:

GENODEF1S1513111
/DE39200905000001234567
Mvvvvvv Lzzz ODER, Uvv Szzz
GENODEF1S15
TASCHENGELD Fvvvv

Ein Fall für den Beautifier?

tbayen, dass im MT940 ein Feld für die IBAN existiert heißt nicht, dass die Struktur für SEPA paßt. Für SEPA gibt es schlicht und ergreifend einige mehr Felder (bei Lastschriften wird das richtig deutlich) die demnächst im camt Format sauber dargestellt werden.
Bis das Realität ist müssen die Banken die Feldinhalte inklusive Feldname noch komplett in den Verwendungszweck schreiben.
Das könnte man parsen aber ob das noch lohnt? Und soweit ich das bisher beobachte sieht das bei den Banken auch nicht durchgängig gleich aus. Das heißt im Extremfall, Olaf müsste für jedes RZ einen Parser machen.


Soweit ich das sehe ja. Worauf genau kommt es dir bei der Frage an? Auf die Komponenten in der Kommunikation oder auf das Format? Entscheidend bei der Frage ist auch, ob es dir um Umsätze oder Kontoauszüge geht. Das ist ein himmelweiter Unterschied, bei beidem kann MT940 beteiligt sein, hat aber ganz andere Auswirkungen.

sme: In welcher Umgebung/Software sieht der Verwendungszweck so aus?

Na, unter Hibiscus natürlich.

Aber offensichtlich scheint jede Bank ihr eigendes Ding zu machen.
Hier die Angaben im Verwendungszweck bei einem Dauerauftrag
Netbk --> PostSparCard:

Referenz NOTPROVIDED Verwen
dungszweck TASCHENGELD

Immerhin steht hier der Absender an der richtigen Stelle

OK, dann hat entweder Olaf schon einen Parser begonnen oder die Banken machen es wirklich alle unterschiedlich, was einen Parser nahezu unmöglich macht.

@onlbanker: Die Entscheidung, ob und ab wann es sich lohnt, camt zu verarbeiten, möchte ich - solange ich selber keine Zeit dazu habe - erst einmal Olaf überlassen.

Du magst zwar Recht haben, das es jetzt mit SEPA mehr Informationen gibt. Aber den meisten Leuten geht es doch um die Information, wann ich von wem wieviel Geld bekommen habe und was für ein Kommentar da dransteht.

Ich selber benutze sehr viele Lastschriften. Wenn die jetzt z.B. platzt, löst das in Zukunft bestimmt einen bunten Regen an Datenfeldern aus. Aber Tatsache ist: Das Geld ist von meinem Konto runter. Ich muss den Kunden anrufen und zur Schnecke machen. Alle anderen Informationen sind zwar "nice to have" aber ehrlich gesagt nebensächlich. Deshalb sind die im Verwendungszweck gar nicht so schlecht aufgehoben.

Na ja, ich werde das mal ein paar Wochen beobachten, zuerst mal meine Problemchen mit dem SEPA Zahlungsverkehr lösen und dann sehen, was meine Bank (und Olaf) bis dahin dazu sagen...

Meine Frage nach dem Ablauf des Imports war eigentlich rein informativ. In meinen Recherchen finde ich es immer noch etwas verwirrend, das sich SEPA und HBCI an einigen Stellen zu ergänzen, an einigen zu ersetzen und an einigen überhaupt nicht zu überschneiden scheinen. Ich arbeite in einem international ausgerichteten Softwareprojekt und habe oft Chats mit Leuten, die nur Bahnhof verstehen. Selbst ein Franzose erklärt mir, das die Übertragung der Daten doch von jeder Bank selber gestaltet wird und meistens über die Webseite geht. (Mal ganz abgesehen von dem Malayen, der mich fragt, warum ich nicht wie jeder normale Mensch Schecks nehme, die seien doch eh viel einfacher und übersichtlicher ). Mir ging es also um die Abgrenzung von HBCI im Vergleich zu den international üblichen Standards. Wenn ich nun Glück habe, baut der Malaye ein Zahlungsmodul für Schecks, der Franzose erzeugt daraus anstatt einem Ausdruck eine SEPA-XML Datei und Olaf schickt mir die dann zu meiner deutschen Bank. Und ich spiele nur noch Software-Lego.

Im Moment habe ich in Hibiscus noch keine SEPA-spezifischen MT940-Spezialparser drin. Und hab eigentlich auch nicht vor, die reinzubauen. Im Moment ist hier aus meiner Sicht noch viel zu viel Durcheinander seitens der Banken. Die stellen grad alle wie verrueckt ihre Systeme um und gefuehlt verhalten die sich jede Woche anders, weil die auf Bankseite ja auch dauernd Updates machen, nachbessern, erweitern, umstellen...

Solange da noch keine Ruhe reingekommen ist, bringt es nichts, hier spezielle Parser zu bauen, die 3 Wochen spaeter eh wieder hinfaellig sind. Wenn sich der SEPA-Wirbel Anfang naechstes Jahr hoffentlich etwas legt, kann man mal schauen, ob bei der Struktur in den MT940-Verwendungszwecken ein brauchbar zu parsendes System erkennbar ist.

In dem Zusammenhang: Voraussichtlich wird es gegen Mitte Dezember ein Hibiscus-Release geben, das dann erstmal den bisherigen SEPA-Stand enthaelt. Also SEPA-Ueberweisungen und -Lastschriften. Insbesondere, damit Heiner ein JVerein-Release fuer die Vereine machen kann.

Derzeit aendert sich wegen dem SEPA-Zeug so viel, dass quasi gar keine Zeit bleibt, den Code mal etwas "abhaengen" zu lassen, um in Ruhe ein Release zu machen. Daher halt erstmal eine Art Zwischen-Release, welches den derzeitigen SEPA-Stand enthaelt. Und dann Anfang naechsten Jahres nochmal ein Release mit weiteren SEPA-Updates.

Heisst das, das es Mitte Dezember SEPA-Lastschriften auch als Sammler geben wird? (Freu!)

Nein. Das heisst, dass es Mitte Dezember ein Release geben wird, welchem dem Feature-Stand des aktuellen Nightly-Build entspricht.

Die freudige Erwartung kam daher, das Du JVerein als Grund angabst. Ich dachte, der Einzug der Mitgliedsbeiträge müsste ein Lastschriftsammler sein...

Ich verstehe diese Aussage nicht. Bitte hilf mir auf die Sprünge.

Zu camt: ich habe selbst nicht die geringste Ahnung, was die Banken sich da so vorstellen, wann sie das einführen wollen. Habe von welchen gehört, die schon mit ausgesuchten Kunden testen. Und wenn ich an solche wie die Sparda denke habe ich wenig Hoffnung, dass das noch dieses Jahrhundert wird. Ich fürchte, die Umstellung auf camt wird noch schlimmer als die auf SEPA im ZV.

JVerein ist derzeit so programmiert, dass es SEPA-Einzellastschriften in Hibiscus erstellt. Wir werden das noch auf Sammeauftraege umstellen. Aber vorher machen wir ein Release mit dem aktuellen Stand. Sammelauftraege kommen dann mit einem 2.6.x Update.

@onlbanker: Als Erklärung zu meiner Bemerkung:

In einem Open Source Projekt finde ich es nicht so höflich, mich lautstark über die Vor- und Nachteile dieser und jener Lösung zu unterhalten, ohne gleichzeitig Verantwortung für die Umsetzung zu übernehmen. Ich kenne das aus meinem eigenen Projekt, das Leute vorbeikommen, rumtönen, wie es gemacht werden soll und wenn ein Programmierer dann Arbeit reingesteckt hat, hört man von denen nie wieder was. Meine Bemerkung sollte also bedeuten, das ich keine Zeit habe, für das Thema camt Verantwortung zu übernehmen und ich außerdem bisher keine Ahnung davon habe und das ich mich deshalb am besten mit einer eigenen Meinung zurückhalte. Oder wie Dieter Nuhr es mal ausgedrückt hat: "Wenn man keine Ahnung hat - einfach mal die Fresse halten!"

Ich hoffe nicht, das Deine Nachfrage bedeutet, das Du das gegen Dich aufgefasst hattest. Wenn ich mir Deine Beitragszahl hier ansehe, bist Du ein engagiertes Mitglied und ich habe den Eindruck, das Du weisst, wovon Du sprichst und auch Verantwortung für das Gesagte übernimmst. Nur für mich gilt das eben nicht, weil ich mir hier noch keine Meriten verdient habe.


@hibiscus: Danke für die Erläuterung des "Release-Plans".

So ganz kann ich nicht folgen, tbayen. An deinen Beiträgen fand ich nichts verwerfliches.
In Beitrag 5 war noch eine Rückfrage zu deiner Frage offen. Oder ist das erledigt?

Ich wusste halt nicht, warum Du nachgefragt hast, (weil ich Dir gerade nicht folgen konnte).

Zu Beitrag 5 hat mir Dein Anfang "Soweit ich das sehe Ja" für den Moment gereicht. Für den Moment ist die Botschaft, die ich vernommen habe, das ich erstens mal abwarte, was sich in den nächsten zwei Monaten noch tut und das ich mich zweitens wenn ich da ernsthaft was ändern möchte, was sich bis dahin nicht von alleine erledigt, wohl etwas mehr einlesen müssen werde. Dann weiss ich, wo ich nach der Richtung frage.

Hallo,
bei Sparda-/Netbank sieht es immer noch so aus.


Ing-Diba:


Die Deutsche-/Berliner-Bank macht aus einer Überweisung:

Immerhin stehen hier IBAN + BIC im richtigen Feld (Kto + BLZ)

die ZiraatBk stellt dem Verwendungszweck eine Nr. voraus


Fiducia/Volksbank:
IBAN/Bic stehen nach dem Verwendungszweck:

Im BLZ-Feld steht die alte BLZ

Gehört das alles zum Stichwort "camt"?
Oder muß hier doch irgendwann der Parser ran?

Hallo sme,

mit camt hat das alles nichts zu tun (ausser das das ggf. die Lösung wäre)
Das Problem ist komplexer und hängt damit zusammen, dass SEPA Informationen in das alte Format MT940 gequetscht werden müssen.
Jetzt kommen ganz viele Abhängigkeiten zusammen
-> Maximaler Umfang der VWZ Zeilen, die eine Bank liefern kann
-> Strukturierter oder unstrukturierter VWZ
-> Überweisung oder Lastschrift
-> Auftraggeberkonto
-> Werden zusätzliche Informationen eingestellt?
-> Wie sinnvoll ist die Umsetzung

Die Angabe der EREF mit NOTPROVIDED ist z.B. eine sinnlose Platzverschwendung.
Die zusätzliche Information von IBAN und BIC im VWZ erhöht die Lesbarkeit durch den Endkunden, wenn die Software das nicht aufbereitet

Viele Grüße

Holger