hbci4java-help — all questions concerning hbci4java

Re: [Hbci4java-help] Abweichung im Saldo der Buchung, erste Spur

[Stefan P. <kle...@gm...>]

Hallo Marc,

dank Deiner ausf=FChrlichen Log-Daten (und meinem HBCI-Server ;-) )
konnte ich das Problem bei mir exakt nachvollziehen. Ich werde heute
nachmittag neue Snapshots von HBCI4Java und wallstreet9 auf
die Homepage stellen, in denen das Problem gefixt sein sollte.

Die Fehlerursache war die Verwendung von float-Datentypen. Diese haben
zwar einen gro=DFen Wertebereich, aber nur eine geringe Genauigkeit
- wenn ich richtig gerechnet habe, sind nur 6 signifikante Dezimal-
stellen garantiert. Da Deine Werte schon dar=FCber hinaus gingen,
kam es halt zu den Problemen... Jetzt wird daf=FCr mit double-Werten
gearbeitet. Au=DFerdem werden s=E4mtliche Rechenoperationen (also
das Saldieren) in Cent (bzw. der jeweils analogen W=E4hrung - aber
auf jeden Fall in Integer-Arithmetik) durchgef=FChrt, so dass sowas
eigentlich nicht wieder auftreten sollte.

Dein anderes Problem mit den fehlerhaften Kontoausz=FCgen der anderen
Bank werde ich mir auch noch vornehmen, mir ist nur noch kein
guter Einfall gekommen, wie ich einen nicht allzusehr gehackten
Workaround da hineinbekomme...

Danke nochmal f=FCr die Unterst=FCtzung

Viele Gr=FC=DFe
-Stefan-

>=20

> So, jetzt,
>=20
> der Block enth=E4lt mehrere (alle) Tage und alle Buchungen.=20
> pro Tag steht dort folgenden Struktur
>=20
> :20:STARTUMS  (ich vermute Beginn Kontoauszug)
> :60F:C030820EURxxx,xx (vermute Tagesstartsaldo)
>    hier die Buchungen des Tages
> :62F:C030820EURxxx,xx (vermute Tagesendsaldo)
> :20:STARTUMS (Beginn des N=E4chsten Tages)
>=20
> Alle Zeilen sind mit \r\n abgeschlossen.=20
> Das \r\n-\r\n gibt es nur genau einmal, n=E4mlich am Ende.
>=20
> Gru=DF
>=20
> Stefan Palme meinte am 09.12.2003 15:32:
> > Hallo,
> >=20
> >  =20
> > > und lerne, dass Zeile 131 nur einmal durchlaufen wird, das hei=DFt =
alle=20
> > > Tage als ein Tag behandelt werden.
> > >    =20
> > hmm, das d=FCrfte wahrlich nicht passieren. Kannst Du mal bitte
> > folgendes ausprobieren: In Zeile 71 (ca.) steht
> > "String st_tag=3DSwift.getOneBlock(booked);". Damit werden
> > aus dem kompletten empfangenen Kontoauszug genau die Daten eines
> > Buchungstages extrahiert. Kannst Du diesen String mal ausgeben und
> > nachsehen, ob da auch *tats=E4chlich* nur ein Tag drinsteht?
> >=20
> > Wenn nicht, kannst Du mal nachsehen, ob zwischen den einzelnen
> > Buchungstagen die Trennsequenz "\r\n-\r\n" [5 Zeichen] steht?
> > Wenn nicht, ist das schon mal ein Problem... (wenn anstatt "\r\n"
> > bei Dir "@@" stehen sollte, ist das okay, das wird von einem
> > Rewriter-Modul (1822direkt) korrigiert).
> >=20
> > Gr=FC=DFe
> > -Stefan-
> >=20
> >  =20
> ------------------------------------------------------- This SF.net
> email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX
> or just sharpen your skills. Sign up for IBM's Free Linux Tutorials.
> Learn everything from the bash shell to sys admin. Click now!
> http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________ Hbci4java-help mailing
> list Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

Re: [Hbci4java-help] Abweichung im Saldo der Buchung, erste Spur

[Stefan P. <kle...@gm...>]

Hallo,

so, die Sache mit dem fehlenden "\r\n-\r\n" ist nicht sch=F6n.
Aber das einzige Problem, was dadurch entsteht, ist, dass in dem
GVRKUms.BTag[]-Array wahrscheinlich nur genau *ein* Element
drinsteht, welches die Umsatzzeilen *aller* Buchungstage
enth=E4lt, anstatt das sch=F6n nach Buchungstagen getrennt zu
tun. Ist aber eigentlich nicht weiter tragisch, wenn man dieses
Feature nicht gerade braucht. Vor allem kann es eigentlich nicht
die Ursache des Rundungsfehlers sein.

Wenn ich Dich richtig verstanden hatte, geht es weder mit
wallstreet9 noch mit der modifizierten Version von=20
AnalyzeReportOfTransactions. Dann liegt es wohl auch nicht an
der falschen Auswertung der Daten durch diese Client-Apps.

Ich werde also noch mal durch den Code in GVKUms.extractResult()
klettern, aber auf den ersten Blick sind da Rundungsfehler extrem
unwahrscheinlich. Kannst Du mir vielleicht ein paar Salden/Umsatz-
werte schicken, an denen man das Verhalten evtl. nachvollziehen
kann? (Ich w=FCrde dann mit HBCI4Java-Server einfach diese Daten
in einem Kontoauszug zur=FCckgeben und sehen, ob ich das Ph=E4nomen
nachvollziehen kann)...

Gr=FC=DFe
-Stefan-

> So, jetzt,
>=20
> der Block enth=E4lt mehrere (alle) Tage und alle Buchungen.=20
> pro Tag steht dort folgenden Struktur
>=20
> :20:STARTUMS  (ich vermute Beginn Kontoauszug)
> :60F:C030820EURxxx,xx (vermute Tagesstartsaldo)
>    hier die Buchungen des Tages
> :62F:C030820EURxxx,xx (vermute Tagesendsaldo)
> :20:STARTUMS (Beginn des N=E4chsten Tages)
>=20
> Alle Zeilen sind mit \r\n abgeschlossen.=20
> Das \r\n-\r\n gibt es nur genau einmal, n=E4mlich am Ende.
>=20
> Gru=DF
>=20
> Stefan Palme meinte am 09.12.2003 15:32:
> > Hallo,
> >=20
> >  =20
> > > und lerne, dass Zeile 131 nur einmal durchlaufen wird, das hei=DFt =
alle=20
> > > Tage als ein Tag behandelt werden.
> > >    =20
> > hmm, das d=FCrfte wahrlich nicht passieren. Kannst Du mal bitte
> > folgendes ausprobieren: In Zeile 71 (ca.) steht
> > "String st_tag=3DSwift.getOneBlock(booked);". Damit werden
> > aus dem kompletten empfangenen Kontoauszug genau die Daten eines
> > Buchungstages extrahiert. Kannst Du diesen String mal ausgeben und
> > nachsehen, ob da auch *tats=E4chlich* nur ein Tag drinsteht?
> >=20
> > Wenn nicht, kannst Du mal nachsehen, ob zwischen den einzelnen
> > Buchungstagen die Trennsequenz "\r\n-\r\n" [5 Zeichen] steht?
> > Wenn nicht, ist das schon mal ein Problem... (wenn anstatt "\r\n"
> > bei Dir "@@" stehen sollte, ist das okay, das wird von einem
> > Rewriter-Modul (1822direkt) korrigiert).
> >=20
> > Gr=FC=DFe
> > -Stefan-
> >=20
> >  =20
> ------------------------------------------------------- This SF.net
> email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX
> or just sharpen your skills. Sign up for IBM's Free Linux Tutorials.
> Learn everything from the bash shell to sys admin. Click now!
> http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________ Hbci4java-help mailing
> list Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

Re: [Hbci4java-help] Abweichung im Saldo der Buchung, erste Spur

[Marc B. <ba...@ma...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
So, jetzt,<br>
<br>
der Block enth&auml;lt mehrere (alle) Tage und alle Buchungen. <br>
pro Tag steht dort folgenden Struktur<br>
<br>
<tt>:20:STARTUMS</tt>&nbsp; (ich vermute Beginn Kontoauszug)<br>
<tt>:60F:</tt><tt>C030820EURxxx,xx</tt><tt> </tt>(vermute
Tagesstartsaldo)<br>
&nbsp;&nbsp; hier die Buchungen des Tages<br>
<tt>:62F:C030820EURxxx,xx</tt><tt> </tt>(vermute Tagesendsaldo)<br>
<tt>:20:STARTUMS</tt> (Beginn des N&auml;chsten Tages)<br>
<tt><br>
</tt>Alle Zeilen sind mit <tt>\r\n</tt> abgeschlossen. <br>
Das <tt>\r\n-\r\n</tt> gibt es nur genau einmal, n&auml;mlich am Ende.<br>
<br>
Gru&szlig;<br>
<tt><br>
</tt>Stefan Palme meinte  am 09.12.2003 15:32:<br>
<blockquote type="cite"
 cite="mid...@tu...">
  <pre wrap="">Hallo,

  </pre>
  <blockquote type="cite">
    <pre wrap="">und lerne, dass Zeile 131 nur einmal durchlaufen wird, das hei&szlig;t alle 
Tage als ein Tag behandelt werden.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
hmm, das d&uuml;rfte wahrlich nicht passieren. Kannst Du mal bitte
folgendes ausprobieren: In Zeile 71 (ca.) steht
"String st_tag=Swift.getOneBlock(booked);". Damit werden
aus dem kompletten empfangenen Kontoauszug genau die Daten eines
Buchungstages extrahiert. Kannst Du diesen String mal ausgeben und
nachsehen, ob da auch *tats&auml;chlich* nur ein Tag drinsteht?

Wenn nicht, kannst Du mal nachsehen, ob zwischen den einzelnen
Buchungstagen die Trennsequenz "\r\n-\r\n" [5 Zeichen] steht?
Wenn nicht, ist das schon mal ein Problem... (wenn anstatt "\r\n"
bei Dir "@@" stehen sollte, ist das okay, das wird von einem
Rewriter-Modul (1822direkt) korrigiert).

Gr&uuml;&szlig;e
-Stefan-

  </pre>
</blockquote>
</body>
</html>

Re: [Hbci4java-help] Abweichung im Saldo der Buchung, erste Spur

[Stefan P. <kle...@gm...>]

Hallo,

> und lerne, dass Zeile 131 nur einmal durchlaufen wird, das hei=DFt alle=
=20
> Tage als ein Tag behandelt werden.

hmm, das d=FCrfte wahrlich nicht passieren. Kannst Du mal bitte
folgendes ausprobieren: In Zeile 71 (ca.) steht
"String st_tag=3DSwift.getOneBlock(booked);". Damit werden
aus dem kompletten empfangenen Kontoauszug genau die Daten eines
Buchungstages extrahiert. Kannst Du diesen String mal ausgeben und
nachsehen, ob da auch *tats=E4chlich* nur ein Tag drinsteht?

Wenn nicht, kannst Du mal nachsehen, ob zwischen den einzelnen
Buchungstagen die Trennsequenz "\r\n-\r\n" [5 Zeichen] steht?
Wenn nicht, ist das schon mal ein Problem... (wenn anstatt "\r\n"
bei Dir "@@" stehen sollte, ist das okay, das wird von einem
Rewriter-Modul (1822direkt) korrigiert).

Gr=FC=DFe
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] Abweichung im Saldo der Buchung, erste Spur

[Marc B. <ba...@ma...>]

Hallo Stefan,

nachdem ich mir an den relaevanten Stelle beim Dekodieren der Meldung 
der Bank in hbci4java
den Saldo ausgeben lasse, habe ich einen Hinweis darauf was nicht 
stimmt. Ich logge in extractResults() 
nach
Zeile 131:  int ums_counter=0;
und nach
Zeile 191: line.saldo.value=new 
Value(Math.abs(saldo),btag.start.value.curr);
und lerne, dass Zeile 131 nur einmal durchlaufen wird, das heißt alle 
Tage als ein Tag behandelt werden.

Wie es dazu kommt und warum es schon nach der 3. Buchung zu 3 
Nachkommastellen (Rundungsfehlern) führt ist mir allerdings
nicht so richtig klar.

Ich hoffe dir hilft die Information erstmal.

Gruss, Marc

[Hbci4java-help] Abweichung im Saldo der Buchung

[Marc B. <ba...@ma...>]

Hallo Stefan,

das Log zeigt, dass die Bank die richtigen Salden liefert. Ich habe mir 
die DBG-Messages
von Wallstreet9 angesehen. und für die relevante Buchung nachvollzogen.
Sowohl der Tagesstart (:60F:  - :60M: gibts bei mir garnicht) als auch der
Tagesendwert (:62F:) sind korrekt bis zur letzten Buchung, während 
Wallstreet
nachwievor meinen Cent unterschlägt, und diesen beharrlich bis zur 
letzten Buchung
nicht wieder hergibt :-).

Die Bank liefert auch konstant 2 Nachkommastellen. Die Ungenauigkeit muß 
also
irgendwo auf dem Weg zu value.toString() entstehen.

Gruß, Marc

Re: [Hbci4java-help] Abweichung im Saldo der Buchung

[Stefan P. <kle...@gm...>]

Hallo Marc,

es wird ja immer verwunderlicher... ;-)

> Was mir bei den in GVRKUms.UmsLine.saldo.value gelieferten Werten
> auffiel (vor=20
> dem Schreiben in die Datenbank gebe ich diese als String auf der
> Console aus): Die Werte
> sind auch nicht immer auf zwei Stellen gerundet sondern haben =F6fters =
3
> Nachkommastellen.

damit habe ich ehrlich gesagt nicht gerechnet. Wenn ich es mir
recht =FCberlege, macht das aber u.U. Sinn, z.B. wenn die Bank
Zinsen gutschreibt oder so, dann kann sie das intern nat=FCrlich
mit drei oder mehr Nachkommastellen machen... hmm, Mist.

> Die ersten Daten habe ich noch mit der hbci4java-2.4.6pre-20031017
> eingelesen. Inzwischen
> arbeite ich mit hbci4java-2.4.6. Glaube aber nicht dass daher der=20
> Unterschied kommt.

richtig, daran hat sich ewig nichts ge=E4ndert.

> Vielmehr scheint es daher zu kommen, - das macht auch meinem
> Synchronisationsmechanismus=20
> zu schaffen - dass die Raiba (Abfrage ohne Einschr=E4nkung auf Datum)
> mitten im Tag beginnt,
> also nicht garantiert mit der ersten Buchung des Tages beginnt (Hat
> wohl mit deren L=F6schstrategie=20
> zu tun).

das ist nicht der Punkt. In den zur=FCckgemeldeten Kontoausz=FCgen
wird zu jedem Buchungstag eine Anfangs- und Endsaldo-Information
geliefert, unabh=E4ngig davon, ob die zur=FCckgemeldeten Buchungen
*alle* Buchungen dieses Tages waren oder ob es andere Buchungen
gab, die nicht mit zur=FCckgemeldet wurden (z.B. weil sie schon zu
alt sind). Also *immer* STARTSALDO-BUCHUNGEN-ENDSALDO.
Der Saldo, den HBCI4Java verwendet, wird bei STARTSALDO synchronisiert,
beim Auswerten der einzelnen BUCHUNGEN wird der HBCI4Java-Saldo
dann weitergerechnet. Eine =DCberpr=FCfung, ob der ENDSALDO mit dem
HBCI4Java-Saldo am Ende eines Buchungstages =FCbereinstimmt, wird
nicht gemacht. F=FCr den n=E4chsten Buchungstag wird aber der HBCI4Java-
Saldo auf jeden Fall mit dem n=E4chsten STARTSALDO synchronisiert.

> Die =E4lteste Buchung, die ich heute Abholen kann ist vom 20.08.2003,
> weitere gibts am=20
> 26., 27, 28, und 29.08. Wenn ich die Abfrage einschr=E4nke auf 28.08
> tritt der Fehler trotzdem
> auf. Hole ich mir jedoch Buchungen ab dem 29.08.2003 stimmen die
> Salden pl=F6tzlich.

hmm, seltsam.

> Wenn du mir sagst an welcher Stelle ich die von der Bank gemeldeten
> Buchungssalden=20
> (m=F6glichst) direkt abgreifen kann, k=F6nnte ich mal das Logging
> erweitern, um der Sache=20
> auf die Spur zu kommen.

da brauchst Du nicht so viel zu erweitern. Du loggst einfach im
Debug-Level "DEBUG" (kannst Du in wallstreet9 einstellen).=20
Du siehst dann f=FCr jede empfangene Nachricht u.a. den Text
"Nachricht nach Entschl=FCsselung: ...". Da steht dann die Klartext-
nachricht von der Bank. Die Nachricht mit den Kontoausz=FCgen
ist relativ lang, darin musst du eine Stelle mit ":60F:" oder
":60M:" finden (das ist der Anfangssaldo eines Buchungstages).
Danach kommen ein Haufen Buchungen, anschli=DFened kommt der
Endsaldo f=FCr diesen Tag (wieder ":60F:" oder ":60M:"). Das Format
dieses Tag ist immer ":60x:CJJMMTTEUR9,87". Dabei steht an der
Stelle "C" immer entweder "C" (f=FCr Guthaben) oder "D" (f=FCr Miese)
[ein negativer Saldo wird also niemals mit "-" geschrieben, sondern
da steht an der Stelle einfach "D" anstatt "C"]. JJMMTT steht f=FCr
Jahr/Monat/Tag, f=FCr den der Saldo gilt (Anfangs- resp. Endsaldo des
genannten Tages). EUR ist immer EUR und gibt die Kontow=E4hrung an.
9,87 ist der Saldo. Genau da m=FCsstest du halt mal sehen, ob da
tats=E4chlich auch Werte mit mehr als zwei Nachkommastellen auftreten.
Wenn ja, muss ich das irgendwie einbauen, weil ich sowas im Code
automatisch auf zwei Nachkommastellen runde (hab ich gerade=20
nachgesehen). Wenn es das ist, muss ich wohl ein wenig rum=E4ndern... :-(

Gr=FC=DFe=20
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] Abweichung im Saldo der Buchung

[Marc B. <ba...@ma...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Hallo Stefan,<br>
<br>
das beschriebene Problem erstreckt sich &uuml;ber viele Tage, genauer gesagt
tritt der Fehler <br>
bei der ersten Buchung des 28.10.2003 auf und zieht sich dann bis heute
(ca. 50 Buchungen)! <br>
Ich konnte die das ganze heute morgen noch einmal mit Wallstreet9
reproduziere.<br>
<br>
Was mir bei den in GVRKUms.UmsLine.saldo.value gelieferten Werten
auffiel (vor <br>
dem Schreiben in die Datenbank gebe ich diese als String auf der
Console aus): Die Werte<br>
sind auch nicht immer auf zwei Stellen gerundet sondern haben &ouml;fters 3
Nachkommastellen.<br>
<br>
Da ich bisher davon ausging, dass der Saldo in der Buchung von der Bank
kommt, habe ich <br>
diesen beim Einpflegen in die Db mit in den Schl&uuml;ssel mit aufgenommen,
um bereits Verbuchte <br>
Buchungen nicht doppelt einzupflegen. <br>
<br>
Wie ich jetzt feststelle, liefert mir hbci4java f&uuml;r ein und die selbe
Buchung geringf&uuml;gig <br>
unterschiedliche Salden (Bei unterschiedlichen Programml&auml;ufen). Der
Synchronisationsmechanismus <br>
scheitert nat&uuml;rlich komplett. Grunds&auml;tzlich l&auml;&szlig;t sich nach einer
Dublettenabfrage in der Datenbank <br>
sagen, dass einer von beiden Salden, die zur Dublette f&uuml;hren, immer 3
Nachkommastellen besitzt.<br>
<br>
Die ersten Daten habe ich noch mit der hbci4java-2.4.6pre-20031017
eingelesen. Inzwischen<br>
arbeite ich mit hbci4java-2.4.6. Glaube aber nicht dass daher der
Unterschied kommt.<br>
Vielmehr scheint es daher zu kommen, - das macht auch meinem
Synchronisationsmechanismus <br>
zu schaffen - dass die Raiba (Abfrage ohne Einschr&auml;nkung auf Datum)
mitten im Tag beginnt,<br>
also nicht garantiert mit der ersten Buchung des Tages beginnt (Hat
wohl mit deren L&ouml;schstrategie <br>
zu tun).<br>
<br>
Die &auml;lteste Buchung, die ich heute Abholen kann ist vom 20.08.2003,
weitere gibts am <br>
26., 27, 28, und 29.08. Wenn ich die Abfrage einschr&auml;nke auf 28.08
tritt der Fehler trotzdem<br>
auf. Hole ich mir jedoch Buchungen ab dem 29.08.2003 <b>stimmen </b>die
Salden pl&ouml;tzlich.<br>
<br>
Wenn du mir sagst an welcher Stelle ich die von der Bank gemeldeten
Buchungssalden <br>
(m&ouml;glichst) direkt abgreifen kann, k&ouml;nnte ich mal das Logging
erweitern, um der Sache <br>
auf die Spur zu kommen.<br>
<br>
Gru&szlig;, Marc<br>
<br>
<br>
</body>
</html>

Re: [Hbci4java-help] Abweichung im Saldo der Buchung =?ISO-8859-1?Q?=28Erg=E4nzung=29?=

[Stefan P. <kle...@gm...>]

Auch hallo nochmal,

ich sehe gerade was im Code. Die Salden werden doch nicht
*immer* von HBCI4Java berechnet, sondern das funktioniert
vielmehr wiefolgt: Am Beginn eines neuen *Buchungstages*=20
wird die Saldeninformation von der Bank genommen. Alle Buchungen
f=FCr diesen einen Tag werden dann von HBCI4Java saldiert.
Der Saldo f=FCr die erste Buchung des n=E4chsten Buchungstages
(also mit einem anderen Buchungsdatum) wird dann wieder aus den
Daten von der Bank extrahiert.

Wenn das Problem also an einer Stelle beginnt und sich dann bis
zum Ende des Kontoauszuges fortsetzt, hie=DFe das wohl, dass es
sich bei den falsch besaldeten Kontoauszugszeilen um ein und
den selben Buchungstag handelt...??? Wenn nicht, m=FCsste n=E4mlich
wenigstens einmal (beim Wechsel des Buchungstages) eine=20
"Synchronisation" mit den Daten, die von der Bank kommen statt-
finden...

-Stefan-

> Hallo nocheinmal,
>=20
> Marc Bantle meinte am 08.12.2003 22:17:
>=20
> > Hallo Stefan,
> >
> > nachdem ich inzwischen die Ums=E4tze meines Raibakontos regelm=E4=DFi=
g in die
> > Datenbank schreibe (Das Programm habe ich durch Erweiterung von
> > AnalyzeReportOfTransactions.java erstellt) und von dort in Star-Calc
> > weiterverarbeite, bin ich auf ein merkw=FCrdiges Ph=E4nomen gesto=DFe=
n.
> >
> > Der von hbci4java gelieferte GVRKUms.UmsLine.saldo.value weicht ab ei=
ner
> > bestimmten Buchung um einen Cent nach unten von dem Wert ab, der sich=
 aus
> > dem Saldo der vorangegangenen Buchung + dem Buchungswert ergibt.
> >
> > Der Cent fehlt fortan im UmsLine.Saldo bis zur letzten abgeholten=20
> > Buchung,
> > es gibt also im weiteren Verlauf keine Rechenfehler mehr auf. Leider=20
> > entspricht
> > dabei der Saldo der letzten Buchung nicht dem Kontostand, den sowohl
> > Wallstreet9 als auch der Webzugang zum Konto identisch und eben um ei=
nen
> > Cent h=F6her anzeigen.
> >
> > Wird der Saldo in der UmsLine von der Bank geliefert oder generierst=20
> > du diesen
> > in hbci4java?
> >
> > Bin leider noch nicht dazugekommen mein Probleme mit der Dresdner Ban=
k
> > weiter zu verfolgen, muss ich mich aber mal dranmachen.
> >
> > Gru=DF, Marc
>=20
> Wallstreet zeigt ja freundlicherweise auch die Buchungssalden an, wie=20
> ich gerade endecke.
> Dort tritt genau das selbe Problem auf, witzigerweise aber eine Buchung=
=20
> vorher. Nat=FCrlich
> ebenso mit dem Ergebnis, dass der Saldo der letzten Buchung ein Cent zu=
m=20
> tats=E4chlichen
> Kontostand fehlt!
>=20
> Ich kann mir leider keine Reim drauf machen.
>=20
> Gru=DF, Marc
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

Re: [Hbci4java-help] Abweichung im Saldo der Buchung =?ISO-8859-1?Q?=28Erg=E4nzung=29?=

[Stefan P. <kle...@gm...>]

Hallo Marc,

das ist offensichtlich ein ernstes Problem ;-). Zum Gl=FCck
werden die jeweiligen Salden von HBCI4Java berechnet und nicht
von der Bank geliefert. Wahrscheinlich handelt es sich hier nur
um einen internen Rundungsfehler, obwohl ich mir nicht so recht
erkl=E4ren kann, wie bei Zahlen, die (im rechentechnischen Sinne)
weder besonders gross noch besonders klein sind und die nur zwei
Nachkommastellen haben, so etwas auftreten kann.

Ich werde mir das aber mal ansehen. Kannst Du den Bug eigentlich
beliebig reproduzieren? Nur f=FCr den Fall, dass ich eine (hoffentlich)
fehlerbereinigte Version bereitstellen kann und Du das dann
mal testen m=FCsstest - ich konnte dieses Verhalten n=E4mlich bis jetzt
noch nicht nachvollziehen...

Gr=FC=DFe
-Stefan-

> Hallo nocheinmal,
>=20
> Marc Bantle meinte am 08.12.2003 22:17:
>=20
> > Hallo Stefan,
> >
> > nachdem ich inzwischen die Ums=E4tze meines Raibakontos regelm=E4=DFi=
g in die
> > Datenbank schreibe (Das Programm habe ich durch Erweiterung von
> > AnalyzeReportOfTransactions.java erstellt) und von dort in Star-Calc
> > weiterverarbeite, bin ich auf ein merkw=FCrdiges Ph=E4nomen gesto=DFe=
n.
> >
> > Der von hbci4java gelieferte GVRKUms.UmsLine.saldo.value weicht ab ei=
ner
> > bestimmten Buchung um einen Cent nach unten von dem Wert ab, der sich=
 aus
> > dem Saldo der vorangegangenen Buchung + dem Buchungswert ergibt.
> >
> > Der Cent fehlt fortan im UmsLine.Saldo bis zur letzten abgeholten=20
> > Buchung,
> > es gibt also im weiteren Verlauf keine Rechenfehler mehr auf. Leider=20
> > entspricht
> > dabei der Saldo der letzten Buchung nicht dem Kontostand, den sowohl
> > Wallstreet9 als auch der Webzugang zum Konto identisch und eben um ei=
nen
> > Cent h=F6her anzeigen.
> >
> > Wird der Saldo in der UmsLine von der Bank geliefert oder generierst=20
> > du diesen
> > in hbci4java?
> >
> > Bin leider noch nicht dazugekommen mein Probleme mit der Dresdner Ban=
k
> > weiter zu verfolgen, muss ich mich aber mal dranmachen.
> >
> > Gru=DF, Marc
>=20
> Wallstreet zeigt ja freundlicherweise auch die Buchungssalden an, wie=20
> ich gerade endecke.
> Dort tritt genau das selbe Problem auf, witzigerweise aber eine Buchung=
=20
> vorher. Nat=FCrlich
> ebenso mit dem Ergebnis, dass der Saldo der letzten Buchung ein Cent zu=
m=20
> tats=E4chlichen
> Kontostand fehlt!
>=20
> Ich kann mir leider keine Reim drauf machen.
>=20
> Gru=DF, Marc
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] Abweichung im Saldo der Buchung =?ISO-8859-1?Q?=28Erg=E4nzung=29?=

[Marc B. <ba...@ma...>]

Hallo nocheinmal,

Marc Bantle meinte am 08.12.2003 22:17:

> Hallo Stefan,
>
> nachdem ich inzwischen die Umsätze meines Raibakontos regelmäßig in die
> Datenbank schreibe (Das Programm habe ich durch Erweiterung von
> AnalyzeReportOfTransactions.java erstellt) und von dort in Star-Calc
> weiterverarbeite, bin ich auf ein merkwürdiges Phänomen gestoßen.
>
> Der von hbci4java gelieferte GVRKUms.UmsLine.saldo.value weicht ab einer
> bestimmten Buchung um einen Cent nach unten von dem Wert ab, der sich aus
> dem Saldo der vorangegangenen Buchung + dem Buchungswert ergibt.
>
> Der Cent fehlt fortan im UmsLine.Saldo bis zur letzten abgeholten 
> Buchung,
> es gibt also im weiteren Verlauf keine Rechenfehler mehr auf. Leider 
> entspricht
> dabei der Saldo der letzten Buchung nicht dem Kontostand, den sowohl
> Wallstreet9 als auch der Webzugang zum Konto identisch und eben um einen
> Cent höher anzeigen.
>
> Wird der Saldo in der UmsLine von der Bank geliefert oder generierst 
> du diesen
> in hbci4java?
>
> Bin leider noch nicht dazugekommen mein Probleme mit der Dresdner Bank
> weiter zu verfolgen, muss ich mich aber mal dranmachen.
>
> Gruß, Marc

Wallstreet zeigt ja freundlicherweise auch die Buchungssalden an, wie 
ich gerade endecke.
Dort tritt genau das selbe Problem auf, witzigerweise aber eine Buchung 
vorher. Natürlich
ebenso mit dem Ergebnis, dass der Saldo der letzten Buchung ein Cent zum 
tatsächlichen
Kontostand fehlt!

Ich kann mir leider keine Reim drauf machen.

Gruß, Marc

[Hbci4java-help] Abweichung im Saldo der Buchung

[Marc B. <ba...@ma...>]

Hallo Stefan,

nachdem ich inzwischen die Umsätze meines Raibakontos regelmäßig in die
Datenbank schreibe (Das Programm habe ich durch Erweiterung von
AnalyzeReportOfTransactions.java erstellt) und von dort in Star-Calc
weiterverarbeite, bin ich auf ein merkwürdiges Phänomen gestoßen.

Der von hbci4java gelieferte GVRKUms.UmsLine.saldo.value weicht ab einer
bestimmten Buchung um einen Cent nach unten von dem Wert ab, der sich aus
dem Saldo der vorangegangenen Buchung + dem Buchungswert ergibt.

Der Cent fehlt fortan im UmsLine.Saldo bis zur letzten abgeholten Buchung,
es gibt also im weiteren Verlauf keine Rechenfehler mehr auf. Leider 
entspricht
dabei der Saldo der letzten Buchung nicht dem Kontostand, den sowohl
Wallstreet9 als auch der Webzugang zum Konto identisch und eben um einen
Cent höher anzeigen.

Wird der Saldo in der UmsLine von der Bank geliefert oder generierst du 
diesen
in hbci4java?

Bin leider noch nicht dazugekommen mein Probleme mit der Dresdner Bank
weiter zu verfolgen, muss ich mich aber mal dranmachen.

Gruß, Marc

[Hbci4java-help] update des online-demo-servers

[Stefan P. <kle...@gm...>]

Hallo,

ich habe heute ein Update des Online-HBCI-Demoservers gemacht,
weil es einige Problemchen gegeben hatte. Vor allem d=FCrfte seit
Montag das Einreichen von Gesch=E4ftsvorf=E4llen fast =FCberhaupt nicht
mehr funktioniert haben. Grund war ein mit einem Serverneustart
verbundener Wechsel der verwendeten Locale, so dass das Bank-
Backendsystem seine eigenen Daten nicht mehr lesen konnte... :-(
Das ist jetzt jedenfalls behoben.

Au=DFerdem wurden einige kleinere interne Bugs gefixt und der
Gesch=E4ftsvorfall "Kontoausz=FCge abholen" integriert. Alle derzeit
unterst=FCtzten Gesch=E4ftsvorf=E4lle sind auf der entsprechenden
Webseite (http://hbci4java.kapott.org/demoserver.html) nachzulesen.

Durch eine =C4nderung der Datenstrukturen, die das Backendsystem
der "Bank" verwendet, wurde es leider n=F6tig, alle Nutzdaten der
Nutzer zu l=F6schen. D.h., dass bei der n=E4chsten Saldenabfrage alle
Konten wieder auf "0.00" stehen, auch die Kontoausz=FCge liefern
zun=E4chst keine Eintr=E4ge zur=FCck (bis zur n=E4chsten =DCberweisung/=20
Lastschrift nat=FCrlich).

Gr=FC=DFe ohne Ende
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

Re: [Hbci4java-help] =?ISO-8859-1?Q?Ums=E4tze?= Dresdner Bank

[Stefan P. <kle...@gm...>]

Hallo,

bei dem Problem handelt es sich im einen Fehler im Parser der zur=FCck-
gemeldeten Kontoausz=FCge. Besser gesagt, die Kontoausz=FCge der Dresdner
Bank haben nicht ganz das vorgeschriebene Format - zumindest der
eine Eintrag, bei dem der Fehler auftritt.

Damit ich einen entsprechenden Workaround basteln kann, br=E4uchte ich
zu dem Kontoauszug ein paar Informationen. Am besten w=E4re ein komplettes
Logfile des betreffenden Dialoges mit Loglevel 4 oder 5. Es w=FCrde aber
auch erst mal reichen, wenn ich aus dem betreffenden Logfile alle
Zeilen, die das Format ":25:.." haben (die also mit ":25:" beginnen),
mal sehen k=F6nnte.

Viele Gr=FC=DFe
-Stefan-

> Hallo Allerseits,
>=20
> nachdem die HBCI-Verbindung zur Raifeisenbank (Kieselbronn) problemlos=20
> ihren Dienst tut, versuche ich gerade mein Konto bei der Dresdnerbank=20
> anzubinden. Dabei treten unerwartet Probleme auf.
>=20
> Die Saldenabfrage funktioniert problemlos. Wenn ich allerdings Ums=E4tze=20
> abziehen will, erhalte ich die folgende Fehlermeldung:
>=20
> <ERR> [2003.11.28 18:20:49.921] [main/Thread-4] manager.HBCIUtils:=20
> Exception: Fehler beim Speichern der Ergebnisdaten f=B3r Job KUmsZeit4 im=
=20
> JobResult-Objekt
>    -> String index out of range: -1
> org.kapott.hbci.exceptions.HBCI_Exception: Fehler beim Speichern der=20
> Ergebnisdaten f=B3r Job KUmsZeit4 im JobResult-Objekt
>          at org.kapott.hbci.GV.HBCIJob.fillJobResult(HBCIJob.java:509)
>          at org.kapott.hbci.manager.HBCIDialog.doJobs(HBCIDialog.java:272=
)
>          at org.kapott.hbci.manager.HBCIDialog.doIt(HBCIDialog.java:349)
>          at=20
> org.kapott.hbci.manager.HBCIHandler.execute(HBCIHandler.java:276)
>          at org.kapott.wallstreet9.HBCI.execute(HBCI.java:193)
>          at org.kapott.wallstreet9.JobStatement$1.run(JobStatement.java:1=
92)
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out=20
> of range: -1
>          at java.lang.String.substring(String.java:1480)
>          at org.kapott.hbci.GV.GVKUmsAll.extractResults(GVKUmsAll.java:73=
)
>=20
>=20
> Anfangs dachte ich, es l=E4ge an dem umfangreichen Buchungstext der erste=
n=20
> Buchung (35 Zeilen). (Wo liegt hier eigentlich die HBCI-Obergrenze?)
>=20
> Um dies auszuschlie=DFen habe ich durch Start- und Endedatum eine Buchung=
=20
> mit kurzem Text ausgew=E4hlt (5 Zeilen). Aber auch hiert tritt derselbe=20
> Fehler auf.
>=20
> Nebenbei: Es ist mir auch mit aqmoney nicht gelungen Ums=E4tze von der=20
> Dresdner Bank abzuziehen.
>=20
> Kennt jemand das Problem oder kann mir sonst weiterhelfen!
>=20
> Gru=DF, Marc
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Hbci4java-help mailing list
> Hbc...@li...
> https://lists.sourceforge.net/lists/listinfo/hbci4java-help
--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] =?ISO-8859-1?Q?Ums=E4tze_Dresdner_Bank?=

[Marc B. <ba...@ma...>]

Hallo Allerseits,

nachdem die HBCI-Verbindung zur Raifeisenbank (Kieselbronn) problemlos 
ihren Dienst tut, versuche ich gerade mein Konto bei der Dresdnerbank 
anzubinden. Dabei treten unerwartet Probleme auf.

Die Saldenabfrage funktioniert problemlos. Wenn ich allerdings Umsätze 
abziehen will, erhalte ich die folgende Fehlermeldung:

<ERR> [2003.11.28 18:20:49.921] [main/Thread-4] manager.HBCIUtils: 
Exception: Fehler beim Speichern der Ergebnisdaten f³r Job KUmsZeit4 im 
JobResult-Objekt
   -> String index out of range: -1
org.kapott.hbci.exceptions.HBCI_Exception: Fehler beim Speichern der 
Ergebnisdaten f³r Job KUmsZeit4 im JobResult-Objekt
         at org.kapott.hbci.GV.HBCIJob.fillJobResult(HBCIJob.java:509)
         at org.kapott.hbci.manager.HBCIDialog.doJobs(HBCIDialog.java:272)
         at org.kapott.hbci.manager.HBCIDialog.doIt(HBCIDialog.java:349)
         at 
org.kapott.hbci.manager.HBCIHandler.execute(HBCIHandler.java:276)
         at org.kapott.wallstreet9.HBCI.execute(HBCI.java:193)
         at org.kapott.wallstreet9.JobStatement$1.run(JobStatement.java:192)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out 
of range: -1
         at java.lang.String.substring(String.java:1480)
         at org.kapott.hbci.GV.GVKUmsAll.extractResults(GVKUmsAll.java:73)


Anfangs dachte ich, es läge an dem umfangreichen Buchungstext der ersten 
Buchung (35 Zeilen). (Wo liegt hier eigentlich die HBCI-Obergrenze?)

Um dies auszuschließen habe ich durch Start- und Endedatum eine Buchung 
mit kurzem Text ausgewählt (5 Zeilen). Aber auch hiert tritt derselbe 
Fehler auf.

Nebenbei: Es ist mir auch mit aqmoney nicht gelungen Umsätze von der 
Dresdner Bank abzuziehen.

Kennt jemand das Problem oder kann mir sonst weiterhelfen!

Gruß, Marc

[Hbci4java-help] update: hbci4java-server testzugang

[Stefan P. <kle...@gm...>]

Hallo,

nach ein paar Startproblemen bzgl. einiger vergessener Synchronisations-
mechanismen ist jetzt eine aktualisierte Version des HBCI-Servers
online.

Diese unterst=FCtzt jetzt neben "Saldenabfrage", "=DCberweisung" und
"Kundenmitteilung" zus=E4tzlich die Gesch=E4ftsvorf=E4lle "Umbuchung"=20
und "Lastschrift einreichen". Alle diese GVs werden auch vom
Backend-System verarbeitet.

Gr=FC=DFe
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] hbci4java-server testzugang

[Stefan P. <kle...@gm...>]

Hallo,

seit heute nacht ist ein auf HBCI4Java-Server basierender
Demo-HBCI-Server online. Der beherrscht zwar noch nicht das
komplette HBCI-Protokoll bis in alle Einzelheiten, aber die
grundlegenden Funktionen zur Schl=FCsselverwaltung und zur
Ausf=FChrung von Gesch=E4ftsvorf=E4llen sind implementiert.

Es wird auch bereits ein Bank-Backend-System simuliert, so dass
die GVs "=DCberweisung" und "Saldenabfrage" schon richtig=20
ausprobiert werden k=F6nnen.

Au=DFerdem gibt es (im Gegensatz zum Testserver von PPI) ein
Web-Frontend, wo Inhaber eines HBCI-Accounts auf dem Testserver
einige Daten ihres HBCI-Accounts selbst und in Echtzeit
manipulieren k=F6nnen (z.B. das oft Zur=FCcksetzen von Schl=FCsseln ;-) ).

Es gibt allerdings noch viel zu tun, warten wir's ab. Wer einen
Zugang auf dem Server haben m=F6chte, schreibt mir einfach ne
Email, ich schicke dann die entsprechenden Daten.

Gr=FC=DFe
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] HBCI4Java-Server und neue Release

[Stefan P. <kle...@gm...>]

Hallo zusammen,

unter http://hbci4java.kapott.org/#download ist eine neue "offizielle"
HBCI4Java Release zu haben. Im Prinzip deckt sie sich mit dem letzten
Snapshot.

Im Vergleich zur vorhergehenden Release ist also neu:
  - besserer Support f=FCr multithreaded Anwendungen
  - (bessere) Unterst=FCtzung vom Schl=FCsseldateien anderer Software
    (StarMoney, GENOlite, OpenHBCI)
  - Sammellastschriften und -=FCberweisungen k=F6nnen jetzt direkt mit
    dem integrierten DTAUS-Generator erzeugt werden
  - bessere =DCberpr=FCfungen der Auftragsdaten schon vor dem Erzeugen
    und Versenden von HBCI-Nachrichten
  - eine Menge kleinerer Bugfixes und Geschwindigkeitsoptimierungen

Dazu geh=F6rt nat=FCrlich der ebenfalls aktualisierte=20
HBCI4Java Passport Editor ebenso wie eine aktualisierte Version
von wallstreet9.

So richtig neu ist allerdings das HBCI4Java-Server Framework, welches
jetzt ebenfalls erstmals =F6ffentlich verf=FCgbar ist. Bei diesem Paket
handelt es sich zum einen um ein Framework f=FCr die Implementierung
eines eigenen HBCI-Servers (wobei praktisch nur noch die Reaktionen
auf die Kundenauftr=E4ge selbst implementiert werden muss). Au=DFerdem
ist in diesem Paket bereits ein mit diesem Framework implementierter
Demo-Server enthalten, der (hoffentlich) einfach ausgepackt und
gestartet werden muss, schon hat man seinen eigenen Testserver
(wenn man sich vorerst mit zwei Gesch=E4ftsvorf=E4llen zufrieden gibt).

Viel Spass beim Testen und rummeckern!

Gr=FC=DFe und sch=F6nes Wochenende
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

Re: [Hbci4java-help] hbci4j - wallstreet doku ?

[Stefan P. <kl...@ka...>]

Hallo,

bei dem PinTan-Verfahren aus HBCI4Java handelt es sich
*NICHT* um das "bekannte" PIN/TAN-Verfahren, was mit jedem
Homebanking-Programm bzw. =FCber das Web-Interface des
OnlineBanking der jeweiligen Bank funktioniert.

Vielmehr handelt es sich bei HBCI4Java-PinTan um eine
Erweiterung des HBCI-Protokolles, bei dem PIN und TAN
als Authentifikation resp. Signatur verwendet werden.

Um HBCI4Java-PinTan benutzen zu k=F6nnen, muss also ein
HBCI-Zugang bei der jeweiligen Bank vorhanden sein. Ausserdem
muss diese Bank HBCI+ unterst=FCtzen (das ist HBCI mit der
PIN/TAN-Erweiterung). Und noch mal au=DFerdem muss nat=FCrlich
eine g=FCltige PIN und eine TAN-Liste f=FCr den Einsatz mit
dem HBCI-Account vorhanden sein.

Viele Gr=FC=DFe
-Stefan-

> Hallo,
> ich konnte leider nirgendwo finden,
> wie ich eine einfache Abfrage (Kontoausz=FCge)
> =FCber das Pin/Tan Verfahren, ohne Kartenleser usw. machen kann.
>=20
> Kann mir jemand die ben=F6tigten Schritte erkl=E4ren ?
>=20
> Thx
> berger
--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] hbci4j - wallstreet doku ?

[Albrecht B. <ber...@gm...>]

Hallo,
ich konnte leider nirgendwo finden,
wie ich eine einfache Abfrage (Kontoauszüge)
über das Pin/Tan Verfahren, ohne Kartenleser usw. machen kann.

Kann mir jemand die benötigten Schritte erklären ?

Thx
berger

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: [Hbci4java-help] Source-Archiv defekt?

[Stefan P. <hbc...@ka...>]

Hallo,

sorry, da ist wohl beim Upload was schiefgegangen.
Habe jetzt neue Archive hochgeladen.

Gr=FC=DFe
-Stefan-

> Hallo Stefan!
>=20
> Sowohl von zu Hause aus als auch aus der Firma sind die von mir
> heruntergeladenen ZIP-Archive (20031104) defekt, ich kann sie nicht
> entpacken.
> Bitte stell gefixte Archive bereit!

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] Source-Archiv defekt?

[Christoph B. <c_b...@gm...>]

Hallo Stefan!

Sowohl von zu Hause aus als auch aus der Firma sind die von mir
heruntergeladenen ZIP-Archive (20031104) defekt, ich kann sie nicht
entpacken.
Bitte stell gefixte Archive bereit!

[Hbci4java-help] dtaus-generator

[Stefan P. <kle...@gm...>]

Hallo,

habe soeben den wahrscheinlich letzten Snapshot vor der
n=E4chsten "offiziellen" Version HBCI4Java 2.4.6 ver=F6ffentlicht.

Im neuesten Paket (-20031104) ist ein einfacher DTAUS-Generator=20
enthalten. Die Gesch=E4ftsvorf=E4lle "Sammel=FCberweisung" und=20
"Sammellastschrift", welche es schon eine ganze Weile in HBCI4Java
gibt, erwarten einen DTAUS-String als Input f=FCr die auszul=F6senden
Transaktionen. Dieser DTAUS-String kann jetzt direkt mit HBCI4Java
selbst erzeugt werden (Klasse org.kapott.hbci.swift.DTAUS). Bisher
war das nur =FCber "externe" Tools bzw. den Import von schon vorhandenen
DTAUS-Daten m=F6glich.

Viele Gr=FC=DFe
-Stefan-

(Nehme noch W=FCnsche f=FCr die n=E4chste Release entgegen... ;-) )

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] neuer snapshot von wallstreet9

[Stefan P. <kle...@gm...>]

hallo,

von wallstreet9 ist ein neuer snapshot verf=FCgbar, bei
dem vor allem die fehlerbehandlung etwas aufpoliert
wurde ;-)

f=FCr diesen snapshot (20031030) wird auch ein aktualisierter
hbci4java-snapshot (20031030) ben=F6tigt.

gr=FC=DFe
-stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------

[Hbci4java-help] bug im letzten snapshot

[Stefan P. <kle...@gm...>]

Hallo,

Der snapshot 20031028 enth=E4lt einen Bug, der verursacht,
dass beim Ausf=FChren von Saldenabfragen immer eine Exception
erzeugt wird. Habe eine entsprechend korrigierte Version
hochgeladen (-20031028a)

Gr=FC=DFe
-Stefan-

--=20
-------------------------------------------------------------------
Dipl. Inf. (FH) Stefan Palme

email: kle...@gm...
phon:  +49 341 3910484
fax:   +49 1212 517956219
mobil: +49 178 8426165

key fingerprint: 1BA7 D217 36A1 534C A5AD  F18A E2D1 488A E904 F9EC
-------------------------------------------------------------------