Falscher Anfangssaldo beim Sparkassenkonto

Hi Vielleicht,

ich halte das auch für einen Programmierfehler, aber vom Sparkassenrechenzentrum. Wir haben das mal analysieren lassen und dabei erfahren, dass die VR-NetWorld Software in der Regel keine Salden berechnet, sondern die Salden verwendet, die die Bank liefert. Hierbei hat sich auch gezeigt, dass das Sparkassenrechenzentrum die Salden mit den falschen Daten liefert. D.h. die VR-NetWorld Software zeigt nur die falsch gelieferten Salden an. Mehr nicht.

Gruß

Holger

Hi Michael,

nicht absurd! Das hat auch nicht mit Tricks zu tun, sondern einfach mit der Logik, wie Umsätze verarbeitet werden.
Es hindert ja niemand einen Hersteller daran, die Salden selber zu berechnen, oder die Umsatzinformationen anders aufzubereiten. Nur die VR-NetWorld Software sagt halt, dass sind die Daten, die die Bank liefert, die wird wissen was sie macht. Leider ist das wohl nicht imemr der Fall.

Gruß

Holger

Hallo Holger,

Danke für die schnelle Antwort.
Wenn ich ein Programm schreibe das Daten aus diversen Anwendungen (Datenbanken, Dateien) analysiert, aufbereitet und Anwendern zur Verfügung stelle, diese Daten dann nicht richtig Darstelle weil meine Programierlogik nicht korrekt ist, dann mus ich den Fehler bei mir suchen.
Ich kann nicht sagen die Daten werden mir falsch geliefert. Auch wenn die Daten nicht so ankommen wie sich die Volksbank das Vorstellt. Dann sollen Sie sagen das Programm ist nicht Sparkassen geeignet.

Gruß Vielleicht
Besser Nicht

P.S. Das Programm halte ich ansonsten für eines der Übersichtligsten auf dem Markt und es bleibt immer noch mein Favorit. Nur Firmenkunden, die Ihre Auszüge daraus erstellen, können nichts damit anfangen.

Ach, so ist das also.
Mich wundert daran nur, dass das jetzt erst auffällt. Auch wir (Sparkasse) haben nämlich etliche Kunden, die VR Networld verwenden. Von einem falschen Saldo hab ich in dem Zusammenhang noch nicht gehört.

Grüße

Hi Michael,

in der VRNWS fällt das nur auf, wenn man die Umsatzansicht so einschränkt, wie es "vielleicht" beschrieben hat, oder wenn die Anzeige "Tagessalden anzeigen" aktiv ist, oder wenn man die Option fehlende Buchungen ermitteln an hat. Da fügt die VRWS eben eine entsprechende Umsatzlücke ein, da hier Endsaldo, Tagesanfangssaldo und die Buchungen die dazwischen liegen kontrolliert werden.

Gruß

Holger

Hi Holger,

in der VRNWS fällt das immer auf. Weil der Anfangsbestand der Sparkassen nie stimmt. Er wird immer falsch übermittelt.
Man scrollt nur nicht mehr nach oben und sieht sich den Anfangsbestand an. Nur Firmen die sich Tagesauszüge oder Wöchentliche Auszüge Drucken lassen wollen haben das Problem. Auch wird wiederum beim Export in eine MT940 Datei der Falsche Anfangsbestand mit eingetragen.
Somit ist die Aussage: "Umsätze kommen in einem spziellen Format (MT940) das spezifiziert wurde, damit jeder, der es nutzt auf den gleichen Standard bauen kann." zwar richtig aber die Spezifikation falsch.
Hier sollte man die Spezifikation überarbeiten, damit nicht jeder machen kann was er will.
Natürlich möchte jeder sein Bankprogramm vermarkten. Aber das geht zu lasten des Kunden. Oder die Programmierer müssen ihre Bankprogramme auf solche Tatsachen einstellen.
Hier sehe ich Handlungsbedarf für VR-NetWorld. Das Programm ist ansonsten Top.
Wie ist das in anderen Programmen, gibt es da auch diesen Fehler?
SFirm wird vermutlich Funktionieren. Hat jemand ne Alternative oder einen Lösungsvorschlag wie ich diesen Fehler umgehen kann?

Übrigens: Wenn man wie Holger beschrieben hat die Funktion "Fehlende Buchungen ermitteln und anzeigen" einschaltet, dann Bekommt man bei den Sparkassenkonten diesen Fehler ja deutlich Angezeigt. Das kann es doch nicht sein oder?

Gruß Vielleicht
Besser Nicht

PS. Danke für eure Antworten. Hier wird man wenigsten nicht mit seinen Problemen allein gelassen. Jetzt brauchen wir nur noch eine Lösung - Bitte VR-NetWorld.

Hallo Captain,

Danke für die Ausführung und Erläuterung der MT940. So Tief stecke ich in der Materie aber nicht drin. Habe mir aber trotzdem mal das Übermittlungsprotokoll der Sparkasse angesehen und muss feststellen das die Daten Feld 60F = Startsaldo und Feld 62F = Endsaldo richtig sind. (Gleicher Betrag und gleiches Datum) Somit:


dieses Argument stimmt. Der Betrag ist gleich. Auch das Datum ist gleich.
Wenn es denn so ist das:


und dies wird so Übermittelt, dann liegt der Fehler augenscheinlich beim Programm VR-NetWorld.

Das Argument von Holger:


simmt aus meiner Sicht nicht, da das Datum richtig übermittelt wird.
Den Schuldigen haben wir jetzt. Wenn sich die Volksbank dem Problem stellt, dann bekommen wir demnachst einen neuen Patch und alle sind glücklich. Schön wäre es.

Danke an alle für die Mitarbeit. Ich will hier auch keinem auf die Füße treten. Bin nur an einer Lösung interessiert, da ja offensichtlich ein Programmfehler vorliegt. Vielleicht werden wir ja mit einer Lösung (Patch) belohnt. :thup: :winke:

Die Sparkassen machen da auch meiner Meinung nach einen Fehler.
Folgendes Beispiel:

:60F:D090419EUR100,00
:61:0904200420D10,00 ... //Umsatz
:62F:D090420EUR90,00 //Endsaldo vom 20.4.

:60F:D090420EUR90,00 //Anfangssaldo vom 21.4. aber mit Datum 20.4.
... Umsätze vom 21.4.

Der Endsaldo vom 20.4. wird auch gleich als Anfangssaldo für den folgenden Buchungstag gemeldet. Dummerweise nur auch mit dem Datum des letzten letzten Buchungstages. Somit sind Anfangs- und Endsaldo für den letzten Buchungstag identisch.

Hallo Captain,

da es mit der Version 4.1 Anpassungen zu diesem Thema geben wird und ich deine Aussage so nicht stehen lassen will, schreibe ich mal ein paar Dinge hierzu.

Deine Aussage :


ist so nicht ganz sauber.

Zum Anfangssaldo 60F steht in der Spec. (FinTS_3.0_Messages_Finanzdatenformate_2008-02-29_final_version.pdf) genau



Sicherlich kann man das auch so interpretieren:
Der Anfangssaldo wird technisch am Vortag gemeinsam mit dem Endsaldo des Vortags gebucht
-> macht ja auch Sinn, da die Beiden ja identisch sein müssen.

Das ist technisch richtig, aber jeder Buchhalter wird Dir sagen, dass das
für die Praxis absolut sinnfrei ist, wenn als Datum des Saldos der Tag der technischen Buchung genommen wird.

Wenn man das nämlich mal konsequent weiter denken würde, müsste das ja für den Kontoauszug ja auch gelten. Der würde nach dem Muster also so aussehen.


Rahmenbedingungen:

Fangen wir mit dem 01.01.2009 und einem Kontostand 0 EUR mal an und starten auch mal ohne Anfangssaldo

- Am ersten Tag (01.01.2009) kommen drei Zahlungen über 100, 200 und 300 EUR an
- Am zweiten Tag (02.01.2009) zwei Zahlungen a 50 EUR

Zieht man sich einen Kontoauszug würde jeder das hier erwarten

*****************************************************
Eingang 01.01.2009 100,00 EUR
Eingang 01.01.2009 200,00 EUR
Eingang 01.01.2009 300,00 EUR

Endsaldo per 01.01.2009..............600,00 EUR


Anfangssaldo per 02.01.2009........600,00 EUR

Eingang 02.01.2009 50,00 EUR
Eingang 02.01.2009 50,00 EUR

Endsaldo per 02.01.2009..............700,00 EUR

*****************************************************


Nach der Logik der Umsatzlieferung kommt aber


*****************************************************
Anfangssaldo per 01.01.2009........600,00 EUR wurde am 01.01. gemeinsam mit dem Endsaldo vom 01.01 gebucht

Eingang 01.01.2009 200,00 EUR

Eingang 01.01.2009 300,00 EUR

Endsaldo per 01.01.2009..............600,00 EUR

Anfangssaldo per 02.01.2009.......700,00 EUR wurde am 02.01.gemeinsam mit dem Endsaldo vom 02.01 gebucht

Eingang 02.01.2009 50,00 EUR
Eingang 02.01.2009 50,00 EUR

Endsaldo per 02.01.2009..............700,00 EUR
*****************************************************

Wie gesagt, technisch kann ich das gut nachvoll ziehen. Der Endsaldo des Tages wird einfach in den Anfangssaldo kopiert. Nur macht es eben überhaupt keinen Sinn, dabei das Datum des Endsaldos beizubehalten. So ist die Info Anfangssaldo schlicht wertlos!

Da es wohl recht unwahrscheinlich ist, dass in absehbarer Zeit seitens des
Rechenzentrums hier eine Anpassung erfolgen wird, kann man ab der Version 4.1 den Anfangssaldo für bestimmte Bankleitzahlen ignorieren lassen (mein Vorschlag für die sprechende Benennung des Schalters ist leider abgelehnt worden, war wohl nicht sachlich genug....).

Um die Aktivierung für den Anwender zu erleichtern, erkennt ein Assistent
das Problem und bietet den Anwender an, die Umgehung für die betroffene BLZ zu aktivieren.

Gruß

Holger