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

[Martin Preuss]

Moin,

On Donnerstag, 11. September 2008, Andreas Köhler wrote:
> On Wed, 2008-09-10 at 19:36 +0200, Martin Preuss wrote:
[...]
> setze mich doch einfach auf To:, dann sollte die Chance, dass ich die
> Mail lese noch etwas erhöht werden :-)  Bin halt etwas faul...
[...]

Ich aber auch, und da Du ja auf der Liste mitliest, hatte ich keine Lust, 
Deine Email-Adresse herauszusuchen ;-)

[...]
> 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.

[...]
> 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...

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.

[...]
> Bei meiner Bank und dem Test-Server des Herrn Palme hat das bisher immer
> super geklappt ;-)
[...]

Ja, die fuehren aber auch sofort aus ;-)

Der Unterschied liegt hier in den Rueckmeldungen des Servers (entweder 
HBCI-Code 10 oder 20, jenachdem ob der Auftrag nur angenommen oder direkt 
ausgefuehrt wurde).


Gruss
Martin Preuss



-- 
"Things are only impossible until they're not"

Martin Preuss - http://www2.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/