On May 12, 2006, at 3:38 AM, Christian Stimming wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi David,
David Reiser schrieb:
The more obvious problem with the null bankID institutions is that
you
can't use the "Select the Bank for this User" dialog in aqbanking
setup
to get the necessary connection data for the affected OFX
institutions.
well, that particular dialog probably needs to be fixed. It sounds
as if
there is some segfault if no bankid was entered -- maybe you can
collect
and report a back trace?
Something less than a segfault, as aqbanking is still running and
usable, the new user definition just disappears. I'll see if I can
trap it with gdb.
But the real problem is somewhere else:
How big is the performance penalty for using bankID+bankName as the
internal aqbanking index key for the bank data? I'd really like to
see
it be possible to have a null bankID because Vanguard refuses
connections if it gets any incorrect data in the ofx connect request.
I understand why you would like to have that. However, this is
where it
hits the limits of a protocol-abstraction layer like aqbanking: For
the
first important protocol (HBCI), using "bankID+bankName" as an
index key
is plain wrong! Instead, HBCI explicitly specifies bankID (well, plus
country code) and *only* this as index key for a bank. If we add the
bankName, we will run into all kinds of trouble because the user might
enter the bankName in whatever different way it ever occurs to him. So
for HBCI, one *must* use only the bankID as the index key --
everything
else will fail miserably.
This is the explanation why the aqbanking protocol-abstraction still
assumes the bankID as unique index key. If I understand you correctly,
then in OFX we should not rely on this assumption anymore. Do the OFX
specifications actually define a clear index key of the bank? (I have
never worked with the OFX specs; I only know the HBCI ones.) I find it
hard to believe the specs don't define something like this.
I'm with you on this, but if such an index is specified, either it
has changed or the banks aren't following it uniformly (or maybe
Microsoft, the source of the numerically labelled xml files I use via
Jeremy Jongsma, has an inconsistency in their data set). There are a
few non-numeric FID's in the current data set, and FIPID's seem
sparser than I would expect. My guess is that there was some
uncertainty in early adopters, the committee has recommended that
FIPID's be the definitive identifier, but not all banks/institutions
have made the changes. Many banks do use the RTN both as the bankId
and either the FID or FIPID. grumble, grumble. The other possibility
is that the 'banks' ARE following a standard, but credit card
companies and investment institutions haven't figured it out yet.
For a while I thought about the possibility of generating an ID
for OFX
institutions that lacked them. But that gets ugly very fast: neither
aux1 nor aux1+aux2 is unique in the current data set. aux1+bankName
might be, but that's still ugly.
In any case we need some unique index key throughout the aqbanking
library, and because of the historical HBCI background, this
happens to
be the bankID (plus country code). If OFX requires something else as
identification, then we have two choices:
1. Change the unique index key of the banks in aqbanking, and make the
bankID field optional as seems to be appropriate for OFX (but not for
HBCI, as explained above)
2. Change the interpretation of the bankID field in the OFX
backend, but
still use it as the unique index key for aqbanking. In other words,
the
bankId should not be transmitted to the OFX server but still be used
inside aqbanking.
Clearly #2 is the much easier solution here... wait a sec: If you look
into src\plugins\backends\aqofxconnect\plugin\context.c and search
for
"BankCode", you will encounter this comment:
/* only copy bank id if it is a number (-> routing number)
* otherwise it serves only identification purposes for this backend
* and doesn't represent a routing number */
Can you try to enter a bankId whose first character is a letter
instead
of a digit? :-)
I can define a bank for a user this way, but it is all manual (can't
use Select the Bank for this User), and I'm forced to look through
banks.data in an external text editor to determine the ofx server
address.
Martin's response regarding new libofx code is probably the right
answer to the fill-in-the-server-address issue.
I'll dig some more, but I'm getting more sure that the ofx backend
isn't handling the return data as smoothly as it should. I'll collect
the Sending and Receiving headers from all my accounts. The backend
parser is expecting to use the bankId as the identifier, but ofx
institutions without RTN's are sending either FID or FIPID from the
ofx spec. That's when Qbankmanager is saying "Please choose an
account to use for this retrieval" and gnucash-hbci is claiming no
transactions within the date range.
Regards,
Christian
--
David Reiser
[EMAIL PROTECTED]
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Aqbanking-devel mailing list
Aqbanking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
