Re: Small bug fix

On Saturday 29 November 2003 13:02, Stephen wrote:
> Hi,
>
> I have been experimenting with libofx and GNUCash to try and load
> statements from an online broker account. One of the statements caused
> the program to hang, and the same happened on running ofxdump on the
> same statement. This appears to be caused by code in
> ofx_container_transaction.cpp which steps up through parent elements to
> find a STATEMENT element. The code was caught in a loop, it always took
> the parent of the same container instead of looping through all parents.
>
> diff ofx_container_transaction.cpp
> ../../libofx_cvs/libofx/lib/ofx_container_transaction.cpp
> 46,47c46
> <       tmp_parentcontainer=tmp_parentcontainer->parentcontainer;
> <
> ---
>
>  >       tmp_parentcontainer=parentcontainer->parentcontainer;

Thanks for the catch and sorry for the delay.  Now applied in CVS.

> I still have some problems with the import, commisions are not brought
> into gnucash for example, and ofxdump gives many errors along the lines of:
> LibOFX ERROR: WRITEME: COMMISSION (1) is not supported by the INVESTMENT
> container
> If it would be useful I can post a more complete bug report and a
> cleaned version of the .ofx file, once I have a chance to find and
> remove private info from it.

Well, that is what WRITEME's are for ;)  Support for the comission element is 
indeed unimplemented in the investment container.  Comissions and other fees 
are annoying to integrate to the data model since they either increase the 
cost or decrease the revenue of the transaction.  But you must still be able 
to tell the "theorical" cost of each share.  What would probably be best is 
to expose an element called transaction_cost in which we could put all the 
various fees of the transaction.  The client could then either note it as a 
separate expense transaction (probably best), or make it part of the price.

> I am a bit hazy on which areas GnuCash, libofx and OpenSP are
> responsible for when imprting a file. I take it OpenSP just gives a list
> of tags which match the provided DTD. But if an element isn't recognized

Correct

> in LibOFX, does it just have to be added to the library, or does GnuCash
> have to be changed too to use the new tags? And is libofx supposed to

Depends on what the element means.  The ultimate goal of LibOFX is to abstract 
much of the complexity of OFX from the client, in this case GnuCash.  If the 
data model has to be extended to allow for an element, then yes GnuCash's ofx 
module must also be modified.  If we were to just substract the comission to 
the globas price of the transaction, GnuCash wouldn't have to be modified.  
However, if we want to 

> support brokerage imports at all, or only personal banking accounts?

It supports brokerage imports, but I have no such accounts and I wrote all the 
support for it, it's surprisingly stable, but as I didn't get much feedback 
so I didn't enhance it much.

I am extremely busy right now, but I'll still be happy to handhold you (and 
even code some of it) if you are willing to work on it.  There is probably 
less than a half day of actual work in what you want, but you'll have to 
modify both gnucash and libofx.

-- 
Benoit Grégoire, http://step.polymtl.ca/~bock/


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click