[gnucash-de] Überweisungen mit HBCI

Mo Nov 15 22:45:00 EST 2010

Hallo Christian, hallo Martin,

On Mon, 15 Nov 2010 20:42:58 +0100
Christian Stimming <stimming at tuhh.de> wrote:

> Am Montag, 15. November 2010 schrieb Manfred Usselmann:
> > > * 23:19:15  CRIT <aqhbci> jobmultitransfer.c:  391: Text key "51"
> > > not supported by bank
> > > * 23:19:15  CRIT <aqhbci> jobmultitransfer.c:  488: Invalid
> > > transaction
> > > * 23:19:15  CRIT <aqhbci> provider.c:  712: Error exchanging
> > > params
> > > * 23:19:15  CRIT <aqbanking> banking_online.c:   88: Could not add
> > > job (-6)
> > > * 23:19:15  WARN <aqbanking> banking_online.c:  141: Not a single
> > > job successfully executed
> > > 
> > > Eine Idee, an welcher Stelle ich das abfangen kann, damit ich
> > > entsprechende Meldungen ausgeben kann?
> > 
> > Das war wohl etwas missverständlich ausgedrückt. Versendet wird
> > natürlich nichts und den Fehlerstatus erkenne ich auch schon, ich
> > weiss nur nicht, wie ich an die obigen Fehlermeldungen komme.
> > 
> > Was ich aus dem Jobs rauslesen kann, ist:
> > Job 1 status 6 - error: Refused by backend
> > Job 2 status 6 - error: Refused by backend
> > Job 3 status 6 - error: Refused by backend
> 
> Also was im Code noch fehlte, war vor dem AB_Banking_ExecuteJobs ein 
> AB_Job_CheckAvailability auf jeden einzelnen Job zu machen. Das hab
> ich eben ins SVN hinzugefügt, r19814. Wenn der Textkey 51 aus
> irgendeinem Grund bei dir noch nicht als verfügbar markiert ist, gibt
> das nun (leider) für jeden einzelnen Job gleich beim Reinladen eine
> entsprechende Fehlermeldung. Naja, besser als nichts.

Gut, danke. Der Funktionsaufruf ist sicher notwendig, hat aber bei mir
keinen Fehler angezeigt und für sich alle auch den Textkey-Fehler nicht
beseitigt. Erklärung kommt noch weiter unten.

> > Auch da ist die Frage, wie man das man besten dem Benutzer
> > präsentiert z.B. in einem gnc_error_dialog.
> 
> Ja, genau. Wenn du irgendwas implementiert bekommst, was für dich in
> der Benutzung sinnvoll ist, dann schick mir gerne die Patches rüber
> und ich stell die ins SVN :-)

Meine Implementierung ist als Diff angefügt. Wobei ich nicht weiss, wo
die zusätzlichen FileNewMenu- und FileOpenMenu-Änderungen herrühren, da
habe ich nichts bewusst gemacht. Ggbfls vor der Anwendung rausnehmen.
Der Rest ist hoffentlich so passend, aber wenn's was zu verbessern
gibt, bitte einfach Bescheid geben. 

> Jedenfalls ist hier natürlich die Schwierigkeit, dass man dem
> Benutzer die Rückmeldung von möglichst allen Jobs gleichzeitig
> serviert. Man muss also irgendwie nachgucken, ob es mindestens einen
> Fehler gibt, und in diesem Fall aus allen Fehlermeldung irgendeine
> brauchbare Meldung an den User zusammenbasteln, oder so ähnlich.

Ja, das habe ich gemacht. Jedenfalls hoffe ich, dass es brauchbar
ist. ;-) 

On Mon, 15 Nov 2010 21:18:26 +0100
Martin Preuss <aquamaniac at gmx.de> wrote:
>
> On Montag 15 November 2010, Christian Stimming wrote:
> [...]
> > Eventuell hängt's auch hier am bisher fehlenden
> > AB_Job_CheckAvailability(), die ich erst eben ins SVN eingefügt
> > habe. Ich erinnere mich dunkel, dass diese Funktion nicht nur eine
> > Prüfung machte, sondern auch noch irgendeine Vorbereitung
> > erledigte. Martin?
> [...]
> 
> Ja, daran liegt das ganz sicher. Diese Funktion macht den ersten
> Kontakt mit dem Backend, welches prueft, ob der Job unterstuetzt wird
> und dann die Limits setzt.

Reichte trotzdem nicht, es wurde immer SINGLE_DEBITNOTE bei
gnc_ab_get_trans_job übergeben. Damit war 51 immer noch unzulässig. In
Abhängigkeit vom AB_Transaction_Type setze ich jetzt auch
SINGLE_TRANSFER. 

Damit ist dann der Fehler 'Text key "51" not supported by bank'
verschwunden und es gibt dafür neue Fehler: :)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
* 01:40:30  WARN <aqhbci> msgengine.c:  388: SystemId requested (deprecated)
* 01:40:30  WARN <aqbanking> de.c:  116: Bank data for KtoBlzCheck not found (-51), falling back to default
* 01:40:30  CRIT <aqhbci> msgcrypt_pintan.c:  252: Error getting pin from medium (-67)
* 01:40:30  CRIT <aqhbci> jobqueue.c:  442: Could not encode message (-67)
* 01:40:30  CRIT <aqhbci> outbox.c: 1410: Error performing queue (-1)
* 01:40:30  CRIT <aqhbci> provider.c:  859: Error exchanging results
* 01:40:30  CRIT <aqhbci> provider.c:  859: Error exchanging results
* 01:40:30  CRIT <aqhbci> provider.c:  859: Error exchanging results
* 01:40:30  WARN <aqbanking> banking_online.c:  141: Not a single job successfully executed
* 01:40:30  WARN <gnc.import.aqbanking> Failed jobs:
Job 1 status 6 - error: Could not exchange results 
Job 2 status 6 - error: Could not exchange results 
Job 3 status 6 - error: Could not exchange results 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Google sagt:

"-67" ist "NOT_IMPLEMENTED", soll heissen: In GnuCash wurde ein
callback nicht gesetzt...

Ich kann aber nicht erkennen, was fehlt, da gnc_GWEN_Gui_get()
aufgerufen wird, womit die Callbacks gesetzt werden. Mmh, wenn ich den
Aufruf weiter nach unten setze, geht es weiter! Ich habe keine
Erklärung dafür gefunden, aber es funktioniert, die Fenster gehen auf
und ich kann ich PIN und TAN eingeben. Leider gibt es dann nach der
TAN-Eingabe doch wieder meinen Fehlerdialog, weil die Jobs auf Status
error sitzen. 

gnucash.trace:

* 03:02:14  WARN <aqhbci> msgengine.c:  388: SystemId requested (deprecated)
* 03:02:14  WARN <aqbanking> de.c:  116: Bank data for KtoBlzCheck not found (-51), falling back to default
* 03:02:23  CRIT <aqhbci> message.c:   68: Signers must be added before nodes !
* 03:02:41  CRIT <aqhbci> itan2.inc:  337: Adding result 9010 to job JobMultiTransfer
* 03:02:41  CRIT <aqhbci> itan2.inc:  337: Adding result 9010 to job JobTan
* 03:02:41  CRIT <aqhbci> itan2.inc:  337: Adding result 9390 to job JobMultiTransfer
* 03:02:41  CRIT <aqhbci> itan2.inc:  337: Adding result 9390 to job JobTan
* 03:02:41  WARN <gnc.import.aqbanking> Failed jobs:
Job 1 status 6 - error: (null) 
Job 2 status 6 - error: (null) 
Job 3 status 6 - error: (null) 

Was bedeutet das denn nun schon wieder?! :-(

Im Verzeichnis .aqbanking/backends/aqhbci/data/banks/de/'BLZ' habe ich
nach einiger Suche ein Log gefunden mit 'Der Auftrag wurde nicht
entgegengenommen. +9390::Auftrag wegen Doppeleinreichung abgelehnt.'
Vermutlich, weil ich die Daten schon mal gestern abend mit
QBankManager hochgeladen hatte.

Beim QBankmanager gab es immer so ein Log-Fenster, das man sich noch
nachträglich ansehen konnte. Hier gibt es das auch, aber es wird nach
der TAN-Eingabe gleich geschlossen.

Oh, sehe gerade, da ist ja ein Haken gesetzt bei "Fenster nach
Verbindungsende schliessen". Nur kann ich den nicht wegnehmen, weil
entweder PIN- oder TAN-Eingabe das aktive Fenster ist. Aber mit
gconf-editor geht es. Meiner Meinung nach sollte das standardmässig
ausgeschaltet sein, so dass das Protokoll gelesen werden kann. Zumal
man an den Haken nicht mehr dran zu kommen scheint zumindest im
PIN/TAN-Modus.

Nach der Änderung der Gnome-Konfiguration kann ich jetzt auch das
Protokoll lesen:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Sending jobs to the bank(s)
Locking users
Locking user xxxxxxxxxx
Executing HBCI jobs
AqHBCI gestartet
Mit Bank verbinden...
Ermittle Adresse von "hbci-pintan-rl.s-hbci.de" ...
Ermittelte IP Adresse ist 193.110.133.34
Selecting iTAN mode "iTAN"
Öffne Dialog mit dem Server
Aufträge werden kodiert
Aufträge werden gesendet
Mit Bank verbinden...
Verbunden.
Warte auf Antwort
HTTP-Status: 200 (OK)
Verbindung von Bank trennen...
Getrennt.
Antwort erhalten
HBCI: 3060 - Teilweise liegen Warnungen oder Hinweise vor (HBMSG=10336) (M)
HBCI: 0020 - Der Auftrag wurde ausgeführt. (S)
HBCI: 3920 - Zugelassene Zwei-Schritt-Verfahren für den Benutzer. (S)
Dialog not aborted, assuming PIN is ok
Empfangenes Konto: xxxxxxxx / Normalsparen
Empfangenes Konto: xxxxxxxx / Normalsparen
Empfangenes Konto: xxxxxxxx / Sichteinlagen
Empfangenes Konto: xxxxxxxx / Sichteinlagen
Aufträge werden kodiert
Aufträge werden gesendet
Mit Bank verbinden...
Verbunden.
Warte auf Antwort
HTTP-Status: 200 (OK)
Verbindung von Bank trennen...
Getrennt.
Antwort erhalten
HBCI: 0010 - Nachricht ist vollständig bearbeitet (HBMSG=10322) (M)
HBCI: 0030 - Auftrag empfangen - TAN Eingabe erforderlich.(MBT61620200002) (S)
Aufträge werden kodiert
Aufträge werden gesendet
Mit Bank verbinden...
Verbunden.
Warte auf Antwort
HTTP-Status: 200 (OK)
Verbindung von Bank trennen...
Getrennt.
Antwort erhalten
HBCI: 9050 - Nachricht teilweise fehlerhaft (HBMSG=10349) (M)
HBCI: 9010 - Der Auftrag wurde nicht entgegengenommen. (S)
HBCI: 9390 - Auftrag wegen Doppeleinreichung abgelehnt. (S)
TAN "xxxxxx" has been used, please strike it out.
Beende Dialog mit dem Server
Aufträge werden kodiert
Aufträge werden gesendet
Mit Bank verbinden...
Verbunden.
Warte auf Antwort
HTTP-Status: 200 (OK)
Verbindung von Bank trennen...
Getrennt.
Antwort erhalten
HBCI: 0100 - Dialog beendet (HBMSG=10346) (M)
Dialog not aborted, assuming PIN is ok
AqHBCI abgeschlossen.
Postprocessing jobs
Resetting provider queues
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Leider nicht so schön farbig markiert wie im QBankManger (kann man das
irgendwie machen?), aber immerhin, die Meldung 'Der Auftrag wurde nicht
entgegengenommen' ist da, wenn man etwas zurückblättert.

Ich gehe davon aus, dass es nun geht, morgen teste ich dann noch mal
mit einer neuen DTAUS-Datei dann hoffentlich den erfolgreichen
fehlerfreien Fall. :-)

Gruß,
Manfred

-- 
Manfred Usselmann <usselmann.m at icg-online.de>

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : MU0001-work-on-enabling-dtaus-import-and-send-again.patch
Dateityp    : text/x-diff
Dateigröße  : 10565 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20101116/e33db7af/attachment-0001.bin>