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
0xDC7C8BF3.asc
Description: application/pgp-keys
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
