ofxdirectconnect in aqbanking3 branch
aquamaniac at gmx.de
Wed Jul 9 18:09:38 EDT 2008
On Mittwoch, 9. Juli 2008, Martin Preuss wrote:
> On Mittwoch, 9. Juli 2008, Jerry Jaskierny wrote:
> Since GnuCash is directly looking for an AccountInfo object for the
> expected account number (in this example "xxxxx1234") it doesn't succeed.
Being finally able to compile GnuCash again (thanks for the hints!!) I had a
look at that particular code and I see a general problem.
The code only looks for a particular account in the data returned (namely the
one it requested statements for). However, this doesn't always work as one
Some banking protocols do not allow to request statements for a specific
account but rather for all accounts a given user is authorized for (e.g. to
some extend EBICS, but certainly YellowNet).
That was the reason to begin with for AqBanking not to return the requested
data with the job structure but rather let the protocol backend gather all
received data in those ImExporterContexts.
This isn't just a problem of not reading superflous data: Some protocols
(especially YellowNet, but EBICS as well) allow the server to physically
remove data reported to the client, so data you loose in gnc-ab-gettrans.c
will most certainly be lost for good. This most likely isn't what the caller
intented when he requested statements...
So what I propose is this: You must already have a generic import/export
interface which is able to import data from an AB_IMEXPORTER_CONTEXT, since
you have an importer for SWIFT MT94x, so why not use this interface to import
the data returned? For HBCI it makes no difference, but the other protocols
can then also be safely used with GnuCash.
"Things are only impossible until they're not"
Martin Preuss - http://www.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/
More information about the gnucash-devel