Hallo zusammen,

ich habe folgendes Problem, eine Kundin unseres Hauses (Raiba) hat Konten bei der Stadtsparkasse München. Diese Konten sollen in der VR-Networld Software eingerichtet werden. Die Bankverbindung (HBCI PIN/TAN) lässt sich ohne Probleme einrichten und synchronisieren. Das Konto wird auch automatisch eingerichtet. Die Umsätze lassen sich einmalig aktualisieren. Die Umsätze werden dann mit der Jahreszahl 2007 abgezeigt. Ein erneutes aktualisieren ist dann nicht mehr möglich, da das von Datum (2007) nicht stimmt. Auf dem Rechner der Kundin ist das richtige Systemdatum eingestellt. Die Hotline der Stadtsparkasse hat gemeint, dass es diesbezüglich ein Fix für die VRNWSW gibt, da diese die MT940 Umsätze falsch interpretiert. Es ist die Version 3.02 installiert. Ist jemandem von Euch dieses Problem bekannt, bzw. gibt es tatsächlich ein Fix für die Stadtsparkasse München?

Besten Dank im voraus.

MfG
Daywalker

Für die Stadtspk. München gab es in der V. 3.0 kein Zertifikat - das Problem sollte aber mit der Version 3.02 nicht mehr auftreten. Von falschen Jahreszahlen habe ich noch nichts gehört...

Hm also davon hab ich leider auch noch nix gehört. Aber ruf doch mal bei der Rechenzentrale (Fiducia?) an, die müssten das doch wissen oder?

Hallo zusammen,

parallel zu diesem Eintrag hab ich bei unserer Fiducia eine Anfrage gestellt. Die Lösung ist folgendermassen:

1. Die Stadtsparkasse München liefert anscheinend keine Jahreszahl mit den Umsätzen (MT940) -> Die VR-Networld Software interpretiert die Umsätze mit einer falschen Jahreszahl.

2. Anhand des Protokolls der ersten Aktualisierung kann ein MT940 Satz erstellt werden, der dann (nach löschen der ersten Umsätze) in die VR-Networld SW importiert wird.

3. Anschliessend kann das Konto angeblich normal bedient werden.

Vielen Dank für Eure schnellen Antworten. Falls dieses Vorgehen nicht funktionieren sollte, werde ich Euch auf dem laufenden halten.

Gruss
Daywalker

Das Problem ist, technisch ausgedrückt, folgendes:
Das Buchungsdatum im :61:-Satz der einzelnen Umsätze im MT940 enthält grundsätzlich keine Jahresangabe. Es muss jedoch zu jedem Wechsel des Buchungstags ein :62:-Satz (Endsaldo) eingestellt werden.
Die Spk München tut dies anscheinend nicht, sondern liefert nur einen :62: am Ende des kompletten MT940. Das ist so lange kein Problem, als kein Jahreswechsel im abgerufenen Intervall liegt. Befindet sich allerdings ein Jahreswechsel in diesem Bereich, können die Jahresangaben nicht korrekt ermittelt werden und es kommt zum beschriebenen Effekt.
Wenigstens der Jahreswechsel sollte also von der anlieferenden Bank als Wechsel des Buchungstags angesehen und auch so übermittelt werden.

Ja und Nein...

Das Buchungsdatum ist gemäß Swift-Standard ohne Jahresangabe, zu jeder Buchung existiert aber ebenfalls im Feld :61: die Angabe der Valuta, und die ist mit Jahresangabe.

z.B. so: :61:0608310831CR450,00N060NONREF

Aus der Valuta-Jahresangabe kann man doch auf das Jahr des Buchungsdatums schliessen. Mehr als ein Jahr Abweichung gibt es nirgendswo zwischen Buchung und Valuta, am Jahreswechsel muss man etwas aufpassen. Sonnenklar ist aber wohl, das wenn die Valuta z.b. 02.01.06 ist und die Buchung 30.12. datiert ist, es sich um das vergangene Jahr handelt.

Zur richtigen Interpretation brauche ich -nach meiner Meinung- kein anderes Feld, wie z.B. den Endsaldo.

Das hätte ich zunächst auch gedacht, habe mich als nicht-Banker aber aufklären lassen, dass Valuta und Buchung u.U. auch sehr weit auseinander liegen können. Der Schluss von Valuta auf Buchung wäre dann nicht ohne weiteres möglich.

Hallo,

ich habe das genau so wie von Capt Frag beschreiben immer programmiert. In den DDBAC, FinPocket, Subsembly FinTS API, usw. wird Jahreszahl zum Buchungsdatum immer so gewählt, dass der abstand zum Wertstellungsdatum minimiert wird. Wenn der reale Abstand mehr als 6 Monate ist, wird die falsche Jahreszahl gewählt. Aber, kann das wirklich vorkommen?

PS: Es gibt noch viele andere Banken die keine Zwischensalden für die Buchungstage einstellen und nur ein einziges Schlusssaldo für den gesamten abgerufenen Zeitraum.