Nun bin ich schon das 2. Mal auf folgendes Phänomen gestoßen: Banking4 rechnet "falsch" ?

Im Zusammenhang mit dem ganzen PDS2-Zirkus habe ich eines meiner Konten, das weniger frequent genutzt wird, (wieder mal) erst nach mehr als 90 Tagen abgerufen. Zunächst mal werden standardmäßig (obwohl die Institute z.T. auch längere Zeiträume bereithalten - könnte aber auch nicht an Banking4, sondern dem Bankserver liegen) nur die letzten 90 Tage abgerufen. Einen Hinweis, dass der letzte Umsatz zu weit zurück liegt, habe ich nicht bekommen und Banking4 weist mir auch den aktuellen Endsaldo aus. Was ich aber erst beim zweiten Hinschauen bemerkt habe, ist der Umstand, dass sich Banking4 nicht um die fehlenden Umsätze schert, sondern einfach den Saldo mit den vorhandenen Einträgen zurückrechnet, diese "Mogelei" aber nicht offenlegt. Fortan stimmen im Konto die Zwischensalden von dem ersten fehlenden Eintrag zurück alle nicht mehr.

Benutzt man wie ich, die Exportfunktion von Banking4 auch für ein anderes (Buchhaltungs- o.ä. Programm), das "richtig" rechnet, stimmen dann die Salden bis zum Endsaldo nicht mehr und man fängt an zu suchen, bis man die verantwortlichen (fehlenden) Buchungen gefunden hat.

Deshalb nun meine Frage an die Gemeinde: Gibt es eine Einstellung, dieses Verhalten zu unterbinden oder sonst einen tauglichen work-around (und bin ich der "Einzigste", der seine Abfrage schon mal über 90 Tage verbummelt) ?

grundsätzlich sollte man regelmäßig Umsätze abrufen, auch um evtl. fehlerhafte Buchungen zu reklam.
des weiteren was soll das Programm machen, wenn die Umsätze nur 90 Tage vorgehalten aber nicht abgerufen werden? (manche sogar kürze, manche viel länger)
ein Mitbewerber nimmt hier dann automatische Gegenbuchungen vor, was die User auch stört

wie soll das Programm/Software dann das "fehlerhafte Verhalten des Users" darstellen?
hier wäre es angebracht, evtl. die Bank zu wechseln, dass diese dem Kundenwunsch/-Abruf näher kommt.

Naja.....meiner Meinungn ach ist das zu einfach gesprungen.

Egal welchen Weg man geht und was der Anwender alles nicht mag, so sollte man versuchen fehlende Buchungen zu identifizieren und bei der Ermittlung der Zwischensalden auch entsprechend reagieren. Dabei ist völlig klar, das es Banken gibt, bei denen man eigentlich kaum eine Chance hat auf Basis der gelieferten Daten eine fehlende Buchung zu erkennen. In solchen Fällen ist das dann tatsächlich nicht änderbar, aber stumpf nur zurück rechnen und damit falsche Salden abbilden geht eigentlich nicht - und würde mich beim Andreas auch wundern.

und wo ist jetzt deine Lösung?

nochmals die User rennen dem Mitbewerber die Bude ein, weil diese das dann auch nicht möchten

Es ist aber leider (?) wirklich so. Das Programm holt seit dem letzten Abruf Buchungen und nimmt dann den heutigen Saldo und rechnet anhand der Buchungen zurück bis zum ersten Umsatz. Dass dann die Salden nicht stimmen, wen zwischendrin Buchungen fehlen, ist klar. Nur - wie sollte man das ungehen? Div. Banken liefern bei Abruf > 90 Tage einfach was da ist. Auch wenn das kürzer ist. Ohne Fehlermeldung. Auch gab es zumindest zu MT940-Zeiten Banken, die keinen Startsaldo in der Datei geliefert haben. Wie soll das Programm also reagieren? Einzige Möglichkeit wäre wohl, dass man sich merkt, bis wohin die Umsätze und der Saldo schon da waren, dann zurückrechnen bis zum ersten neuen Umsatz und dann schauen, ob das, was man als Startsaldo rauskriegt mit dem letzten alten Endsaldo übereinstimmt. Wenn nicht, dann wäre eine "Ausgleichsbuchung Saldo" fällig. Die haben mich aber bei div. anderen Programmen früher immer genervt, weil die oft auch dann kamen, wenn es garnicht nötig war. Schwierig, das Ganze...

Ja, aber eine "Ausgleichsbuchung Saldo" kann ich manuell nicht mal einpflegen, habe jedenfalls nichts gefunden, wie das gehen soll. Also war für mich der steinige Weg, eine Importdatei anzulegen und die fehlenden Umsätze damit "nachzubuchen". Mir persönlich sind automatische Ausgleichsbuchungen auch nicht genehm, wie ich sie von den englischen Money-Versionen kenne, sondern ich bevorzuge, wenn das Programm (wie etwa das deutsche !Money99") den Saldo selbst errechnet und ich daran sehe, ob alle Buchungen erfasst sind. Ab und an passiert es nämlich auch, dass eine Buchung doppelt erfasst wird und da sind Saldoabweichungen der einzig vernünftige Weg Differenzen zur Rechnung der Bank feststellen.

Für mich wäre schon ein Optimum erreicht, wenn neben der Möglichkeit, manuell Korrekturen zu buchen, auch das Programm in irgendeiner Weise auf Saldodifferenzen zum abgerufenen Wert hinweist, und wenn das nur etwa mit einem (!) oder einer farblichen Markierung kenntlich gemacht würde. Einfach drauflos zu rechnen halte ich jedenfalls für suboptimal.

Du kannst Dich behelfen, indem Du in den Kontoeinstellungen des Kontos im Bereich Bankzugang, Online-Banking, den Bankzugang herausnimmst. Damit wird das Konto zum "Offline-Konto". Dann kannst Du "von Hand" eine Ausgleichsbuchung einpflegen. Hinterher trägst Du den Bankzugang wieder ein, damit in Zukunft wieder normal abgerufen wird.

Gruß
Lisa

Das nenne ich mal einen konstruktiven Lösungsvorschlag!

hier handelt es sich doch aber nicht um eine Buchhaltung, wo man einfach eine Korrektur/manueller Umsatz einbuchen kann.

auch wenn dein Wunsch teilweise nachvollziehbar ist
es gibt viele unterschiedliche Problemfälle, siehe auch mein og. verlinkter FAQ-Beitrag

Naja, aber wenn das, was da gelesen wurde falsch ist (und fehlende Buchungen sind nun mal falsch), dann ist das keine Nachbuchung sondern eine Fehlerkorrektur - und diese durchzuführen finde ich absolut in Ordnung!Ich bin auch nicht dafür, dass man in Buchungen im Text etc. rumändert, aber päpstlicher als der Papst muß man auch nicht sein.

Ich wollte auch gerade den Weg mit der temporären Umstellung auf "offline" vorschlagen, aber da ist mir lisari zuvor gekommen

@msa
aber du bist doch normalerweise dafür, dass weder am Kontoumsatz (also einzelne Postion) was geändert wird, noch sonst irgendwie
des weiteren sind ja "nur" die Zwischensummen/-salden falsch

dass es worarounds usw. gibt die Daten doch hineinzuschreiben, wurde ja eine Möglichkeit vom User selbst mitgeteilt

zurück aber zum Problem:
ist es Sinnvoll, dass eine Software eine "Buchung" vornimmt, die nicht vom RZ abgeholt wurde?
bzw. was macht man, wenn die Geldautomat-Abbuchung schon im Saldo steckt, aber noch nicht in den Umsätzen?

Nur??? Es sind dann sämtliche Tagessalden rückwärts incl. Startsaldo falsch. Damit kann man die Daten dann gleich in die Tonne treten. Da ist es nahezu ein Muss, das zu korrigieren.

Wenn die Alternative lautet "alle Tagessalden von der Fehlstelle an rückwärts sind falsch", dann ein klares ja.

Dann macht man was falsch. Es mag sein, dass diese Buchung bereits im angezeigten "verfügbaren Saldo" steckt, sie kann aber nicht im Schlußsaldo der abgerufenen Kontoumsätze stecken. Wenn das tatsächlich der Fall wäre: Bank wechseln

Auch von mir Dank für den Tip von Lisari. Damit lässt sich zumindest praktikabel eine Saldokorrekturbuchung einpflegen.

Wenn mehrere Buchungen fehlen, ist wohl der Import schneller, als alle Buchungen von Hand einzugeben (Systemisch sehe ich da keine Hinderungsgründe, denn ein Bankingprogramm unterliegt nicht GOB, und auch dort sind Stornos und Berichtigungen statthaft). Die benötigten Buchungen bekommt man idR wohl noch vom Institut als CSV-Datei und kann sie nach Bearbeitung etwa in Excel dann (z.B. mit XL2QIF) nach Banking4 exportieren. Das Programm hat zwar bei mir ein bißchen gezickt, aber die Daten dann nach einigen Versuchen doch angenommen.

Was mir in diesem Zusammenhang wieder aufgefallen ist, ist der Umstand, dass zwar viele Im-/Exportformate angeboten werden, aber wohl keine Möglichkeit , bei der Selektion der gewünschten Felder selbst Hand anzulegen. Nachdem Subsembly das SUPA-Format ja ausdrücklich als open source anbietet, sollten die anderen Formatdateien eigentlich aiuch keine Betriebsgeheimisse beinhalten? Aber ich habe bisher nicht mal herausgefunden, wie man an die SUPA-Datei rankommt - aber das ist nun wohl OT.

Da würde ich auf jeden Fall SUPA als Format empfehlen, das ist gut dokumentiert und enthält alle Felder, die es in der Datenbank gibt. Man muss aber solche, die man nicht braucht, nicht angeben.

Die Beschreibung der SUPA-Dateien sind auf der Website von Subsembly downloadbar. Siehe https://subsembly.com/supa.html Damit ist dann sehr leicht eine Importdatei zu erstellen.

@rotlomax

Hast (oder hattest) du vor der Nutzung Banking 4 Version 7, eventuell parallel noch die 6er Version Banking 4W in Betrieb?
Wenn ja, wurden dann auch Umsätze bis zur Umstellung auf PSD2 abgerufen?
Dann wäre es eine große Hilfe, aus dem 6-er Programm (z.B. V 6.10.5.6843) über Export diese Daten auf die neue Version zu importieren.
Wenn nicht, dann hilft tatsächlich nur (offline) die Daten ein zu pflegen.

@msa

die Seite mit der "Supa" Beschreibung war mir bekannt, nur hilft das beim Export wenig, wenn ich selbst bestimmen will, welche Felder ich exportieren möchte. Natürlich kann ich die nicht benötigten dann in Excel löschen und danach weiter verarbeiten. Eine Weile hatte ich damit geliebäugelt, OFX-Dateien zu produzieren, um sie dann als Kontoauszüge in Money zu verarbeiten. Die hauseigene Möglichkeit mit HBCIFM99 ist aber besser und so habe ich das wieder beiseite gelegt.

@ DBuessen

nein, ich arbeite nicht mehr mit der V.6, denn damit funktionieren die Bankzugänge doch nicht mehr, zumindest was PIN/TAN angeht.

Ja, das hab ich ja auch nicht behauptet. Selbstebstimmte Feldauswahl ist bei B4 (zumindestens aktuell) nicht.
Und Du hattest ja von Excel geschrieben, mit dem Du eine Datei für den Import nach B4 erzeugen willst. Und bei einer selbst erzeugten Datei ist in meinen Augen SUPA das am besten geeignete Format. Zumal bei den QIF-Dateien oft Probleme vorkommen. Von wegen Datums- und Zahlenformat usw. Und vor Allem werden in dem Format die meisten bankfachlichen Felder nicht unterstützt.
Aber wenn Du inzwischen eine bessere Lösung gefunden hast, um so besser.

Hallo,
meine Frage zielte darauf ab, ob du bis zur Umstellung auf PSD2 evtl. noch mit V 6 zugange warst?
Es ist bekannt, dass ab PSD2-Umstellung die Version 6 nicht mehr bei allen Konten funktionierte. Bis dahin war die Version 6 jedoch voll funktionsfähig und auch im Parallelbetrieb mit der Version 7 einsetzbar.

Das wäre zumindest der einfachere Weg gewesen, um rückwärtige Daten noch zu retten, um sie dann in V7 zu übertragen.