hbci4java-help Mailing List for HBCI4Java (Page 34)
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help — all questions concerning hbci4java
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(21) |
Jun
|
Jul
(9) |
Aug
(2) |
Sep
(16) |
Oct
(9) |
Nov
(10) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(16) |
Feb
(43) |
Mar
(11) |
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
(2) |
Oct
(20) |
Nov
(32) |
Dec
(10) |
| 2005 |
Jan
(15) |
Feb
(15) |
Mar
(20) |
Apr
(19) |
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
(9) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
(34) |
Feb
|
Mar
(9) |
Apr
|
May
(12) |
Jun
(27) |
Jul
(2) |
Aug
(1) |
Sep
(11) |
Oct
(11) |
Nov
(7) |
Dec
(1) |
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(23) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(32) |
May
(29) |
Jun
(22) |
Jul
(3) |
Aug
(5) |
Sep
(25) |
Oct
(30) |
Nov
(25) |
Dec
(1) |
| 2009 |
Jan
(23) |
Feb
(20) |
Mar
(20) |
Apr
(72) |
May
(9) |
Jun
(3) |
Jul
(18) |
Aug
|
Sep
(6) |
Oct
(7) |
Nov
(10) |
Dec
|
| 2010 |
Jan
(19) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(11) |
Jul
(3) |
Aug
(19) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
|
From: Stefan P. <kl...@ka...> - 2004-01-13 10:18:07
|
Hallo, > gibt es bei den Gesch=E4ftsvorf=E4llen KUmsNew und KUmsAll eine > M=F6glichkeit eine einzelne Buchungszeile eindeutig zu identifizieren > und so Duplikate herauszufinden? Gut w=E4re eine Art eindeutige > Buchungsnummer. Leider habe ich es n=E4mlich mit Szenarien zu tun, > in denen dieselbe Person dieselbe =DCberweisung gewollt mehrfach an > einem Tag in Auftrag gibt (Ratenzahlungen). "Duplikate herausfinden" im Sinne der Vorgehensweise, dass man beim mehrmaligen Abholen von Kontoausz=FCgen feststellt, welche man "schon mal" abgeholt hatte, und welche tats=E4chlich neu sind? Dieses Problem ist relativ einfach zu l=F6sen. Man kann zum einen=20 den Gesch=E4ftsvorfall "GVKUmsNew" verwenden (dazu unten mehr), damit erh=E4lt man nur tats=E4chlich neue Buchungen, d.h., alle Daten, die man empf=E4ngt, hat man noch niemals vorher empfangen. Auch wenn GVKUmsNew nicht verwendet wird, gibt es einfache M=F6glichkeit (die zwar leider nicht 100%ig zuverl=E4ssig ist, aber prinzipiell erst mal funktioniert). Kontoausz=FCge werden immer *tagesweise* ausgeliefert. D.h., wenn man den Zeitraum f=FCr einen Kontoauszug einschr=E4nkt, so sin= d sowohl vom Start- als auch vom Enddatum (und nat=FCrlich von den dazwischenliegenden Tagen) alle! Buchungszeilen des Tages im Kontoauszug enthalten. Hat man z.B. am Tag T tats=E4chlich zwei Buchungen B1 und B2, die vom Inhalt her absolut identisch sind (z.B. zwei =DCberweisungen von 100 EUR an mich ;-)), so ist es beim Empfang der zweiten dieser Zeilen einfach, festzustellen, ob es sich um ein Duplikat oder tats=E4chlich eine zweite Buchung handelt: da die beiden Zeilen ja *identisch* sind, sind auch die Buchungstage identisch. Daraus ergibt sich wiederum, dass in einem Kontoauszug, bei dem *eine* der beiden Zeilen enthalten ist, auf jeden Fall auch die *andere* drin ist (gleicher Tag, und alle Daten immer tagesweise gruppiert). Wenn also eine Buchung an einem BTag nur *einmal* auftaucht (egal, wie oft man diesen Kontoauszug schon abgeholt hat), dann ist diese Buchung auch tats=E4chlich nur einmal gelaufen. Sind an einem BTag=20 allerdings *mehrere* identische Buchungen enthalten, so sind diese Buchungen an diesem BTag genau so oft tats=E4chlich aufgetreten, wie es Eintr=E4ge gibt... (ich hoffe das war jetzt nicht zu wirr...) Die "Ausnahme", wo das nicht funktioniert, ist die Stelle in der "Vergangenheit", an der die Bank irgendwann mal Buchungen "vergisst". Von zwei identischen Buchungen am selben Buchungstag kann u.U. schon eine nicht mehr zur=FCckgemeldet werden (z.B. die von 10:00), die von 14:00 Uhr wird aber noch zur=FCckgemeldet... Aber dieser Fall sollte sehr selten auftreten, und dass auch nur bei Buchungen, die schon so alt wie der max. Aufbewahrungszeitraum der Bank sind (bei meiner Bank [Sparkasse Leipzig] sind das 30 oder 60 Tage). > Wenn f=FCr ein Konto mehrere hbci-Zug=E4nge existieren, holt dann der > GV KUmsNew die Ums=E4tze, die mit dem aktiven Zugang noch nicht abgehol= t > wurden oder die, die noch von keinem Zugang abgeholt wurden? Das wei=DF ich leider auch nicht. Ich denke(!), das h=E4ngt nur von der verwendeten *Kunden-ID* (und nicht von der Benutzerkennung) ab. Meiner Meinung nach wird die GVKUmsNew-Sache =FCber die Kunden-IDs geregelt, d.h. wenn eine Kunden-ID einen Kontoauszug mit KUmsNew abholt, und sp=E4ter ein anderer Benutzer (Benutzerkennung), der aber mit der gleichen Kunden-ID arbeitet (n=E4mlich mit der, die Zugriff auf dieses Konto hat), dann sieht er die Daten, die der erste Benutzer abgeholt hatte, schon nicht mehr. > Wenn erst KUmsAll mit einem Startdatum ausgef=FChrt wird und ein paar > Tage sp=E4ter KUmsNew, werden dann alle noch nicht =FCbertragenen Ums=E4= tze > =FCbertragen? KUmsAll und KUmsNew sind unabh=E4ngig voneinander. *Nur* die Ausf=FChrung von GVKUmsNew beeinflusst den internen "Zeiger", welche Daten neu sind und welche nicht (also *nur* der GV KUmsNew arbeitet analog zum Abholen der Kontoausz=FCge ab Auszugsdrucker [das ist ein altmodisches elektronisches Ger=E4t mit eingebauter Druckfunktion zum Abfragen der Kontobewegungen und Speichern dieser Daten auf Papier] ;-) ). Ich hoffe ich konnte helfen... Beste 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 ------------------------------------------------------------------- |
|
From: Christian S. <sti...@tu...> - 2004-01-13 09:02:56
|
Johann Uhrmann schrieb: > Hallo, >=20 > gibt es bei den Gesch=E4ftsvorf=E4llen KUmsNew und KUmsAll eine > M=F6glichkeit eine einzelne Buchungszeile eindeutig zu identifizieren > und so Duplikate herauszufinden? Gut w=E4re eine Art eindeutige > Buchungsnummer. Leider habe ich es n=E4mlich mit Szenarien zu tun, > in denen dieselbe Person dieselbe =DCberweisung gewollt mehrfach an > einem Tag in Auftrag gibt (Ratenzahlungen). Ich hab genau die gleiche Problematik ebenfalls schonmal in HBCI=20 versucht zu l=F6sen. Das war zwar mit einer anderen HBCI-library (n=E4mli= ch=20 OpenHBCI und Gnucash), aber das Problem liegt bei der Implementierung=20 von HBCI auf Bankseite. Der zugrundeliegende HBCI-Standard definiert=20 sehr wohl eine "Kunden-Referenznummer" und eine "Bank-Referenznummer",=20 die f=FCr so etwas genutzt werden k=F6nnte. Aber alle Banken, mit denen ich zu tun hatte (Deutsche Bank=20 Privatkunden, Hamburger Sparkasse, PPI-Testserver), haben f=FCr mich als=20 Privatkunde beide M=F6glichkeiten schlicht nicht belegt. Die Bank gibt=20 also gar keine Information zur=FCck, mit der dann eine Buchungszeile=20 eindeutig identifiziert werden k=F6nnte. :-( Sofern man nicht eine Bank=20 findet, wo das anders ist, h=E4tte ich da wenig Hoffnung... Gru=DF Christian |
|
From: Johann U. <joh...@xp...> - 2004-01-13 08:57:45
|
Hallo, gibt es bei den Geschäftsvorfällen KUmsNew und KUmsAll eine Möglichkeit eine einzelne Buchungszeile eindeutig zu identifizieren und so Duplikate herauszufinden? Gut wäre eine Art eindeutige Buchungsnummer. Leider habe ich es nämlich mit Szenarien zu tun, in denen dieselbe Person dieselbe Überweisung gewollt mehrfach an einem Tag in Auftrag gibt (Ratenzahlungen). Wenn für ein Konto mehrere hbci-Zugänge existieren, holt dann der GV KUmsNew die Umsätze, die mit dem aktiven Zugang noch nicht abgeholt wurden oder die, die noch von keinem Zugang abgeholt wurden? Wenn erst KUmsAll mit einem Startdatum ausgeführt wird und ein paar Tage später KUmsNew, werden dann alle noch nicht übertragenen Umsätze übertragen? Vielen Dank, Johann Uhrmann -- Johann Uhrmann xpecto AG | Lindenstrasse 81 | D-84030 Ergolding Telefon: 0700 xpecto 00 (0700 973286 00) Telefax: 0700 xpecto 10 (0700 973286 10) Internet: http://www.xpecto.com |
|
From: Stefan P. <kle...@gm...> - 2004-01-08 09:29:15
|
Hallo, leider hatte sich im letzten Snapshot (20040106) ein Bug=20 eingeschlichen, der verursacht hat, dass beim Abholen von Kontoausz=FCgen der Parser in einer Endlosschleife festhing. Dieser Bug ist mit dem heutigen Snapshot (20040108) behoben. Au=DFerdem wurde die PIN/TAN-Passport-Implementation erweitert. Beim Erzeugen von PIN/TAN-Passports muss jetzt der zu verwendende Kommunikationsfilter (None oder Base64) mit angegeben werden. Diese Information kann auch nachtr=E4glich mit dem aktualisierten HBCI4Java Passport Editor bearbeitet werden. Die alten PIN/TAN-Passport-Dateien k=F6nnen ab sofort nicht mehr verwendet werden, sie m=FCssen gel=F6scht und neu erzeugt werden (siehe dazu auch der "Read this"-Link auf der Homepage unter http://hbci4java.kapott.org/#download). Beste Gr=FC=DFe -Stefan- Marc: wenn Du voraussichtlich l=E4nger mit HBCI4Java arbeitst, trag Dich am besten in der Mailingliste ein... Hier gibts immer mal Infos zu aktuellen Bugs/Patches usw. --=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 ------------------------------------------------------------------- |
|
From: Stefan P. <kl...@ka...> - 2004-01-07 10:03:03
|
Hallo,
> F=FCr einen Zugang zur HypoVereins-Bank habe ich versucht per
> InitAndTest und anschlie=DFend via INILetter einen Zugang zu
> bekommen.
>=20
> Jedoch bricht INILetter ab, da von der Bank folgender Fehler
> gemeldet wird:
> 9010 - Erstinitialisierung abgelehnt, zur Freigabe vorgemerkter Schl=FC=
ssel vorhanden
>
> Bedeuted das, dass der Client-Key f=FCr den Passport von der
> Bank erzeugt wird? Falls ja, was ist dann der Inhalt des
> INI-Briefs und (wie) kann er mit hbci4java erstellt werden?
Die Fehlermeldung von der Bank ist leider (wie so oft) nicht besonders
aussagekr=E4ftig. F=FCr mich sieht es so aus, als h=E4tte die Bank bereit=
s
Schl=FCssel in Empfang genommen (vielleicht w=E4hrend der ersten Ausf=FCh=
rung
von InitAndTest?) und verwehrt jetzt die Entgegennahme eines anderen
Schl=FCssels. Warum allerdings nochmal versucht wird, einen Schl=FCssel a=
n
die Bank zu senden, verstehe ich nicht. Die richtige Vorgehensweise
ist jedenfalls die folgende:
- der HBCI-Zugang muss vollkommen "frisch" sein, d.h. es d=FCrfen nicht
bereits Schl=FCssel mit einer anderen Software hinterlegt worden sein
- beim erstmaligen Starten von InitAndTest wird als Passport-Datei=20
eine noch nicht existierende Datei angegeben; f=FCr diese werden
dann die Zugangsdaten erfragt. HBCI4Java erzeugt dann automatisch
die pers=F6nlichen Schl=FCssel und sendet den =F6ffentlichen Teil der
Schl=FCssel an die Bank
- danach bricht das Programm mit einer Fehlermeldung "es muss ein INI-
Brief erzeugt und an die Bank geschickt werden" ab.
- jetzt ist "java -cp ... org.kapott.hbci.tools.INILetter" an der
Reihe
- hier wird zun=E4chst der gleiche Passport-Typ (also sicher RDHNew),
dann der Dateiname der soeben erzeugten Passport-Datei und=20
schlie=DFlich der Dateiname einer noch nicht existierenden Datei
angegeben. In dieser zweiten Datei wird dann der INI-Brief als
ASCII-Text gespeichert, der ausgedruckt, unterschrieben und an
die Bank geschickt werden muss.
- Anschlie=DFend schaltet die Bank die mit InitAndTest eingereichten=20
Schl=FCssel frei. Danach kann InitAndTest beliebig oft erneut
ausgef=FChrt werden - jetzt existiert die Passport-Datei nat=FCrlich
schon, weshalb auch nicht mehr nach den einzelnen Zugangsdaten,=20
sondern nur nach dem Passwort gefragt wird.
...
Ich hoffe ich konnte soweit erst mal weiterhelfen. Falls Sie nicht
sicher sind, ob der HBCI-Zugang tats=E4chlich "frisch" ist --- die Banken
tun sich i.d.R. nicht allzuschwer damit, den Zugang wieder
zur=FCckzusetzen. Sie k=F6nnen mir auch gern die Logs von InitAndTest mit
Debug-Level 4 schicken (und evtl. vorher die "sensitiven" Informationen
aus-X-en), damit wir dem Problem auf die Spur kommen...
Viele 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
-------------------------------------------------------------------
|
|
From: Johann U. <joh...@xp...> - 2004-01-07 09:31:18
|
Hallo, noch relativ neu in Bezug auf hbci und hbci4java habe ich eine Frage zu Passports. Für einen Zugang zur HypoVereins-Bank habe ich versucht per InitAndTest und anschließend via INILetter einen Zugang zu bekommen. Jedoch bricht INILetter ab, da von der Bank folgender Fehler gemeldet wird: 9010 - Erstinitialisierung abgelehnt, zur Freigabe vorgemerkter Schlüssel vorhanden Bedeuted das, dass der Client-Key für den Passport von der Bank erzeugt wird? Falls ja, was ist dann der Inhalt des INI-Briefs und (wie) kann er mit hbci4java erstellt werden? Vielen Dank, Johann Uhrmann -- Johann Uhrmann xpecto AG | Lindenstrasse 81 | D-84030 Ergolding Telefon: 0700 xpecto 00 (0700 973286 00) Telefax: 0700 xpecto 10 (0700 973286 10) Internet: http://www.xpecto.com |
|
From: Stefan P. <kle...@gm...> - 2004-01-06 09:53:41
|
Hallo, gesundes neues Jahr euch allen... Der Server-Snapshot von heute ist jetzt auf den neuen Objekt-Pooling-Mechanismus im aktuellen HBCI4Java-Snapshot umgestellt, so dass die beiden aktuellsten Snapshots (beide 20040106) von HBCI4Java und HBCI4Java-Server jetzt wieder zusammen passen... Viele 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 ------------------------------------------------------------------- |
|
From: Stefan P. <kle...@gm...> - 2003-12-30 15:36:21
|
Hallo, zum wahrscheinlich letzten Mal in diesem Jahr habe ich einen neuen HBCI4Java-Snapshot bereitgestellt. Neben einigen gr=F6=DFeren internen =C4nderungen wurde auch das Bankleitzahlen- Verzeichnis aktualisiert. Au=DFerdem gibt es jetzt (rudiment=E4re) Unterst=FCtzung f=FCr die BIC-Codes der Banken. Marc: Du kannst das PIN/TAN-Zeugs jetzt nochmal testen, ich habe die Stelle evtl. gefixt (wenn meine Vermutung bzgl. der Fehlerursache =FCberhaupt richtig war). Eine Anmerkung noch: dieser Snapshot sollte *nicht* als HBCI4Java-Library f=FCr den HBCI4Java-Server verwendet werden, weil der Server-Code noch nicht auf den neuen Objekt-Pooling- Mechanismus in HBCI4Java angepasst ist und es somit schnell zur Speicherengp=E4ssen kommen d=FCrfte... Mit "normalen" HBCI-Client- Anwendungen kann dieser Snapshot aber schon mal getestet werden. Dann viele Gr=FC=DFe und die besten W=FCnsche f=FCr das n=E4chste Jahr (auch noch ein Schaltjahr --- ein Tag mehr Zeit f=FCr die Arbeit an HBCI4Java ;-) -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 ------------------------------------------------------------------- |
|
From: Stefan P. <kle...@gm...> - 2003-12-30 15:36:15
|
Hallo, zum wahrscheinlich letzten Mal in diesem Jahr habe ich einen neuen HBCI4Java-Snapshot bereitgestellt. Neben einigen gr=F6=DFeren internen =C4nderungen wurde auch das Bankleitzahlen- Verzeichnis aktualisiert. Au=DFerdem gibt es jetzt (rudiment=E4re) Unterst=FCtzung f=FCr die BIC-Codes der Banken. Marc: Du kannst das PIN/TAN-Zeugs jetzt nochmal testen, ich habe die Stelle evtl. gefixt (wenn meine Vermutung bzgl. der Fehlerursache =FCberhaupt richtig war). Eine Anmerkung noch: dieser Snapshot sollte *nicht* als HBCI4Java-Library f=FCr den HBCI4Java-Server verwendet werden, weil der Server-Code noch nicht auf den neuen Objekt-Pooling- Mechanismus in HBCI4Java angepasst ist und es somit schnell zur Speicherengp=E4ssen kommen d=FCrfte... Mit "normalen" HBCI-Client- Anwendungen kann dieser Snapshot aber schon mal getestet werden. Dann viele Gr=FC=DFe und die besten W=FCnsche f=FCr das n=E4chste Jahr (auch noch ein Schaltjahr -- ein Tag mehr Zeit f=FCr die Arbeit an HBCI4Java ;-) -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 ------------------------------------------------------------------- |
|
From: Stefan P. <kle...@gm...> - 2003-12-23 07:58:02
|
Hallo allerseits, neben einem neuen HBCI4Java-Snapshot gibt es die Weihnachts- Edition ;-) von HBCI4Java-Server 0.2.0. Bei dieser Version handelt es sich mehr oder weniger um das gleiche Server-Framework bzw. den Demo-Server, der auch Online als Testserver zur Verf=FCgung steht. Die entsprechenden Pakete k=F6nnen wie immer unter http://hbci4java.kapott.org/#download gezogen werden. Damit kann jetzt jeder der will seinen eigenen Testserver mit Bank-Backend, Web-Administrations-Interface usw. einrichten.=20 Nat=FCrlich arbeite ich selbst weiter daran. Ich w=FCnsche euch allen ein sch=F6nes erholsames Weihnachtsfest und 'nen guten Rutsch ins neue Jahr, falls wir uns bis dahin=20 nicht nochmal h=F6ren sollten. So long -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 ------------------------------------------------------------------- |
|
From: Stefan P. <kl...@ka...> - 2003-12-22 14:38:50
|
Hello, > > I think HBCIDialog.java(org.kapott.hbci.manager) plays a vital role > > in sending and recieving messages.But u havent mentioned that. > > > > Can u describe a little of HBCIDialog class? The class HBCIDialog is used *only* internally be the HBCI4Java library, *never* use it directly in an application! All classes and methods you are allowed to use in an application are described in the API documentation (the class HBCIDialog does not appear there, so dont use it). Regards -Stefan- -- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- |
|
From: Marc B. <ba...@ma...> - 2003-12-22 12:57:33
|
Hello, > I think HBCIDialog.java(org.kapott.hbci.manager) plays a vital role > in sending and recieving messages.But u havent mentioned that. > > Can u describe a little of HBCIDialog class? Sorry, I'm not that much into the code of hbci4java. I am using it from an application programmer's point of view. Please see what Stefan Palme (the author of hbci4java) replied on the mailing list: >hello, > >if you intend do use the provided high-level-api, see the >response from Marc Bantle (look in the sources of >org.kapott.hbci.tools.AnalyzeReportOfTransactions). All the HBCI >internal messages like dialog init and dialog end are created and >executed transparently by the HBCI4Java libraries. > >But if you want to make these "administrative" call manually >(e.g. making only a dialog init), I must disappoint you - HBCI4Java >is intended to provide a high-level API and does not allow executing >such lowlevel stuff manually. > >Best regards >-Stefan- > > > >>Hello, >>Can any one describe a java class that how to receive and send >>message(i.e a Dialog) from a HBCI client to HBCI server(in java). >>i.e 1.Dialog intialisation >>2.Dialog's work >>3.Dialog end >>Thanks in advance, >>sb. >> best regards, Marc |
|
From: Stefan P. <kle...@gm...> - 2003-12-20 21:19:26
|
Hallo, ich habe gerade einen Bug in einem der =E4ltesten Codeteile von HBCI4Java gefunden und beseitigt. Dieser Bug verursacht sehr sehr selten und sporadisch auftretende Fehler, die so aussahen, dass die Bank Nachrichten mit der Fehlermeldung "Fehler bei Entschl=FCsselung" abgelehnt hat. Beim n=E4chsten Versuch wurde die entsprechende Nachricht i.d.R. angenommen (so dass ich das bis jetzt immer auf ein Problem bei der=20 Bank geschoben habe --- Asche auf mein Haupt). Auf jeden Fall sollten sowohl die Anwender von HBCI4Java auf Client-Seite als auch diejenigen, die den HBCI4Java-Server bei sich einsetzen, den aktuellen Snapshot (20031220) installieren, da auch der HBCI4Java-Server die entsprechenden Funktionen aus der HBCI4Java-Bibliothek benutzt hat und somit ebenfalls u.U. fehlerhafte Nachrichten erzeugt. Sorry an all diejenigen, die diesen Fehler schon gemeldet haben, die ich aber an ihre jeweilige Bank verwiesen habe mit der Bitte, dort um Rat nachzufragen (*duck*). Kurz vor Weihnachten wird es =FCbrigens sehr wahrscheinlich die n=E4chste offizielle Release von HBCI4Java-Server geben, die dann in etwa der Version entsprechen wird, die bereits im Online- Betrieb als Testserver bereitsteht=20 (http://hbci4java.kapott.org/demoserver.html). Wer noch Bug-Reports oder W=FCnsche (gro=DFe oder kleine - schlie=DFlich ist bald Weihnachten) hat, der sollte sich also schnellstens bemerkbar machen... ;-) So long und viele 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 ------------------------------------------------------------------- |
|
From: Stefan P. <kl...@ka...> - 2003-12-19 16:14:38
|
hello, if you intend do use the provided high-level-api, see the response from Marc Bantle (look in the sources of org.kapott.hbci.tools.AnalyzeReportOfTransactions). All the HBCI internal messages like dialog init and dialog end are created and executed transparently by the HBCI4Java libraries. But if you want to make these "administrative" call manually (e.g. making only a dialog init), I must disappoint you - HBCI4Java is intended to provide a high-level API and does not allow executing such lowlevel stuff manually. Best regards -Stefan- > Hello, > Can any one describe a java class that how to receive and send > message(i.e a Dialog) from a HBCI client to HBCI server(in java). > i.e 1.Dialog intialisation > 2.Dialog's work > 3.Dialog end > Thanks in advance, > sb. -- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- |
|
From: Marc B. <ba...@ma...> - 2003-12-19 13:51:43
|
Hi, have a look at org.kapott.hbci.tools.AnalyzeReportOfTransactions. This is a nice little example of how to get account postings from your bank. Unfortuatelly comments are in German. 1.) Initialize hbci4java (HBCIUtils.init, AbstractHBCIPassport.getInstance, new HBCIHandler) 2.) Issue a request (hbciHandle.newJob, hbciHandle.addJob, hbciHandle.execute) 3.) and go through the postings recieved (auszug.getJobResult) Marc balu s meinte am 19.12.2003 11:52: > Hello, > Can any one describe a java class that how to receive and send > message(i.e a Dialog) from a HBCI client to HBCI server(in java). > i.e 1.Dialog intialisation > 2.Dialog's work > 3.Dialog end > Thanks in advance, > sb. > > > signature > > /S.Balu/ > /Trichy/ > ------------------------------------------------------------------------ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=21260/*http://photos.yahoo.com> |
|
From: balu s <bal...@ya...> - 2003-12-19 10:52:41
|
Hello, Can any one describe a java class that how to receive and send message(i.e a Dialog) from a HBCI client to HBCI server(in java). i.e 1.Dialog intialisation 2.Dialog's work 3.Dialog end Thanks in advance, sb. signature S.Balu Trichy --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing |
|
From: Marc B. <ba...@ma...> - 2003-12-13 12:17:21
|
Hallo Stefan, Stefan Palme meinte am 13.12.2003 10:57: >Meine Frage ist jetzt folgende: Da in der ~/.openhbci-Datei mehrere >HBCI-Zugänge gespeichert sein können, muss natürlich beim Initialisieren >eines Passports geklärt werden, *welcher* der Zugänge aus der >~/.openhbci verwendet werden sollen. Wie wird das in OpenHBCI erledigt? >Welche Angaben, die der Client machen muss, führen zu einer eindeutigen >Identifikation des zu verwendenden HBCI-Zugangs und damit zur zu >verwendenden Schlüsseldatei (wahrscheinlich Bankleitzahl und >Benutzerkennung, könnte ich mir vorstellen)? Genau diese Angaben würde >ich dann auch in HBCI4Java als Parameter verwenden, um die Informationen >für den gewünschten HBCI-Zugang aus der ~/.openhbci-Datei zu >extrahieren. > zu den Internas von openhbci kann ich dir leider nicht viel sagen. Ich weiß allerdings, dass ich bei aqmoney neben dem Pfad auf die .openhbci nur noch --institute (also BLZ) und --account (Kontonummer) angeben muß, um z.B. meine Kontoauszüge abzurufen . Den Rest zieht sich aqmoney aus der Datei .openhbci. Die anzugebende BLZ ist dabei die BLZ des Kontos (z.B. bank/1/account/0/params - institute), nicht die BLZ des Instituts, das den HBCI-Server stellt (z.b. bank/1/params - code), die nicht notwendigerweise die selbe ist. Grüße, Marc |
|
From: Stefan P. <kle...@gm...> - 2003-12-13 09:57:24
|
Mahlzeit, > Ich arbeite wie du wei=DFt mit OpenHBCI-Konfigurationen. Die > Konfigurationsdatei .openhbci > enth=E4lt alle notwendigen Informationen f=FCr die drei Konten, die ich > mit hbci4java warten will.=20 > Auch die Verweise auf die beiden Mediumdateien sind dort hinterlegt. > hbci4java holt sich > jedoch den Pfad auf die Mediumdatei aus der Configuration und nicht > aus .openhbci. Ich habe jetzt vor, HBCI4Java das OpenHBCI-Handling der Schl=FCsselmedien besser beizubringen als das derzeit gemacht wird. Im Moment wird beim Initialisieren eines OpenHBCI-Passports (=3D -Schl=FCsselmediums) sowohl der Dateiname der "Mediumdatei" (die die Schl=FCssel usw. enth=E4lt) als auch die ~/.openhbci-Datei ben=F6tigt, weil hier einige zus=E4tzliche Daten enthalten sind, die nicht in der Schl=FCsseldatei stehen. Nun steht aber in der ~/.openhbci-Datei der Name der Schl=FCsseldatei eh schon drin, so dass es eigentlich ausreichen w=FCrde, nur die ~/.openhbci-Datei f=FCr die Initialisierung von OpenHBCI-Passports zu verwenden. Meine Frage ist jetzt folgende: Da in der ~/.openhbci-Datei mehrere HBCI-Zug=E4nge gespeichert sein k=F6nnen, muss nat=FCrlich beim Initialis= ieren eines Passports gekl=E4rt werden, *welcher* der Zug=E4nge aus der ~/.openhbci verwendet werden sollen. Wie wird das in OpenHBCI erledigt? Welche Angaben, die der Client machen muss, f=FChren zu einer eindeutigen Identifikation des zu verwendenden HBCI-Zugangs und damit zur zu verwendenden Schl=FCsseldatei (wahrscheinlich Bankleitzahl und Benutzerkennung, k=F6nnte ich mir vorstellen)? Genau diese Angaben w=FCrd= e ich dann auch in HBCI4Java als Parameter verwenden, um die Informationen f=FCr den gew=FCnschten HBCI-Zugang aus der ~/.openhbci-Datei zu extrahieren. Viele 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 ------------------------------------------------------------------- |
|
From: Stefan P. <kle...@gm...> - 2003-12-12 09:37:57
|
Hallo,
> doch. Das entscheidende W=F6rtchen ist hier "hintereinander". Du
> kannst in einem Thread mit HBCIUtils.setParam(...) irgendwelche
> Parameter setzen, dann mit AbstractHBCIPassport.getPassport()
> und new HBCIHandler() einen HBCIHandler erzeugen und mit diesem
> dann Auftr=E4ge ausf=FChren (HBCIHandler.execute()). Wenn das beendet
> ist, kannst du mit HBCIUtils.setParam() wieder irgendwelche
> Kernel-Parameter =E4ndern, mit ...getPassport() und new HBCIHandler()
> einen neuen Handler erstellen usw. usf.
mir ist eingefallen, dass diese Vorgehensweise zwar m=F6glich, aber
doch schon sehr restriktiv ist. Es ist nat=FCrlich auch m=F6glich,
mehrere HBCIPassport- und damit auch mehrere HBCIHandler-Instanzen
gleichzeitig zur Verf=FCgung zu haben... Folgender Pseudo-Code w=E4re
also auch m=F6glich:
-----------------------
HBCIUtils.setParam("client.passport.RDH.filename","...");
...
HBCIPassport passport1=3DAbstractHBCIPassport.getInstance("RDH");
HBCIHandler handler1=3Dnew HBCIHandler(passport1,...);
HBCIUtils.setParam("client.passport.RDH.filename","...");
...
HBCIPassport passport2=3DAbstractHBCIPassport.getInstance("RDH");
HBCIHandler handler2=3Dnew HBCIHandler(passport1,...);
HBCIUtils.setParam("client.passport.OpenHBCI....","...");
...
HBCIPassport passport3=3DAbstractHBCIPassport.getInstance("OpenHBCI");
HBCIHandler handler3=3Dnew HBCIHandler(passport1,...);
...
HBCIJob job1=3Dhandler3.newJob("...");
job1.setParam(...);
...
HBCIJob job2=3Dhandler1.newJob("...");
...
handler1.execute();
handler2.execute();
...
handler3.execute();
...
-----------------------
usw. Das Prinzip sollte klar sein. Wichtig ist, dass die
"client.passport.*.*"-Kernel-Parameter nur beim *Erzeugen* eines
Passports (mit AbstractHBCIPassport.getInstance()) ausgewertet
werden. Eine =C4nderung dieser Parameter, nachdem einmal eine
Passport-Instanz da ist, =E4ndert diese Passport-Instanz nicht
mehr. Deshalb k=F6nnen mit obigem Code viele verschiedene Passport-
Instanzen im selben Thread erzeugt werden.
Einige andere Kernel-Parameter beeinflussen die Arbeit von HBCI4Java
allerdings direkt (z.B. "log.loglevel.default") - d.h. sie k=F6nnen
zur Laufzeit ge=E4ndert werden und =E4ndern damit auch sofort das
Log-Verhalten des HBCI-Kernels. Analoges gilt f=FCr die meisten anderen
Parameter.
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
-------------------------------------------------------------------
|
|
From: Stefan P. <kle...@gm...> - 2003-12-11 19:22:23
|
Hallo Marc, > Ratschlag zur Configuration >=20 > Ich arbeite wie du wei=DFt mit OpenHBCI-Konfigurationen. Die > Konfigurationsdatei .openhbci > enth=E4lt alle notwendigen Informationen f=FCr die drei Konten, die ich > mit hbci4java warten will.=20 > Auch die Verweise auf die beiden Mediumdateien sind dort hinterlegt. > hbci4java holt sich > jedoch den Pfad auf die Mediumdatei aus der Configuration und nicht > aus .openhbci. hmm, ja, das ist "historisch" bedingt, weil die erste Version von HBCIPassportOpenHBCI die Datei ~/.openhbci *=FCberhaupt nicht* ber=FCcksichtigt hatte. Das w=E4re aber in der Tat ein Punkt, den ich mal =E4ndern k=F6nnte... > Wenn ich das richtig interpretiere, habe ich keine Chance > einunddemselbem Thread=20 > hintereinander zwei verschiedene Konfigurationen unterzuscheiben. Da doch. Das entscheidende W=F6rtchen ist hier "hintereinander". Du kannst in einem Thread mit HBCIUtils.setParam(...) irgendwelche Parameter setzen, dann mit AbstractHBCIPassport.getPassport() und new HBCIHandler() einen HBCIHandler erzeugen und mit diesem dann Auftr=E4ge ausf=FChren (HBCIHandler.execute()). Wenn das beendet ist, kannst du mit HBCIUtils.setParam() wieder irgendwelche Kernel-Parameter =E4ndern, mit ...getPassport() und new HBCIHandler() einen neuen Handler erstellen usw. usf. Auf die Art und weise k=F6nntest Du sequenziell alle Deine Konten abfragen (die m=FCssten dazu nicht mal alle OpenHBCI-basiert sein). Wenn Du die Abfrage verschiedener Konten parallelisieren wolltest (also je Passport ein Parallel-Strang), dann m=FCsstest Du in der Tat f=FCr jedes Passport eine neue ThreadGroup erzeugen... Aber das war wohl das, was Du genau *nicht* machen wolltest...? > Liste der Banken > Woher beziehst Du die Bankenliste (blz.properties), die mit hbci4java > mitgeliefert > wird. Unter http://192.109.2.70/internet/bankleit.nsf kann man die > Banken > ja downloaden. Irgendwie ist mir nicht wohl dabei eine *.exe-Datei von > einem Server=20 > zu laden der nicht einmal im DNS rergistriert ist. > Kennst du eine Quelle im web, wo man eine Liste der existierenden > Banken abfragen=20 > kann, vielleicht sogar als xml? wenn das der Link zur Deutschen Bundesbank ist, dann benutze ich den auch :-) Die Sache mit der EXE-Datei ist kein Problem, unter Linux kann ich=20 diese EXE-Datei direkt mit UNZIP entpacken, wobei die Bankenliste sowie eine Word-Datei mit der Beschreibung des Dateiformates zutage tritt (kennst Du sicher schon). Die Frage nach der Vertrauensw=FCrdigkeit einer solchen Quelle habe ich der Bundesbank auch schon gestellt, aber von dort erh=E4lt man als Otto-Normalb=FCrger wohl keine Antwort (f=E4llt wohl unter das Bankgeheimnis... ;-)) Jedenfalls ist es genau diese Quelle, die die Grundlage f=FCr=20 blz.properties bildet (ich merke gerade, dass ich das letzte Update verschlafen habe....) Dann erst mal viele 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 ------------------------------------------------------------------- |
|
From: Marc B. <ba...@ma...> - 2003-12-11 18:11:50
|
<!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>
hbci4java-2.4.7pre-20031210 funktioniert prächtig. <br>
<br>
Jetzt möchte ich daran gehen, hbci2db (mein Programm zum Abziehen der
Buchungen <br>
in die Datenbank) so zu erweitern, dass ich in einem Programmlauf die
neuen Buchungen <br>
aller Konto (derzeit 3) aller Banken (derzeit 2) in die Datenbank
schreiben kann. Da ich <br>
das selbe Passwort für beide Mediendateien (eine pro Bank) verwende,
will ich dieses <br>
daher auch nur einmal eingeben.<br>
<br>
Das einheitliche Passwort kann ich durch einen geeigneten <tt>HBCICallback</tt>
übergeben.<br>
<br>
<b>Ratschlag zur Configuration</b><br>
<br>
Ich arbeite wie du weißt mit OpenHBCI-Konfigurationen. Die
Konfigurationsdatei <tt>.openhbci</tt> <br>
enthält alle notwendigen Informationen für die drei Konten, die ich mit
hbci4java warten will. <br>
Auch die Verweise auf die beiden Mediumdateien sind dort hinterlegt.
hbci4java holt sich<br>
jedoch den Pfad auf die Mediumdatei aus der Configuration und nicht aus <tt>.openhbci</tt>.<br>
<br>
Ich habe dazu <tt>README.OpenHBCI</tt> und das Konfigurationshandling
in <tt>HBCIUtils </tt>angesehen.<br>
Wenn ich das richtig interpretiere, habe ich keine Chance
einunddemselbem Thread <br>
hintereinander zwei verschiedene Konfigurationen unterzuscheiben. Da <tt>HBCIUtils</tt>
zudem <br>
noch final ist, kann ich auch <tt>getParam()</tt> nicht überschreiben
(' weiß garnicht, ob man in Java<br>
statische Methoden überschreiben kann). Muß ich also mit mehreren
Threads arbeiten um <br>
auf unterschiedliche Mediendateien zuzugreifen, oder gibt es eine
elegantere Methode?<br>
<br>
<b>Liste der Banken</b><br>
<br>
Für meine Datenbanklösung habe ich die Banken der Version 2.4.6 vorab
in die Tabelle <br>
Bank eingepflegt. Wenn eine neu Bank durch eine Buchung hinzukommt,
trage ich diese <br>
zusätzlich ein. Wenn hbci4java keine Bezeichnung liefert, weil sie in
blz.properties auch <br>
nicht existiert generiere ich eine Dummynamen aus dem Kontoinhaber. <br>
<br>
Woher beziehst Du die Bankenliste (blz.properties), die mit hbci4java
mitgeliefert<br>
wird. Unter <tt><a class="moz-txt-link-freetext" href="http://192.109.2.70/internet/bankleit.nsf">http://192.109.2.70/internet/bankleit.nsf</a></tt> kann man
die Banken<br>
ja downloaden. Irgendwie ist mir nicht wohl dabei eine *.exe-Datei von
einem Server <br>
zu laden der nicht einmal im DNS rergistriert ist.<br>
Kennst du eine Quelle im web, wo man eine Liste der existierenden
Banken abfragen <br>
kann, vielleicht sogar als xml?<br>
<br>
Vorab schon mal vielen Dank!<br>
Gruß, Marc<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
|
|
From: Marc B. <ba...@ma...> - 2003-12-10 19:26:17
|
Hallo, bin leider den ganzen Tag nicht am Netz gewesen. Stefan Palme meinte am 10.12.2003 11:48: >Dein anderes Problem mit den fehlerhaften Kontoauszügen 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... > Wo ich gerade gerade sowieso in den Sourcen war, habe ich mir selbst einen Workaround gebastelt - allerdings very dirty weil hardcoded. Konnte aber damit erstmals meine Buchungen sehen :-). tw...@im... meinte am 10.12.2003 12:56: >Netürlich synchronisierst du dich immer wieder und vermeidest so die grossen nachschleppefehler, aber selber richtig rechnen und runden iss besser als synchronisation (meine Meinung ;-)). > > Ich als "hbci4java-Anwender" (;-) sehe das richtig nachrechnen, also Saldieren der von der Bank gemeldeten Salden, eigentlich eher als klassische Aufgabe der Anwendung die hbci4java nutzt, weniger der hbci-Middleware (also hbci4java). Um Buchungssalden bereit zustellen, bleibt der Middleware allerdings nichts anderes als selbst zu rechnen: eine Art Komfort-API. Ich könnte auch gut mit dem GVRKUms.BTag-Interface mit "UmsLine"s ohne Saldo leben. Vorteil: weniger Redundanz. Nachteil: weniger Komfort. Stefan Palme meinte am 10.12.2003 14:45: >Marc: Dein Dresdner-Bank-Problem ist jetzt hoffentlich auch >erst mal behoben, ist aber ein eher nicht so schöner Workaround >(siehe dazu die API-Dokumentation zum Feld GVRKUms.BTag.my). > > So schlimm finde ich den Workaround jetzt nicht. Er ist allemal besser als die schäbigen hbci-Implementationen der Banken, die so etwas nötig machen. - Von meinem hardcoded-Workaround gar nicht zu reden :-) Vielen Dank auch Stefan, dass du das gleich mit eingebaut hast. Ich habe mir schon Gedanken gemach, wie ich meinen billigen Workaround über den nächsten Versionswechsel rette :-) Gruss, Marc |
|
From: Stefan P. <kle...@gm...> - 2003-12-10 14:05:50
|
hallo waffel, die EU-Richtlinie bzgl. runden muss ich eigentlich nicht=20 kennen/beachten, da ich von der Bank eh schon auf zwei Nachkomma- stellen "gerundete" Werte bekomme (und *niemals* mehr Nachkommastellen), und ich selbst auch keine Werte selbst "erzeuge", die irgendwie gerundet werden m=FCssten. Mein Problem ist nur gewesen, dass ich beim Addieren zweier solcher Werte (wobei nat=FCrlich wieder immer nur ein Wert mit max. zwei Nachkommastellen rauskommt) ab und zu Probleme mit der float-Genauigkeit von Java hatte. Deshalb werden diese Werte jetzt einfach in=20 Cent umgerechnet (--> mit Sicherheit keine Nachkommastellen mehr), als Long-Werte addiert und sp=E4ter bei Bedarf wieder in EURO zur=FCckge- rechnet. Mehr Rechenoperationen als diese eine Addition mache ich auch niemals. Das "Synchronisieren" mit der Bank k=F6nnte dabei auch komplett entfallen, weil ja die fortlaufende Addition der Buchungen auf diesem "sicheren" Weg mit Sicherheit das gleiche Ergebnis liefern sollte. Selbst wenn Ihr in eVerlage in MilliCent gerechnet habt, und dazu double (anstatt long) verwendet habt, h=E4tte es Probleme geben k=F6nnen, weil n=E4mlich double-Datentypen nur 15 signifikante Stellen sicher berechnet. Bei gro=DFen Zahlenwerten (das geht durch die Verwendung von MilliCent dann ja recht schnell) h=E4tte es also auch bei euch zu Rundungsproblemen kommen k=F6nnen. Die Flie=DFkommadarstellung von Zahlen ist keine "exakte" Darstellung,=20 sondern nur so eine Art "Rundung", mit der man nicht *beliebige*=20 rationale Zahlen darstellen kann. Das ist ungef=E4hr so, als h=E4ttest Du nur die uns bekannten Geldm=FCnzen in einer begrenzten Anzahl zur=20 Darstellung von Float-Werten zur Verf=FCgung. 1 Million EURO k=F6nnte man leicht darstellen durch einmal 1 EURO und das ganze dann um ein paar Zehnerpotenzen verschoben (die Verschiebung um Zehnerpotenzen gibt es zus=E4tzlich zu den "M=FCnzen"). Auch 0.000000045 EURO kann man leicht darstellen, z.B. durch 2 EURO-M=FCnzen und eine 50-CENT-M=FCnze, das ganze dann addiert und wieder um ein paar Zehnerpotenzen verschoben. Aber bei 123456789 oder 0.7654321 (also bei Zahlen mit vielen=20 *signifikanten* Ziffern) gibt es Probleme, weil du nicht so viele M=FCnzen hast wie Du dazu br=E4uchtest (Du darfst z.B. immer max. 5 M=FCn= zen und die Zehnerpotenz-Verschiebung f=FCr die Darstellung der Zahlen verwenden - dann gehen die beiden ersten Beispiele nat=FCrlich, aber die beiden letzten nicht mehr). Analog ist das bei float- und double-Werten, nur dass hier nicht=20 mit Zehner-, sondern mit Zweierpotenzen gearbeitet wird. Und ob Du float- oder double verwendest, ver=E4ndert nur die "maximale Anzahl M=FCnzen", die Du verwenden darfst, und die maximale Zehner- (bzw.=20 Zweier-)Potenz, um die Du den Betrag verschieben darfst. Wie auch immer, danke f=FCr den Hinweis (vielleicht brauch ich ihn ja doch nochmal)... Gr=FC=DFe -Stefan- > Hallo, >=20 > Stefan ... das Problem hatte ich doch auch schon in everlage. Es gibt d= a eine EU-Richtlinie, wie zu runden ist ect. Aus diesem Grunde habe ich d= amals alles nicht nur auf Cent umgestellt und damit gerechnet, sondern mu= sste auch noch Millicent nehmen, denn nur dann kann man die EU-Richtlinie= erf=FCllen. Miliicent gehen dann aber mit double-werten auf jeden Fall, = wir hatten da ja verschiedene Betrachtungen und Tests gemacht. Net=FCrlic= h synchronisierst du dich immer wieder und vermeidest so die grossen nach= schleppefehler, aber selber richtig rechnen und runden iss besser als syn= chronisation (meine Meinung ;-)). >=20 > Viele Gr=FCsse >=20 > Waffel >=20 > >=20 > > Hallo Marc, > >=20 > > 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. > >=20 > > Die Fehlerursache war die Verwendung von float-Datentypen. Diese habe= n > > 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. > >=20 > > 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... > >=20 > > Danke nochmal f=FCr die Unterst=FCtzung > >=20 > > Viele Gr=FC=DFe > > -Stefan- > >=20 >=20 >=20 > -------- SIgnature -------- > Thomas Wabner > wissenschaftlicher Mitarbeiter > Karl-Liebknechtstrasse 145 > 04277 Leipzig > HTWK Leipzig >=20 > --------------------------- > Thomas Wabner > CIO > Ancoso Development GMBH >=20 > --------------------------- > PGP Key: > http://search.keyserver.net:11371/pks/lookup?op=3Dget&search=3D0x486817= 15&template=3Dnetenextract,netennomatch,netenerror >=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=1278&alloc_id371&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 ------------------------------------------------------------------- |
|
From: Stefan P. <kle...@gm...> - 2003-12-10 13:45:21
|
Hallo, es ist ein neuer Snapshot von HBCI4Java verf=FCgbar, bei dem vor allem Probleme bei der Salden-Berechnung beim Abrufen von Kontoausz=FCgen gefixt wurden. Marc: Dein Dresdner-Bank-Problem ist jetzt hoffentlich auch erst mal behoben, ist aber ein eher nicht so sch=F6ner Workaround (siehe dazu die API-Dokumentation zum Feld GVRKUms.BTag.my). Au=DFerdem wurde der online-HBCI4Java-Server wieder aktualisiert, er beherrscht jetzt auch die Doppeleinreichungskontrolle f=FCr Signatur-IDs. 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 ------------------------------------------------------------------- |
|
From: <tw...@im...> - 2003-12-10 11:55:53
|
Hallo, Stefan ... das Problem hatte ich doch auch schon in everlage. Es gibt da e= ine EU-Richtlinie, wie zu runden ist ect. Aus diesem Grunde habe ich damal= s alles nicht nur auf Cent umgestellt und damit gerechnet, sondern musste a= uch noch Millicent nehmen, denn nur dann kann man die EU-Richtlinie erf=FC= llen. Miliicent gehen dann aber mit double-werten auf jeden Fall, wir hatt= en da ja verschiedene Betrachtungen und Tests gemacht. Net=FCrlich synchro= nisierst du dich immer wieder und vermeidest so die grossen nachschleppefe= hler, aber selber richtig rechnen und runden iss besser als synchronisatio= n (meine Meinung ;-)). Viele Gr=FCsse Waffel >=20 > Hallo Marc, >=20 > 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. >=20 > 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. >=20 > 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... >=20 > Danke nochmal f=FCr die Unterst=FCtzung >=20 > Viele Gr=FC=DFe > -Stefan- >=20 -------- SIgnature -------- Thomas Wabner wissenschaftlicher Mitarbeiter Karl-Liebknechtstrasse 145 04277 Leipzig HTWK Leipzig --------------------------- Thomas Wabner CIO Ancoso Development GMBH --------------------------- PGP Key: http://search.keyserver.net:11371/pks/lookup?op=3Dget&search=3D0x48681715&= template=3Dnetenextract,netennomatch,netenerror |
23 messages has been excluded from this view by a project administrator.
