[gnucash-de] Datumsproblem beim Abruf von Kontoumsaetzen in Verbindung mit terminierten Buchungen

[Manfred Usselmann]

On Thu, 20 Mar 2008 10:22:29 +0100
Manfred Usselmann <usselmann.m at icg-online.de> wrote:

> Christian Stimming <stimming at tuhh.de> schrieb am Wed, 19 Mar 2008
> 22:20:55 +0100:
> 
> > Am Dienstag, 18. März 2008 13:33 schrieb Manfred Usselmann:
> > > Das klang fuer mich so, dass das Wertstellungsdatum als
> > > Buchungsdatum genommen wird, wenn ich ueber HBCI Kontoumsaetze
> > > abrufe. Das finde ich auch absolut richtig.
> > >
> > > In meinem Fall funktioniert das aber nicht so wie gewuenscht.
> > > Dabei geht es mir im Moment gar nicht darum, welches der
> > > gelieferten Datumsfelder genommen wird, sondern dass die
> > > Datumsinformationen von der Bank komplett ignoriert werden.
> > >
> > > Ich habe naemlich die meisten der regelmaessig wiederkehrenden
> > > Buchungen als terminierte Buchungen angelegt. Hauptsaechlich um
> > > eine korrekte Zuordnung des Gegenkontos (in manchen Faellen auch
> > > mehrere Gegenkonten) zu erzielen. Das funktioniert auch soweit
> > > wie von mir gewuenscht. Allerdings wird dann das Datum der
> > > terminierten Buchung, welches fuer mich nur vorlaeufig ist,
> > > genommen statt dem tatsaechlichen Buchungsdatum der Bank. Das ist
> > > fuer mich falsch bzw. ich kann mir im Moment auch keinen Fall
> > > vorstellen, wo diese Verhalten sinnvoll waere.
> > 
> > Deine Frage geht nicht so sehr darum, *welches* vom HBCI-Server
> > empfangene Datum denn in gnucash verwendet wird. Stattdessen geht
> > deine Frage darum, ob gnucash bei einer empfangene Buchung, wenn sie
> > denn ein Duplikat einer existierenden Buchung ist und daher als
> > "abgleichen" markiert wird, also ob gnucash dann irgendwelche
> > Datenfelder aus der empfangenen Buchung in die bereits existierende
> > Buchung rüberkopieren soll.
> 
> Genau so ist es.
> 
> > Momentan geschieht das nicht.
> 
> Stimmt, ich habe das gerade nochmal getestet. Sogar der Wert wird
> nicht korrigiert!
> 
> > Wenn das geschehen soll, müsste man aber mal deutlicher formulieren,
> > welche Datenfelder genau denn in die existierende Buchung
> > rüberkopiert werden sollen. Denn ich kann mir Benutzerfälle für alle
> > möglichen Felder oder eben nicht Felder vorstellen. Ob es da eine
> > allgemeingültige Lösung gibt, die möglichst auch verständlich ist?
> 
> Ich gebe dir recht, dass sicher alle moeglichen Faelle denkbar sind.
> 
> Allerdings kann ich mir keine Faelle vorstellen, wo man Datum und
> Wert abweichend vom HBCI-Server speichern moechte. Das ist doch dafuer
> sicher die definitive Quelle, oder?
> 
> Der Wert sollte in den allermeisten Faellen gleich sein. Bei einer
> wiederkehrenden Zahlung, die als terminierte Buchung gespeichert ist,
> koennte eine Abweichung durch eine Preisaenderung vorkommen. Dann
> waere aber auch der neue Betrag richtig. Welche Abweichung laesst
> GnuCash hier eigentlich zu, um trotzdem noch eine automatisch
> gewaehlte Zuordnung zum machen? Mein Testfall war: Vorliegende
> Buchung 26,56 EUR, Buchung vom Server: 25,56 EUR, restliche Daten
> gleich. Die Zuordnung erfolgte automatisch, der Betrag blieb bei
> 26,56. Da haette ich nachher beim Kontoabgleich lange gesucht.
> Vielleicht sollte bei abweichenden Betrag gar kein automatisches
> Abgleichen erfolgen?
> 
> Beim Datum duerfte es sogar haeufiger vorkommen, dass das exakte
> Buchungsdatum abweichend ist. Aber hier ist sicher das Buchungsdatum
> vom Server richtig. Bei einer als terminierte Buchung gespeicherten
> wiederkehrenden Zahlung (Lastschrift) kann ich das genaue Datum gar
> nicht wissen. Auch wenn ich eine Ueberweisung per HBCI uebertrage,
> steht nicht unbedingt fest, mit welchem Datum die Bank die
> Ueberweisung nachher bucht. Hier hat fuer mich das Datum vom Server
> definitiv Vorrang und ich kann mir keinen anderen Fall vorstellen. Ich
> persoenlich wuerde mir hier definitiv eine Aenderung wuenschen.
> 
> Ein Streitpunkt ist die Beschreibung, da gibt es sicher fuer beide
> Moeglichkeiten (vom HBCI-Server uebernehmen oder belassen) gute
> Argumente. Fuer die Uebernahme vom Server spricht, dass da oft
> zuaetzliche Informationen enthalten sind, die sonst verloren gehen.
>  
> > In Ermangelung einer verständlichen Lösung blieb es bisher dabei,
> > dass gar nichts rüberkopiert wird. Man muss also die empfangene
> > Buchung als "neu" übernehmen und dann die manuelle Buchung per Hand
> > löschen. Oder so.
> 
> Das muesste ich aber die Gegenkonto-Zuordnung auch von Hand
> korrigieren und der Sinn der terminierten Buchung (Sicherstellung des
> richtigen Gegenkontos und des richtigen Splits etc., insbesondere
> z.B. bei Darlehensbuchungen, wo ich sogar Formeln verwende), waere in
> Frage gestellt.
> 
> OK, man koennte auch die vorlaeufige Buchung datumsmaessig anpassen
> und dann die neu empfangenen Buchung loeschen.
> 
> Allerdings muesste man erstmal im Buchungszuordnungdialog jede
> Zuordnung per Doppelklick aufrufen zum Ueberpruefen, ob relevante
> Abweichungen vorliegen. In der Zuordnungsuebersicht ist das nicht
> sichtbar, da steht nur "Abgleichen (Mit automatisch gewaehlter
> Zuordnung)".
> 
> Aber der Hinweis auf die Moeglichkeit, die Buchung als 'neu' zu
> uebernehmen und dann die Anpassungen manuell zu machen, ist gut und
> hilft schon mal weiter. 

Das Thema ist nach wie vor für mich relevant. Die Möglichkeit, die
Buchung als 'neu' zu übernehmen und dann die Anpassungen manuell zu
machen, klang zwar gut, hat sich jedoch nicht als besonders hilfreich
erwiesen, weil nicht erkennbar ist, welche abgleichbaren Buchungen
Abweichungen haben und daher überprüft werden müssen und besser als
'neu' importiert werden sollten.

Nachdem ich gerade mal wieder Kontoumsätze von drei Monaten
runtergeladen habe, habe ich wieder lange suchen müssen, um die zwei
Buchungen zu finden, wo sich der Betrag geringfügig gegenüber der
terminierten Buchung geändert hatte, was dann zu (berechtigten)
Differenzen beim Kontoabgleich führte. 

Auch ist es sehr störend, dass das Datum nicht angepasst wird.
Besonders beim Monatsende. Beispiel: Terminierte Buchung 30. des
Monats, die Abbuchung kommt aber ausnahmsweise erst am Monatsanfang.
Damit stimmt der Monatssaldo des Kontos nicht. Und durch diese
Datumsverschiebungen stimmte der laufende Kontosaldo nie mit dem
laufenden Saldo der Bank, so dass die fehlerhaften Buchungen auch nicht
zeitlich einzugrenzen waren.

Ich denke wirklich, dass Datum und Betrag kopiert werden sollte, wenn
die Buchung anhand der Kontoumsätze abgeglichen wird. Zumindest wäre es
sehr hilfreich, wenn das Vorliegen solcher Abweichungen im Dialog
erkenntlich wäre.

Bin ich der einzige, der solche Probleme hat? 

Vielleicht sollte ich einfach mal selber versuchen, eine Lösung zu
programmieren. Wie wäre es, wenn die Felder mit Abweichungen irgendwie,
z.B. farblich, markiert würden und man dann per Dropdown zwischen den
runtergeladen und den vorhanden Werten auswählen könnte. Da könnte man
dann auch verschiedene Datumsfelder anbieten:

01.06.2008 (Bank Wertstellung)
31.05.2008 (Buchung)
02.06.2008 (Bank Buchung) 

Gruß,
Manfred