Help with OFX in Gnucash

[David Carlson]

On 7/11/2012 1:50 PM, Benoit Grégoire wrote:
> On July 10, 2012 05:32:54 PM Ngewi Fet wrote:
>> Yes, there is:
>> http://lists.gnucash.org/pipermail/gnucash-devel/2012-April/033857.html
>> At the beginning of this project, consensus on this mailing list was that
>> OFX is a better idea
>> than QIF.
> Well, OFX is a half competent (by banking standards...) and fully specified way 
> of modeling banking transaction.
>
> Unfortunately, unlike QIF it does not even try to model an accounting storage 
> system.  So qif has a bit less of an impedence mismatch with what you are 
> doing, and is simpler.
>
> Whatever you do you'll have to make some changes in gnucash's import system 
> for a good user experience.  Offhand, either:
>
> You use OFX in which case for a goood experience you'll probably need to: 
> * Support explicit OFX transfer between accounts (even libofx doesn't have 
> support yet I believe, I could help you with the libofx part).  That's the 
> only mecanism in OFX to explicitely model where the money is going.  
> Unfortunately, it doesn't allow modeling a transaction involving more than two 
> account (cash, expense and taxes for example).
> * Support an account having multiple ids (and a simple gui to manage it).  
> Note that the account id can be any 22 caracters,and are displayed to the user 
> at account matching, so there is nothing stopping you from having them 
> meaningfull in you mobile app, as long as they no longer change once defined.
>
> You use QIF in which case for a goood experience you'll probably need to:
> * Extend the format (and importer)  to add a transaction identifier, otherwise 
> you are going to have a real painfull user experience.
>

Benoit Grégoire, you are putting an electrical engineering term to good
use when you refer to an impedance mismatch.  I concur wholeheartedly. 
I would personally view a smartphone ap as an attempt to be a very
sophisticated yet user friendly way to create an input data entry file
for GnuCash.  It would certainly be difficult for users to maintain a
full copy of their chart of accounts in such an ap.  Thus it may be
necessary for the gui to 'wear blinders' and deal with only one or a
very small number of source accounts and destination accounts at a
time.  In fact, it may also be necessary to output a separate file for
each source account that the ap purports to work with.
To me, your suggestions appear to be 'right on the money'.

David C



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20120711/14c59fee/attachment.bin>