Online OFX import of Investment Statements

[Stephen R. Besch]

Martin,

The problem s that when an OFX stock transaction is included in the 
transaction list, it gets treated by GnuCash like a cash transaction, 
even though it is marked as a stock and has all the transaction data in 
the correct places in the transaction record (CUSIP, Shares, Trade 
Price, Trade Date). Here is an example of an OFX stock transaction taken 
from an <INVTRANLIST> group:

<BUYSTOCK>
 <INVBUY>
   <INVTRAN>
      <FITID>4851010688</FITID>
      <DTTRADE>20090414121522</DTTRADE>
      <MEMO>BUY TRADE</MEMO>
   </INVTRAN>
   <SECID>
     <UNIQUEID>172967101</UNIQUEID>
     <UNIQUEIDTYPE>CUSIP</UNIQUEIDTYPE>
   </SECID>
   <UNITS>50</UNITS>
   <UNITPRICE>4</UNITPRICE>
   <COMMISSION>9.99</COMMISSION>
   <TOTAL>-209.99</TOTAL>
   <SUBACCTSEC>CASH</SUBACCTSEC>
   <SUBACCTFUND>CASH</SUBACCTFUND>
 </INVBUY>
 <BUYTYPE>BUY</BUYTYPE>
</BUYSTOCK>

This would be one of several stock and income items. The stock's ticker 
symbol is passed later as a <STOCKINFO> group in the <SECLIST>...</SECLIST>:

<STOCKINFO>
  <SECINFO>
   <SECID>
    <UNIQUEID>172967101</UNIQUEID>
    <UNIQUEIDTYPE>CUSIP</UNIQUEIDTYPE>
   </SECID>
   <SECNAME>CITIGROUP INC COM</SECNAME>
   <TICKER>C</TICKER>
  </SECINFO>
</STOCKINFO>

The two lists need to be correlated after both are received - I've 
already written code to do this (mostly), but no matter how I construct 
the list(s) to send back to GnuCash, the result is that the stocks get 
treated as cash. On the other hand, if I take the same OFX file and 
import it with File->Import->OFX/QFX..., it works perfectly: The stocks 
are identified and assigned to specific stock accounts in GnuCash.  If I 
could figure out how to construct the list passed back from aqbanking to 
do the same thing as the OFX passed through libofx, I would be happy to 
implement it.

By the way, I do appreciate your slant on the issue of taking the 
aqbanking parser out of the loop - especially if libofx has issues. 
After all, I've spent several weeks studying the aqbanking code base and 
learning to write parser code - this was my first choice too. I just 
couldn't get any tangible help, so I worked out an alternative 
strategy.  However, using aqbanking as the bank account data base 
manager and permitting the caller to use their own parser might also be 
considered an enhancement by some. In fact, it would be possible to do 
this already by using the /tmp/ofx.log -it's just that it's not as 
elegant and straightforward.

Martin Preuss wrote:
> Hi,
>
>
> On Freitag, 5. Juni 2009, Stephen R. Besch wrote:
> [...]
> > Lastly, I've also tried to get the investment part of aqbanking working.
> > In fact, I've submitted quite a bit of code that succesfully imports
> > everything in the investment transaction list except stock transactions
> > (i.e, dividends and cash transactions work). The problem is that getting
> > the stock stuff to work is a great deal more difficult - in fact no one
> > would even offer any help at all regarding the next steps that I might
> > take. This patch is so simple that it's hard for me to justify investing
> > the time to duplicate the effort that's already been put into the
> > investment import that the File->Import->OFX/QFX... function provides.
> [...]
>
>
> I can understand that you consider that matter closed by your patches, 
> especially if that works for your use cases.
>
>
> However, what you are doing is to take out the OFX parser of AqBanking 
> out of the loop. I guess you can appreciate that this is from 
> AqBanking's viewpoint not the desired way to go ;-)
>
>
> So what I would be interested in is to have AqBanking's importer do 
> what you need it to. On the other hand I have neither investment data 
> to work on nor an idea of what exactly it is that AqBanking is missing.
>
>
> If this problem could be solved within AqBanking's importer it would 
> automatically help other applications as well so it might be worth 
> working on. Especially since the LibOFX library used by GnuCash has 
> some very important limitations (e.g. it simply bails out with a 
> segmentation fault if lines become to long).
>
>
>
> Regards
> Martin
>
>
>
> -- 
> "Things are only impossible until they're not"
>
>
> Martin Preuss - http://www2.aquamaniac.de/
> AqBanking - http://www.aqbanking.de/
> LibChipcard - http://www.libchipcard.de/
>
>