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

Hallo Elch, liegt am Aufbau der Umsatzinformationen, die die Sparda liefert. Wenn es Dich interessiert, erkläre ich gerne, was da bei denen nicht ganz Spezifikationsonskonform läuft.
Ansonsten für Dich vermutlich zunächst wichtiger :
Es ist wohl eine Umgehung angekündigt.
Aber versprech Dir nicht zuviel davon, die Umsätze, die ich da bisher gesehen habe, hatten nur noch einen rudimentären Verwendungszweck.

Viele Grüße

Holger

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.

Hallo zusammen,

die Internas wer da was und wie zu liefern hat, ist mir als reiner Endanwender vollkommen gleichgültig. Da ich aber gerne die Auswertung (Filter) von VRNetWorld nutze, habe ich zwischenzeitlich bei der Sparda nachgehört. Leider ist man sich dort jedoch keiner Schuld bewusst, seitens Sparda werden die Daten sehr wohl "HBCI-Konform" geliefert. Eine Änderung ist dort nicht erfolgt. Womöglich könnte aber eine Update oder die fehlerhafte Konteneinstellung bei mir ursächlich sein. Leider wüsste ich aber nicht, was ich da an welcher Stelle einstellen kann.

Da der Sachbearbeiter aber hier mitliest, könntet ihr die Hintergründe vielleicht doch an dieser Stelle noch weiter aufklären. Allzu tief wollte ich für meinen Teil eigentlich nicht in die Materie einsteigen…

Gruß elch

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.

Gerade die Diskussion über den HBCI Standard hatten wir bereits mehrfach. So ganz Standard ist die ganze Sache nicht, zudem vieles Interpretationssache ist. Ich frage mich auch, warum es jede andere Software hinbekommt nur VR-NetWorld nicht?

Sofern mir jemand definitiv Fehler im Standard der HBCI Kommunikation und des Protokolls darlegen kann, gebe ich dies gerne zur Diskussion weiter. Das letzte mal als wir ähnlichen Fall hatten, hat sich herausgestellt, dass vieles im Standard interpretationssache ist!

lg

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...

Um die langen Diskussionen zusammen zufassen:
Die Aussagen von msa sind im Kern richtig (in den Daten, die ich aktuell gesehen habe stellt sich das nicht ganz so extrem da, wie von Dir geschildert und wie viele Leerzeichen nach dem Bezeichner für den Verwendungszweck kommen ist -technisch und von der Spezifikation her- egal, da das als VWZ interpretiert wird.
In den Umsätzen, die ich gesehen habe, werden Referenzen und Verwendungszweck mit den richtigen Bezeichnern eingestellt. Das Problem ist vereinfacht -wie msa es richtig geschrieben hat- dass die Bezeichner nicht am Zeilenanfang stehen, sondern fortgeschrieben werden und so mitten in der Zeile stehen. Der erste Bezeichner für die Ende zu Ende Referenz wird so richtig ausgelesen (wenn belegt) und alles Andere wird dann nicht mehr richtig gelesen, da am Zeilenanfang nicht die Informationen stehen, die man erwartet.

Zitat der Spec: Jeder Bezeichner [z.B. EREF+] muss am Anfang eines Subfeldes [z. B. ?21] stehen. Bei Längenüberschreitung wird im nach folgenden Subfeld ohne Wiederholung des Bezeichners fortgesetzt. Bei Wechsel des Bezeichners ist ein neues Subfeld zu beginnen.

Softwareprodukte, die die SEPA Informationen aus dem Verwendungszweck nicht raus interpretieren, sondern einfach 1:1 als Verwendungszweck übernehmen haben damit in der Tat keine Probleme.

Für Elch aber die wichtigste Information: Wir hatten so einen Fall vor Kurzem mal weiter gegeben. So wie es aussieht hat die "Dehnung" der Spezifikation hier System, so dass man das wohl abfangen kann. In einer der kommenden Versionen soll das dann auch so erfolgen.

Viele Grüße

Holger

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.

Damit wir mal wissen, worüber wir reden. So schaut ein Original-netbank-Umsatz in MT940 aus (netbank läßt bei SPARDA-DV rechnen). Ich habe die Subfelder (Zeilen ?21 usw. der Übersichtlichkeit mal auf einzelne Zeilen gesetzt:



Korrekt müßte das wie folgt:



Dass Subsembly es KANN liegt daran, dass der Hersteller sich halt irgendwann erbarmt hat, und die Sonderlocke eingebaut hat.

Dass Networld offenbar Text verschwinden läßt, ist auch leicht erklärbar. In der ersten VZ-Zeile geht es mit dem Feldschlüssel EREF+ los. Die Referenznummer ist laut Spec beendet, wenn auf einem ZEILENBEGINN der nächste Feldschlüssel steht. Auf KEINEM der folgenden Zeilenanfänge steht ein Feldschlüssel - also ist das in der Zerlegung bis zum Ende ALLES immer noch EREF. Das wird ins Feld EREF der Datenbank geschrieben - das ist aber nicht so lang - also "verschwindet" das, was hinter dem Feldende steht.

Dass das so ist, liegt daran, dass Networld es gut meint und die Texte sinnvoll zerlegen will. Bei anderen Softwaren, wo das nicht passiert, versuchen die es nicht mal, die Feldschlüssel zu zerlegen, sondern knallen alles von vorneherein uninterpretiert in die VZ-Felder.

WARUM Sparda-DV keine neuen Zeilen anfängt, ist mir schon klar. Deren wunderbares HBCI-System kann wenn ich mich recht erinnere (auf jeden Fall war das vor SEPA so) über HBCI nur maximal 4 (!) VZ-Zeilen übertragen. Wenn man da korrekt neue Zeilen anfängt, wie es sich gehört, dann fällt hinten zu viel weg. Offenbar schafft man es aus irgendwelchen Gründen nicht, das anständig zu implementieren und alle VZ-Zeilen via HBCI zu übertragen, wenn es mehr gibt. Dass es mitunter mehr gibt, sieht man im WebBanking, denn DORT WERDEN alle Zeilen angezeigt.... Ich war seinerzeit sehr belustigt, als irgend eine Sparda in ihren FAQs auf die Beschwerde eines Kunden, der in seinem Programm irgendwelche Zahlungen nicht zuordnen konnte, weil zu viel vom Text fehlte antwortete: "Der Kunde kann ja im WEB nachgucken, da steht mehr Text drin".

Die Beschwerde des Thread-Starters hatte ich im Übrigen so verstanden, dass er nach FELDERN filtern will, also nicht einfach nur über SCHMID im gesamten Text sondernüber SCHMID im FELD VZ oder so.... Wenn der Großteil des Textes in Networld garnicht ankommt (ich weiß es nicht, ich hab zwar irgendwo eine Büro-Testversion von Networld, aber darin nie ein SPARDA-DV-Konto abgefragt, dann ist das natürlich besonders störend. Aber wie geschrieben, dann nur auf den Guten Willen vom Programm zurückzufürhen. Die anderen Hersteller, die es nicht mal versuchen, sind hier natürlich im Vorteil

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 msa,

perfekt beschrieben (wenn man die "Sticheleien" mal rausfiltert). Deckt sich mit meinen Beschreibungen und Interpretationen, die ich im Supportfall abgebe. Ich wollte es nur nicht so ausufern lassen, da die wichtigste Info für Elch ja die war, das man schauen wird, auch diese Besonderheit abzufangen. Die Unterschiede in unseren beiden Fällen sind übrigens interessant, mein Aufteilung ist ein echter Umsatz, ich habe nur die Ziffern geändert. Die Ende zu Endereferenz scheint auch bei voller Ausnutzung übertragen zu werden, alle anderen Infos insbesondere der VWZ wird im Zweifel gekürzt.
Der Wegfall des VWZ kann im Übrigen auch bei voller Nutzung der 14 möglichen VWZ bei allen Banken passieren.... Daher ist die Ende zu Ende Referenz im Zweifel wichtiger!

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.

Auf den ersten Blick scheint das geschilderte Problem mit der neuen Version 6.0 gelöst!

Nach dem Update wurden mir eben einige Umsätze (allerdings nur ein paar Tage zurück) neu heruntergeladen und blau markiert.
Vielen Dank für die Unterstützung ans Forum und die Entwickler.

Gruß elch

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