ofxdirectconnect in aqbanking3 branch
andi5.py at gmx.net
Fri Jul 11 17:37:28 EDT 2008
On Do, 2008-07-10 at 00:09 +0200, Martin Preuss wrote:
> 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.
I suppose this only concerns the fetching of transactions, not balances,
I will take look at this issue this weekend. Thanks!
BTW, I followed
http://email@example.com/msg00945.html , even though you said that was not your recommended solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080711/181d8ea5/attachment.bin
More information about the gnucash-devel