[gnucash-de] Problem mit gnucash 2.2.6 und aqbanking/HBCI/iTAN/Überweisungen

[Andreas Köhler]

Hi Martin,

On Thu, 2008-09-11 at 07:31 +0200, Martin Preuss wrote:
> On Donnerstag, 11. September 2008, Andreas Köhler wrote:
> > On Wed, 2008-09-10 at 19:36 +0200, Martin Preuss wrote:
> [...]
> > Kann man denn sagen, dass Pending prinzipiell ok und vom Benutzer
> > erwartet wird? Falls nicht, kommt das üblicherweise, wenn successful
> [...]
> 
> Oh, aber ja! Meine Banken beispielsweise sagen *immer* nur, dass sie den 
> Auftrag angenommen haben. Wenn das Konto gedeckt ist, wird die Bank den 
> Auftrag ja auch ausfuehren, aber darueber bekommt man bei vielen Banken halt 
> keine direkte Rueckmeldung (man sieht es nur an den Auszuegen).
> 
> Daher: Der Status "Pending" ist voellig ok und auch erwartet. Das bedeutet 
> zumindest, dass die Uebermittlung an die Bank geklappt hat und der Auftrag 
> inhaltlich in Ordnung ist. Ob die Bank das dann ausfuehrt, kann man jedoch 
> nicht erkennen, bevor es nicht in den Umsaetzen erscheint.
> 
> Erklaerung: Es gibt in HBCI einen Geschaeftsvorfall, mit dem man den Status 
> eines Auftrages nachtraeglich noch abrufen kann. Bloederweise implementieren 
> es aber offensichtlich die meisten Banken so, dass man immer den gleichen 
> Status bekommt, den man auch schon beim *Einreichen* bekam, selbst, wenn die 
> Bank den Auftrag inzwischen schon lange ausgefuehrt hat. D.h. die Banken 
> aendern den Status nicht mehr.
> 
> Frueher hat AqHBCI dieses Report-Feature verwendet, aber da die meisten Banken 
> das nicht in einer Form anbieten, in der man es auch *gebrauchen* kann, habe 
> ich das wieder herausgenommen.

Super, danke!

> [...]
> > TRUE oder FALSE ist? Man müsste in dem Fall dem Benutzer wahrscheinlich
> > nur Bescheid geben, ein Wiederholen allerdings nicht anbieten, oder?
> [...]
> 
> Wenn die Bank den Auftrag schon bei der Einlieferung ablehnt, sollte man sich 
> die Fehlermeldungen der Bank anschauen. Darin finden sich meist Hinweise auf 
> den Grund der Ablehnung. Die meisten inhaltlichen Gruende sollte die 
> Anwendung schon abfangen (z.B. falsche Zielkonto-Angabe, unerlaubte 
> Sonderzeichen im Verwendungszweck etc); andere Gruende - wie ungedecktes 
> Konto etc - kann wiederum nur der Benutzer behandeln.
> 
> Daher wuerde ich nicht unbedingt fragen, ob der Benutzer den Vorgang 
> wiederholen will, wenn es sich um Ueberweisungen handelt. Andererseits 
> speichert GnuCash im Fehlerfall wohl auch nicht die Auftraege, daher muesste 
> der Benutzer den Auftrag beim naechsten Mal komplett neu eingeben, oder?
> In diesem Fall ist es vermutlich einfacher, den Benutzer zu fragen. 
> Andererseits ist es gerade diese Nachfrage, die im Moment die Benutzer 
> verunsichern...

GnuCash merkt sich zumindest alle Werte, die der Nutzer für die
Ãœberweisung eingegeben hat. Die GnuCash-Transaktion muss er glaube ich
erneut eingeben, das sollte im Normalfall aber nicht viel mehr als die
Auswahl des entsprechenden Gegenkontos sein.

Sicherlich habe ich da Pending falsch ausgewertet. Intuitiv warne ich
den User lieber einmal zu oft als zu selten. Auf der anderen Seite
können doppelt ausgeführte Überweisungen bei unlieben Partnern auch
problematisch werden, oder? Oder gibt es da eine Möglichkeit, Duplikate
rückbuchen zu lassen? (Ich tippe mal auf nein).

Für entstandene Probleme möchte ich mich entschuldigen.

> Bei der Auswertung wuerde ich uebrigends vollstaendig auf den Job-Status 
> schauen; Das Resultat von ExecJobs() wird selbst dann "OK" sein, wenn einer 
> oder alle Jobs Fehler enthalten. Der Rueckgabe-Code hier sagt naemlich nur 
> etwas darueber aus, ob die Auftraege an die Backends weitergeleitet wurden 
> und diese die Auftraege bearbeitet haben. Mehr nicht. Insbesondere bezieht er 
> sich nicht auf den Status der Auftraege.
> 
> Wenn also der Status eines Jobs "OK" ist, dann ist der Rueckgabe-Code von 
> ExecJobs() an sich egal, Du kannst ihn also getrost ignorieren.

Ich habe das jetzt in http://svn.gnucash.org/trac/changeset/17502
gepatcht. Falls ich da immer noch völlig auf dem Schlauch stehen sollte,
gib mir bitte jetzt den Wink :-)

Danke nochmals.

Ciao,
-- Andreas

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: This is a digitally signed message part
URL         : http://lists.gnucash.org/pipermail/gnucash-de/attachments/20080911/82fcbe90/attachment.bin