Moin list members,

arrghh, hole ich doch gerade die Umsätze mit KMyMoney ab und bekomme eine 
Fehlermeldung, dass eine Buchung nicht zugeordnet werden kann, weil die schon 
mal mit einer anderen Quasi-UID zugeordnet wurde. Das kommt immer dann vor, 
wenn eine Buchung von der Bank eingelesen wird und die dazugehörige von 
KBanking produzierte Quasi-UID nicht mit der in einem früheren Lauf 
eingelesenen Information zusammen passt.

Diese Quasi-UID wird in KBanking wie folgt gebaut, wenn 
AB_Transaction_GetFiId() keine Information enthält (und das ist bei HBCI 
genau so, weil die keine IDs kennen):

YYYY-MM-DD-HHHHHHH-L

Wobei YYYY-MM-DD das Buchungsdatum, HHHHHHH ein Hashwert (in dem der Zahler, 
der Verwendungszweck und der Betrag eingearbeitet sind) und L eine laufende 
Nummer ist, falls der Hashwert mal dopppelt vorkommt.

Jetzt ist es mir zweimal passiert, dass eine bereits akzeptierte Buchung ein 
paar Tage nach dem ersten Download von KMyMoney angemeckert wurde. D.h. es 
gibt nur eine Buchung die passen würde und die hat aber eine andere 
Quasi-UID. Somit wird die einfach importiert und eine zweite angelegt. Soweit 
ist das ja in Ordnung, falls mal eine andere Buchung da auftauchen sollte, 
das war aber in beiden Fällen nicht so.

Heute morgen habe ich also ernsthaft an dem Algorithmus für den Hashwert 
gezweifelt, schon nicht initialisierte Variablen gesucht u.d.g.m.  Nichts zu 
sehen.

Dann bin ich mal in die Tiefen der Logs gestiegen, und was muss ich 
feststellen:

1. Abruf
:61:0808190819D88,NMSCNONREF^M
:86:999TANK MAX                   ^M
EC 74024507 16.08 13.06 ME1  ^M

2. Abruf
:61:0808190819D88,NMSCNONREF^M
:86:999TANK MAX                   ^M
EC 74024507 16.08 13.06 ME1  ^M

3. Abruf
:61:0808190819D88,NMSCNONREF^M
:86:999TANK MAX                   ^M
EC 74024507 16.08 13.06 ME1 ^M

Sieht auf den ersten Blick alles gut aus, doch fehlt beim dritten Aufruf in 
der letzten Zeile genau ein Blank am Ende. Wer hat denn das geklaut? Hat's 
die Bank beim 3. Mal nicht übertragen? Ist es in AqBanking irgendwo 
verschüttet gegangen? Ich tippe ja mal eher auf die Bank. Jetzt ist mir klar, 
warum die Bildung des Hashwertes (Quasi-UID) einen anderen Wert ergibt. 

Werde wohl den Algorithmus dahingehend verändern, dass ich die Blanks einfach 
zusammenfasse und am Anfang und Ende lösche. Dann sollte das erstmal kein 
Problem mehr sein, bis die nächste Überraschung auftaucht.

So, genug heheult und gejammert.

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
'Software is like sex: it's better when it's free' (Linus Torvalds)
-------------------------------------------------------------

Attachment: signature.asc
Description: This is a digitally signed message part.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Aqbanking-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel

Reply via email to