Moin, On Mittwoch, 26. März 2008, Thomas Baumgart wrote: > On Wednesday 26 March 2008 07:16:11 Martin Preuss wrote: [...] > Es wäre daher sinnvoll, mal darüber nachzudenken, eine Referenz auf das > Konto in den ACCOUNTINFO Teil mit aufzunehmen, denn für das Absenden eines > Auftrages muss ich ja ein Konto angeben (soweit ich das verstanden habe). [...]
Aber woher soll die denn stammen? Wenn die nicht von der Bank gesendet wird oder ohnehin schon in der zu importierenden Datei steckt, kann die von AqBanking gar nicht beigebracht werden. Der Hintergrund der Einfuehrung war folgender: Manche Protokolle senden auf die Anfrage nach bestimmten Daten eines bestimmten Kontos auch Ergebnisse fuer andere Konten (z.B. yellownet). Das liegt im Protokoll begruendet. Die Anwendung kann diese zusaetzlichen Infos ja ignorieren, aber AqBanking darf das nicht, weil bei solchen Backends - wie eben YellowNet - die Daten nach Abruf und Bestaetigung unwiderbringlich weg sind. Und z.B. bei YellowNet sind es nicht nur die angeforderten Bankdaten (Saldo oder Umsaetze), sondern z.B. Saldo *und* Umsaetze. Das laesst sich mit den Jobs nicht mehr abbilden, weil dann ein Job-Bearbeiter darauf gefasst sein muesste, hier auch andere Daten zu bearbeiten. Wenn das aber so ist, ist es sinnvoller, diese Daten gleich ganz in einen IMEXPORTER_CONTEXT zu stecken. Damit sind klare Verhaeltnisse geschaffen und die Anwendung braucht nur noch *eine* Funktion zum Importieren von Daten aus Dateien oder von Banken abgerufen. Das hat zudem den Vorteil, dass es leicht erweiterbar ist. Beispielsweise werden inzwischen auch die von HBCI-Servern manchmal gesendeten Bankmitteilungen beim Abruf im IMEXPORTER_CONTEXT abgelegt. Diese Infos liessen sich beispielsweise ueberhaupt keinem Job zuordnen, weil die von der Bank waehrend des Dialogaufbaus unvorhehrbar gesendet werden und nicht nachtraeglich wieder abgerufen werden koennen. Es fuehrt also kein Weg vorbei an dem aktuellen Design, und es hat sich inzwischen auch bewaehrt. Du musst daher leider damit leben, dass Du die zwei "String" parsen musst. Aber mal ehrlich: Bankleitzahl und Kontonummer... Bisher kommen alle Anwendungen - incl. KMyMoney - damit klar. Wenn Du Infos zu einem Konto abrufen willst, musst Du doch ohnehin beides wissen (bzw. die Anwendung muss das), d.h. diese Infos liegen vor. Und da die Kombination aus Bankleitzahl und Kontonummer pro Land unique sind (und es selbst andernfalls ein riesiger Zufall waere, wenn ein Kunde zweimal die gleiche Kombination haette), gibt es da nicht einmal Verwechselungsprobleme... [...] > Solange ich nur einen einzigen Job ausführe ist das alles kein Problem, > wenn aber in der Jobqueue mehrere Jobs liegen (womöglich noch für > unterschiedliche Banken/Konten) dann wird es knifflig aus dem > ImporterContext die Daten herauszufischen. Ich halte i.d.R. nix davon, > Strings zu parsen, wenn man eine ID (AqBanking oder applikationsspezifisch) > relativ einfach transportieren kann. [...] Ist es wie gesagt nicht. Du musste beide Daten zur Hand haben (bzw. die Anwendung). Und beides sind doch keine wilden "Strings", sondern IDs mit (z.B. in DE: festgelegtem) Format. Da gibt es also keinen grossen Interpretations-Spielraum... [...] > > Bei den HBCI-Zugaengen solltest Du aber in den meisten Faellen im > > ACCOUNTINFO die Bankleitzahl und Kontonummer finden, und anhand dieser > > kannst Du eine Zuordnung vornehmen. > > Ja, das ist klar, aber fehleranfällig, wenn die Information nicht oder nur > unvollständig in der Applikation vorliegt. [...] Das waere dann aber ein Fehler in der Anwendung: Denn wie gesagt *muss* die Anwendung - bzw. AqBanking - ja diese Informationen in jedem Fall haben, wenn ein Job ausgefuehrt werden soll. Du musst sogar darauf gefasst sein, dass diese Infos beim Importieren einer Datei fehlen (wenn Du da - wie QBankManager auch - die gleichen Routinen verwendest zum Importieren). Dann hast Du einen ACCOUNTINFO, der keine Bankleitzahl hat, aber dafuer etwas anderes (z.B. nur die Kontonummer, oder den Kontonamen, alles Felder im ACCOUNTINFO). Wenn naemlich diese Infos in der Datei nicht anders vorhanden sind, kann AqBanking sie auch nicht synthetisieren. D.h. Dein Importer muss da ohnehin locker sein... In QBankManager suche ich beispielsweise als erstes nach dem Konto (mit den verfuegbaren Angaben), und wenn es nicht gefunden wird, frage ich, welches vorhandene Konto eventuell gemeint ist, oder ob er Benutzer ein neues Konto anlegen will. Man koennte sich dann in der Anwendung diese Zuordnung merken. Das hat sich inzwischen ebenfalls gut bewaehrt. Gruss Martin -- "Things are only impossible until they're not" Martin Preuss - http://www.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
