OFX Investment Import

[Christian Stimming]

Am Donnerstag, 14. Dezember 2006 20:39 schrieb Hubert Bahr:
>> That's http://bugzilla.gnome.org/show_bug.cgi?id=385366
>
>> Can you please explain now more clearly which parts of your test file
>> are imported correctly, and which parts are erroneous or missing data?
>
>  An enlightening challenge.  It turns out OFX investment import works
> sometime.  It is very sensitive to the creation of the transaction account
> and the commodity accounts.  Using previously established accounts
> definitely doesn't work.  I have best results when creating the accounts
> and commodities from scratch on an initial import of the file.  

This is indeed *very* strange. I have never used the OFX import in detail, 
though; I only use the HBCI transaction import and these are always quite 
simple. (No account creation involved etc.)

> However, 
> that seems to work in varying degrees depending on structure.  I am still
> trying to document the differences, but in my opinion it is hyper-sensitive
> to this situation and needs to be desensitized.  

Absolutely agreed.

> One problem is, there 
> seems to be no way to clear the previously learned connections between the
> accounts without deleting the accounts.  This is a real pain when you
> started the account using one method and then try to change to a new
> strategy especially when the new method doesn't provide all the data.  If
> we only had an ofx export that might help.  Once, I understand the
> differences, I will collect individual account structures and example ofx
> files.
>
>  Where does the account mapping occur, and how is it saved?

In OFX every element has an <UNIQUEID>. This character sequence is stored in 
gnucash's accounts and/or imported transactions in their "kvp" structure 
under "ofx" or "online_id", or "ofx/associated-income-account".

If you gunzip your gnucash data file and open it in a text editor, you will 
find that each account and transaction has some XML elements under <slot>; 
this kvp (key-value-pair) slots are our mechanism to dynamically add data to 
almost any gnucash object. In this case, the kvp is used to store the 
UNIQUEID from the ofx import.

Concerning that the matching accounts cannot be changed later: That has been a 
RFE for a long time now, http://bugzilla.gnome.org/show_bug.cgi?id=98963 but 
it still isn't there. Sorry for that.

Currently you can either edit your gnucash data file and remove the slot 
values (simply replace the <value>...</value> part by <value></value>), or 
alternatively you could modify the UNIQUEID fields in your OFX file so that 
the next import will not see a matching UNIQUEID again. 

>> Also, do you work with SVN-trunk source code for this? I hope so.
>
>  I am working with the SVN-trunk and also comparing to a previous release. 
> How often do I need to update?

That's fine; I just wanted to make sure you don't accidentally work with very 
old code. In my case, I run a "svn update" daily before I start to work. But 
your concerned part of the gnucash code isn't under active development by 
anyone else anyway, so it probably doesn't matter whether you updated daily 
or only after a few days. Note that if you supply a patch (use "svn diff"), 
you should give us the revision number of SVN that the patch was created 
against (see "svn info").

All the best,

Christian