Verwendungszweck fehlt bei SPARDA

Hallo zusammen,

mal wieder ein Problem mit der SPARDA-Bank:

Seit einiger Zeit bleibt das Feld Verwendungszweck in meinen Kontoumsätzen bei externen Zahlungsaus- und eingängen leer. Bank-interne Buchungen werden hingegen angezeigt. Kann das jemand bestätigen, und was kann man tun?

Gruß elch

Das, was die SPARDA-DV an Daten liefert, ist eigentlich eine Frechheit. Entspricht in keinem Fall der Spezifikation und ist ein häßliches Durcheinander, bei dem div. Dinge ganz fehlen. Das kann man ja schon im Web-Banking sehen. Um daraus was halbwegs sinnvollen in die Datenbank zu bringen, sind umfangreiche Verarbeitungen nötig (also Textstringakrobatik mit explizitem Eingehen auf die Fehler des SPARDA-Formates). Ich kenne derzeit nur ein einziges Programm, das sich das antut, das sind die Programme und Apps von Subsembly. Alle anderen Hersteller lassen sich meines wissens nach darauf nicht ein, deswegen steht da dann nur ein Durcheinander in den Feldern der Kundenprodukte.

Leider ist das, was man Dir da gesagt hat NICHT richtig. Daß Dir als Endanwender das egal ist, ist natürlich berechtigt, hilft aber hier nicht weiter. Softwarehersteller bauen Produkte, die auf Standards aufsetzen, wenn diese Standards nicht eingehalten werden, dann klappt es eben nicht richtig. HBCI-konform - das stimmt sogar - man kann durchaus per HBCI "etwas" abfragen bei Sparda. Nur das "etwas" muß einen spezifizierten Aufbau haben, um weiterverarbeitet werden zu können. Mit der SEPA-Umstellung gab es ein Problem. Es wurden neue Felder eingeführt, die im alten Übertragungsformat nicht spezifiziert waren. Um sich zu behelfen, wurde ein Workaround spezifiziert: Man packt die Felder, die nicht vorgesehen sind, versehen mit Feldschlüsseln in einem ganz bestimmten Aufbau in die Verwendungszweckzeilen.
Die Spezifikation verlangt, dass SEPA-Feldschlüssel verwendet werden (meist 4stellig), danach ein + kommt nud danach sofort der Feldinhalt folgt. Wenn die VZ-Zeile nicht reicht, dann geht der Feldinhalt sofot auf Spalte 1 in der nächsten Zeile weiter. Das nächste Feld beginnt dann mit dem entsprechenden Feldschlüssel vorneweg auf der nächsten Zeile.

Leider macht es SPARDA-DV "etwas anders". Man schreibt in die erste Verwendungszweckzeile den Zahlungsgegnernamen ohne Feldschlüssel, danach ohne Feldschlüssel die Buchungsart (also z.B. SEPA-BASISLASTSCHRIFT, danach dann den Verwendungszweck-Schlüssel SVWZ+ gefolgt von einem Leerzeichen (nicht so vorgesehen) und dann alle Verwendungszwecke dahinter, dann wieder ein Leerzeichen, gefolgt von einem Feldschlüssel mit + und Leerzeichen und dann andere Angaben. Dieser Bandwurm wird dann in die Verwendungszweckzeilen gepackt und übertragen. Somit finden Softwareprodukte, die das auswerten wollen, keinen Anfang (teilweise ohne Feldschlüssel, und dann Feldschlüssel irgendwo mitten im Text, wo es gerade kommt und NICHT am Zeilenanfang) und auch kein Ende (neue Zeile). Insofern können die Softwareprodukte das nicht sinnvoll in die Datenbank einordnen und somit kannst Du es auch nicht suchen oder finden.

Mir ist unklar, wie man von Seiten des Rechenzentrums die recht eindeutigen Vorgaben so dermaßen verfehlen kann. Zumal diese Version der Darstellung auch erst ein langer Prozeß war, am Anfang wurde den Kunden (!) noch schlimmerer Kauderwelsch, der ausschließlich mit dem Auge Sinninhalt erkennen ließ, keinesfalls aber maschinell auswertbar war, serviert. Man hat es nicht erst getestet, sondern irgendwas programmiert und das dann in den Echtbetrieb gegeben und das dann xmal im Echtsystem geändert. Alle paar Tage kam ein anderer Dialekt heraus, aber niemals das, was ein Kundenprodukt verstehen würde. Irgendwann - bei der jetzigen Version - blieb es dann und es wurde gesagt, das bleibt jetzt so - dass das nicht den Spezifikationen entspricht, war denen völlig egal - oder sie haben es nicht verstanden - ich weiß nicht was schlimmer ist.

Wenn also nun ein Softwareprodukt nicht explizit eine Sonderbehandlung für SPARA-Banken (und netbank, die auch da rechnen läßt) einprogrammiert bekommt, dann kommt nur Unfug in der Datenbank dabei heraus (wenn denn das Produkt versucht, die einzelnen Felder zu erkennen). Ich kenne bisher nur ein einziges Kundenprodukt, wo sich der Hersteller die Mühe gemacht hat, eine Sonderbehandlung für SPARDA einzubauen. Alternative wäre, das alles einfach unzerlegt in Textfelder der Datenbank zu knallen (so wie es im SPARDA-WebBanking der Fall ist). Bei VR-Networld würde ich nicht erwarten, daß die für Sparda in Ihrem Programm eine Extra-Wurst braten und pflegen, denn das ist eigentlich ja auch nicht ihre Aufgabe...

Daß ein Sachbearbeiter bei der einzelnen Bank das technisch nicht durchschaut ist klar, das ist auch nicht seine Aufgabe. Das wäre die Aufgabe von Programmierern der SPARDA-DV, also dem Rechenzentrum in Nürnberg, denen scheint es aber egal zu sein. Man will wohl irgendwann mal den neuen Übertragungsstandard CAMT statt MT940 einführen, das hat man jedenfalls damals bei den ständigen Änderungen Softwareherstellern gegenüber erklärt, aber davon hört und vorallem sieht man jetzt nichts (mehr). Aber es war auch nicht gesagt worden, WANN das erfolgen soll oder könnte.

Welche Software kommt denn mit den geliefertern Daten von SPARDA zurecht? Also ich meine jetzt, dass die Felder korrekt anhand von Feldschlüsseln zerlegt und in die richtigen Datenbank-Felder gesetzt werden... Dass man die kompletten Strings einfach so hintereinander in Verwendungszweckfelder klatschen kann zählt da nicht!!

Dass sämtliche Standards grundsätzlich "interpretiert" werden, ist so alt, wie das Onlinebanking überhaupt. Schon zu BTX-Zeiten war es so, daß im Prinzip jede Bank alles anders interpretiert hat, es ist unglaublich, wieviele MT940-Dialekte es gibt. Wenn man 5 Banken nimmt, dann kriegt man 6 verschiedene Interpretationen/Daten für den gleichen Vorgang. Letztendlich muß es dann immer das Kundenprodukt richten und auf die "Feinheiten" des jeweiligen Rechenzentrums eingehen - am Ende hat man dann einen kaum mehr pflegbaren Wildwuchs, für jedes Rechenzentrum einen extra Programmteil, um die Interpretation wieder zurückzuinterpretieren. Aber wie gesagt, das war schon von aller Anfang an so. Ich habe Anfang der 90er Jahre bei der Firma gearbeitet, die das damals einzige deutsche Onlinebanking-Programm entwickelt hat, welches von fast allen Banken in Deutschland vertrieben wurde. Anfangs wurden noch Daten über die Maskendialoge ausgelesen - klar, da brauchte man für jede Bank ein extra Modul. Das mit der Interpretation ging dann los, als man sich auf den ZKA-Dialog über MT940 einigte...

Subsembly!
Aber ich wüsste auch keine anderen Programme außer VR-Networld, welche dann einfach den kompletten Verwendungszweck leer lassen. Selbst wenn die Software die Daten nicht in alle Felder richtig zuordnen kann, warum haut die nicht einfach die kompletten Strings in den Verwendungszweck? Immerhin sieht man dann den Inhalt, auch wenns optisch nicht ganz optimal ist. Ist aber immer noch besser als die Daten in gar kein Feld zu übertragen.

Relativ einfach, der VWZ steht beim MT940 für SEPA Buchungen nach dem Bezeichner SWZ+ alles Andere ist bei einer solchen Buchung kein Verwendungszweck.
Wenn der technische Verwendungszweck auch nicht richtig mit einem richtigen Bezeichner an der richtigen Stelle starten würde, würden die Daten auch als "alte" Form des Verwendungszweck interpretiert werden. Das Problem ist also der richtige Start und dann die andere Belegung. Entweder interpretiert man halt SEPA oder nicht. Und die VR-NetWorld Software hat sich für den Weg entschieden, dem Kunden die Daten entsprechend aufzubereiten, damit er damit etwas anfangen kann. Denn ein VWZ :

hilft dem normalen Kunden nicht wirklich weiter.

Viele Grüße

Holger

Hallo,

das bei mir ist schon auch ein Originalumsatz eines meiner Konten, nur etwas anonymisiert. Daß letztendlich bei SEPAoverMT940 immer die Gefahr besteht, daß hinten "was rausliegt" ist eh klar und letztendlich nicht zu umgehen, wenn man irgendwie "mehr in weniger" reinpackt. Damit kann ich irgendwo auch leben. Aber wenn man halt nur 4 Stück MT940-Verwendungszweckfelder zu je 27 Stellen in seinem HBCI-System übertragen kann, dann fliegt eben sehr schnell was raus...

Die Sticheleien seien mir bitte verziehen, weil ich mich da irgendwo schon seit Jahren drüber ärgere. Wenn man weiß, wie es zusammenhängt und daß eine Behebung in der Sache sehr einfach wäre, dann nervt das halt, wenn es einfach ignoriert wird. Als EDVler weiß ich andererseits natürlich auch, dass man da Änderungen in einem gewachsenen System macht - und wer weiß womit die da leben müssen, und was es für riesiger Umwälzungen bedürfen würde, es korrekt (mit mehr MT940-VZ-Feldern) umzusetzen. Und zur Ehrenrettung der SPARDA-DV sei hier auch mal was gesagt: Die sind, was die Transaktionen betrifft, unheimlich schnell, geradezu beängstigend schnell. Daß innerhalb des Rechenzentrums Umsätze bei anderen Banken innerhalb von max. 15min erscheinen ist noch halbwegs normal, wenn auch nicht Standard. Sparkassen brauchen innerhalb FI mitunter sogar einen ganzen Tag. SPARDA-DV schafft es aber auch in die außenwelt fast immer noch am gleichen Tag. Und zwar eigentlich in alle Richtungen. Mir ist es aufgefallen zu FIDUCIA, GAD, FI, ING-DiBa, Hypovereinsbank. In allen Fällen erscheinen Zahlungen von SPARDA weg dort noch am gleichen Tag, teils auch umgekehrt. Das schönste was ich erlebt habe war ein DA von Hypovereinsbank zu Sparda-DV. Er erschien bei Sparda als Zahlungseingang mit Valuta x, bei der Hypovereinsbank erschien er als Zahlungsausgang - nach der Nachtverarbeitung dort natürlich - mit Valuat x+1 !! Rechnerisch war er also angekommen, bevor er abgegangen war. Sowas hätte man sich in Zeiten der Hochzinsen durch Hin- und Herschieben von Millionenbeträgen zu Nutze machen sollen :bandit:

Die EREF wäre sicher für Rechnungsnummern oder so die erste Wahl - allerdings traue ich sie mir nie so recht hernehmen, weil es einfach noch viel zu viele Systeme gibt, die nichts damit anfangen können und Eintragungen in EREF ignorieren und teils nicht mal dem Buchhalter anzeigen.

Sehr befrendend finde ich in dem Zusammenhang der WebBanking von FIDUCIA: Da kann man nur alternativ ENTWEDER VZ ODER EREF eingeben. Sobald in eines der beiden Felder etwas eingegben wird, wird das andere abgeblendet. Was soll davon wohl der Sinn sein? Denn zumindest über HBCI nimmt man auch Zahlungen mit beiden belegten Feldern an.

Hallo Elch,

ja, die Auswertung der Umsatzinformationen ist felxibilisiert worden, um auch einige kreative Auslegungen der Spezifikation unterstützen zu können.
Aus der Readme:
9.4 Erweiterung der Umsatzverarbeitung
Die Umsatzverarbeitung wurde erweitert, um Umsätze mit SEPA-Bezeichnern, die entgegen der Spezifikation nicht am Feldanfang stehen, dennoch richtig und vollständig auslesen zu können.

Viele Grüße

Holger