ofxdirectconnect in aqbanking3 branch

[Martin Preuss]

Hi,

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 
would expect.

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.


Regards
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/