Re: Interfacing with online bank.
On Fri, 21 Jul 2000, Keith Refson wrote: > One of the UK banks (which I am considering switching my accounts to > -- hence the message) offers the option to interface with Microsoft > Money. There is apparently no obvious or straightforward way to > download a QIF file (as allowed by my current poor service, poor > value hight-street bank) as the process is apparently entirely managed > by the Microsoft program. > > Is there any way that gnucash can interface with such a system? Perhaps. The biggest problem would be getting the protocol that they use. I think that they also use identification certificates that are not available to us. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Interfacing with online bank.
On Fri, Jul 21, 2000 at 06:39:49PM +0100, Keith Refson wrote: > > One of the UK banks (which I am considering switching my accounts to > -- hence the message) offers the option to interface with Microsoft > Money. There is apparently no obvious or straightforward way to > download a QIF file (as allowed by my current poor service, poor > value hight-street bank) as the process is apparently entirely managed > by the Microsoft program. > > Is there any way that gnucash can interface with such a system? > Most browsers have a way of forcing a link to download to a file. In Netscape you hold when clicking on the link. Works with my bank. -- James (Jay) Treacy [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
error writing file
found this interesting error: 1. start gnucash 2. open an account - so far I have confirmed this with bank and credit accounts 3. start entering a new transaction's description, but don't hit "enter" 4. cancel the transaction 5. try to exit gnucash you should get something to the likes of "error writing to file, invalid transaction" I can't remember if that's the exact text.. but anyways, gnucash then pops up a save dialog for you to enter a new filename to save as.. of course, no changes have been made, thus I cancel it.. running the latest cvs under RH6.2 -e -- Ed Porras [EMAIL PROTECTED] http://www.cise.ufl.edu/~ep ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
On Fri, 21 Jul 2000, Rob Walker wrote: > I have 3 1/2 years of > data there, will it create these new accounts for me as it goes when > it encounters my new categories while I do my imports? Fundamentally, yes. The procedure works best if you have exported all of the data for another set of books such as Quicken. The import is in two phases. In the first phase, the files to be imported are examined and gnucash builds a working "dictionary" that tells it how to translate from Quicken Accounts and Categories to Gnucash Ledger Accounts. The user is given an opportunity to edit this translation dictionary before the second phase when the actual import is performed. The system works very well with well formed QIF files and most files that were generated by programs which come close to meeting the spec. We are interested in any failures encountered so that we can develop appropriate corrections and/or workarounds to enable us to import data from any reasonable source. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
I think we're both shooting at pretty much the same target here. Richard Wackerbarth wrote: [snip many vs. one] > > How does the user pick which processor to use? How do they configure it > > for their personal situation? > > This problem is not particular to any method of accomplishing the import. True. But I see "configure this QIF importer/filter" as an easier thing than "Pick from these QIF importers", where one is configured for Citibank QIFs, one is for Quicken QIFs, etc. Since I see much of the same configuration for each such filter, (e.g. if this field matches this criteria, file under this category), I see it as a customization of configuration, not a specialization of code. > Unfortunately, each user thinks it is easy to convert from some Memo field > that encodes his transaction information into his set of accounts. However, > that ease is based on the false assumption that the next bank does things > exactly the same way that the user's bank does it. Unfortunately, that is not > the case. I'm not advocating restricting the user to "one" importer configuration. In my head, I saw "filter sets", which could be tuned for each QIF dealt with. On the Import QIF dialog, you pick a file, then either pick a filter set or edit existing configurations. Maybe get a preview of the data, so you can configure an importer before the default rule dumps everything into the unfiled category. > > File->Import->QIF (Quicken, generic) > > ->QIF (Quicken, customizable) > > ->MsMoney > > ->Pocket$ for PalmPilot > > --- > > ->Install New Importer > > > > Something like this is what I see in my head. > > I quess that I would remove all of your (above the line) options and make > them appear only after they get configured. Even better. > I would reduce the menu items to "Post from XYZ Bank", "Post from Ripoff > Credit Card", "Post stock prices from YAHOO", etc. > > Or perhaps we simply tie it to the current Gnucash Account. Open the ledger > for "XYZ Bank" and select "Online update" Even better yet. Or "Import File", for downloaded stuff. Could add it to the context menu of the account so you don't even have to leave the front page. > Hide the details from your wife. That gets harder and harder the more she learns. =) [snip stuff] > > > Frankly, I am waiting for the new "text" format. Once we have it, I'll > > > advocate stripping the QIF importer out of Gnucash proper and changing it > > > into a reformatter that translates from QIF to "gnucash text". This > > > translation step should be combined with appropriate additional commands > > > to form part of an extensible user menu for acquiring additional data. > > > > So you're saying I should download the QIF, install, configure and > > run "Joe's magic QIF processing script for Your Credit Card's screwy > > files v0.2.1" on it, and import the output file? As long as the GUI > > shields me from having to drop to a shell to do it, I don't care what > > happens under the hood. > > I'm not sure how far I am willing to carry that. If your only objective is to > do it all from the GUI, I would balk. The complexity of building an editor > just so you can fetch "contributed" filters or write the code to implement a > new one is not worth the effort. However, I do think that, from the GUI, you > should be able to configure a new menu option from the set of available > filters and supply some small set of "parameters" to finish the filter > definition. That's actually what I was thinking, too. Different terminology, but the same idea. Also, that you should be able to install external importers after initial installation, so you could, e.g. synch with a palm pilot via an import option, or import data from some other source without having to recompile GnuCash to do so. > > And a way to synch with my PalmPilot, but that's another story... =) > > Not to too great of an extent. Palm import/export front ends should be > developed because they are a popular device. If I didn't have the demo from hell at work next month, I'd already be working on it... -- ebm +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Eric B. Mitchell mailto:[EMAIL PROTECTED] | | tel: (301) 809 - 3534Altair Aerospace Corporation | | tel: (800) 7 - ALTAIR4201 Northview Dr. Suite 410 | | fax: (301) 805 - 8122Bowie, MD 20716 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ ,___ /"\ / o=\ /"""---===/ / \_/ \__/ ---===/ |//\ || /""TT""/ //\ || ||""\ | // \ |||| // \ || ||__/ | //--==\ |L--/ || //--==\ || || "=, \ ---===/ \---===/ ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
At a minimum, could the importer be modified so that you can select which field is used to select accounts when importing, e.g. the Memo field instead of the category (L in .qif)? When importing data from my bank, all the transactions appear to come from a single, blank category. This means all transactions need to be dumped into a single account and then manually moved around. Using the Memo field would allow most of the entries to be automatically placed in the proper place. If a hierarchy were used it would be even better. Often, the Memo field is sufficient, but if the Payee field were used instead, when it is non-blank, even more accounts could be put in the right place. I am thinking of something like the following: Choose the order tags are used to select the destination account: Category 1 Payee2 Memo 3 The above shows the default ranking. The destination account is chosen by using the highest ranked non-blank tag in an entry. Here are two typical entries from my bank: !Type:Bank D05/31/00 MAutomated Banking Withdrawal NABW P T-100.00 ^ D05/29/00 MElectronic Debit Memo NEDM PATT CANADA T-28.85 ^ 'Automated Banking Withdrawal' should be mapped to the the cash account and 'ATT CANADA' mapped to the long distance account. The above scheme would hopefully handle a larger percent of the .qif formats out there. -- James (Jay) Treacy [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Interfacing with online bank.
One of the UK banks (which I am considering switching my accounts to -- hence the message) offers the option to interface with Microsoft Money. There is apparently no obvious or straightforward way to download a QIF file (as allowed by my current poor service, poor value hight-street bank) as the process is apparently entirely managed by the Microsoft program. Is there any way that gnucash can interface with such a system? Keith Refson -- Dr Keith Refson,"Paradigm is a word too often used by those who would Dept of Earth Sciences like to have a new idea but cannot think of one." Parks Road, -- Mervyn King, Deputy Governor, Bank of England Oxford OX1 3PR, UK Keith.Refson@ Tel: 01865 272026 earth.ox.ac.uk Fax: 01865 272072 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Compile Error
"Charles M. Gagnon" writes: > I'm getting compile errors on a Solaris 8 box on the last > gnucash (from CVS): > > Making all in calculation > make[3]: Entering directory > `/home/charlesg/src/gnucash/src/calculation' > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -c > expression_parser.c > In file included from expression_parser.c:333: > finproto.h:30: parse error before `0x0004' This error leads me to believe that some of the short function names in src/calculation are already defined as macros on your system. Let me do some renaming and see if that clears things up. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Working more closely with GNOME
On Thu, 20 Jul 2000, you wrote: > Terry <[EMAIL PROTECTED]> writes: > > > On Wed, 19 Jul 2000, you wrote: > > > > As a biased observer and gnucash user, I would agree that this is probably good > > with some reservations from a user standpoint. Right now gnucash works with > > both gnome and KDE. If gnucash developers become committed to gnome, does that > > preclude running gnucash under KDE in the future? or would gnucash become a > > gnome only app. Or are the KDE and gnome APIs becoming closer and better > > coordinated so as to preclude gnome/KDE only apps. I may switch from KDE to > > Gnome in the future or I may use both at different times, but as a user I > > definitely do not want apps that work only on one or the other Right now I > > think having both Gnome and KDE is a big win/win/win situation for Linux, > > Gnome, KDE and all the users. This is especially so if Gnome and KDE APIs > > continue being coordinated so that everybody can use one or the other or both. > > Well, there are two levels on which I could answer your > question. First, using the GNOME APIs does not preclude an application > from running under a KDE desktop enviornment. Second, a project does > not need to commit to being "GNOME only" to be involved in the GNOME > Foundation. For example, Sawmill and Gtk+ both consider themselves to > have broader reach than just GNOME. > > - Maciej I think the question I was trying to ask is: Do Gnome and KDE coordinate API's. I have seen reports that they do and I have seen reports denying such coordination. I think it would be a win all around if they do/would coordinate APIs. Do they? I mean officially? ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
cvs
CVS has been set up to automatically post notification of updates to [EMAIL PROTECTED], so if you'd like to track CVS changes as soon as they are made, you should subscribe to that list. These notifications will be used in lieu of the 'CVS has been updated' messages I used to post. thanks, dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
On Fri, 21 Jul 2000, James A. Treacy wrote: > At a minimum, could the importer be modified so that you can select which > field is used to select accounts when importing, e.g. the Memo field > instead of the category (L in .qif)? When importing data from my bank, all > the transactions appear to come from a single, blank category. This means > all transactions need to be dumped into a single account and then manually > moved around. Using the Memo field would allow most of the entries to be > automatically placed in the proper place. Could? yes. Should? I'll argue no. The problem is really that the bank does not create an appropriate QIF file. Rather than attempt to make a generalized translation widget that does everything for everybody, I think we should look to customized preprocessors that each handle one particular format and translate it into a consistent format for importing. It is MUCH more difficult to attempt to process many variations than it is to write many specialized translators. From the user's perspective, once he knows which preprocessor to use for a particular source, he can direct us to it (hopefully through stored preferences) and we can "do the right thing". Such a scheme is certainly easier to maintain because you don't have to comingle old, already working, code with new warts to handle the inevitable new input source. As a user, it is highly unlikely that I will be interested in all the formats used by some German bank and that used by one in France and that of the local S&L here in Texas. Frankly, I am waiting for the new "text" format. Once we have it, I'll advocate stripping the QIF importer out of Gnucash proper and changing it into a reformatter that translates from QIF to "gnucash text". This translation step should be combined with appropriate additional commands to form part of an extensible user menu for acquiring additional data. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
On Fri, 21 Jul 2000, Eric Mitchell wrote: > > Rather than attempt to make a generalized > > translation widget that does everything for everybody, I think we should > > look to customized preprocessors that each handle one particular format > > and translate it into a consistent format for importing. It is MUCH more > > difficult to attempt to process many variations than it is to write many > > specialized translators. From the user's perspective, once he knows which > > preprocessor to use for a particular source, he can direct us to it > > (hopefully through stored preferences) and we can "do the right thing". > > How does the user pick which processor to use? How do they configure it > for their personal situation? This problem is not particular to any method of accomplishing the import. Unfortunately, each user thinks it is easy to convert from some Memo field that encodes his transaction information into his set of accounts. However, that ease is based on the false assumption that the next bank does things exactly the same way that the user's bank does it. Unfortunately, that is not the case. > The usability question I keep asking myself is "Can I make this easy > enough for my wife to use?" Not install. Not configure. Not diagnose > problems. Just use. Only if you do the configuration. Just as you note that the bank doesn't know how you wish to handle things, gnucash has the same problem. Only the user (installation level, not data entry clerk level) is in a position to know how they want various things handled. > File->Import->QIF (Quicken, generic) > ->QIF (Quicken, customizable) > ->MsMoney > ->Pocket$ for PalmPilot > --- > ->Install New Importer > > Something like this is what I see in my head. I quess that I would remove all of your (above the line) options and make them appear only after they get configured. I would reduce the menu items to "Post from XYZ Bank", "Post from Ripoff Credit Card", "Post stock prices from YAHOO", etc. Or perhaps we simply tie it to the current Gnucash Account. Open the ledger for "XYZ Bank" and select "Online update" Hide the details from your wife. > > > Such a scheme is certainly easier to maintain because you don't have to > > comingle old, already working, code with new warts to handle the > > inevitable new input source. As a user, it is highly unlikely that I will > > be interested in all the formats used by some German bank and that used > > by one in France and that of the local S&L here in Texas. > > The code in the importer is fine, AFAICT. The GUI that drives it is > incapable of handling anthing other than QIFs from Quicken. Have a > default, from-Quicken-and-has-all-fields importer. Also, have one > that's as-customizable-as-the-netscape-mail-filter for special cases. > > The user tries the generic one. If it fails, they try the customizable > filter. Have online help/step-by-step assistance ready. > > > Frankly, I am waiting for the new "text" format. Once we have it, I'll > > advocate stripping the QIF importer out of Gnucash proper and changing it > > into a reformatter that translates from QIF to "gnucash text". This > > translation step should be combined with appropriate additional commands > > to form part of an extensible user menu for acquiring additional data. > > So you're saying I should download the QIF, install, configure and > run "Joe's magic QIF processing script for Your Credit Card's screwy > files v0.2.1" on it, and import the output file? As long as the GUI > shields me from having to drop to a shell to do it, I don't care what > happens under the hood. I'm not sure how far I am willing to carry that. If your only objective is to do it all from the GUI, I would balk. The complexity of building an editor just so you can fetch "contributed" filters or write the code to implement a new one is not worth the effort. However, I do think that, from the GUI, you should be able to configure a new menu option from the set of available filters and supply some small set of "parameters" to finish the filter definition. > And a way to synch with my PalmPilot, but that's another story... =) Not to too great of an extent. Palm import/export front ends should be developed because they are a popular device. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Compile Error
I'm getting compile errors on a Solaris 8 box on the last gnucash (from CVS): Making all in calculation make[3]: Entering directory `/home/charlesg/src/gnucash/src/calculation' gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -c expression_parser.c In file included from expression_parser.c:333: finproto.h:30: parse error before `0x0004' expression_parser.c: In function `next_token': expression_parser.c:630: warning: suggest parentheses around assignment used as truth value expression_parser.c:642: warning: control reaches end of non-void function make[3]: *** [expression_parser.o] Error 1 make[3]: Leaving directory `/home/charlesg/src/gnucash/src/calculation' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/charlesg/src/gnucash/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/charlesg/src/gnucash' make: *** [all-recursive-am] Error 2 -- Charles Gagnon | My views are my views and they http://unixrealm.com | do not represent those of anybody [EMAIL PROTECTED] | but me. Whatever temperature a room is, it's always room temperature ... -- Stephen Wright ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
[EMAIL PROTECTED] said: > one of the sourceforge people today asked me about gnucash, and after > i raved about it for a few moments, he said, "I have 3 1/2 years of > data there, will it create these new accounts for me as it goes when > it encounters my new categories while I do my imports?" I recently did some QIF importing and I was quite impressed how relatively simple it was considering that Quicken does not do double entry accounting. GNUCash lets you specify the translation from QIF categories to different accounts in your GNUCash account hierarchy. The person who will be doing the importing should do some reading of documentation before trying to do the import. It also helps to build an account hierarchy just to get a feel for what is possible. He can find info on double accounting at: http://www.gnucash.org/docs/C/xacc-double.html A nice sample account hierarchy is at: http://www.gnucash.org/docs/C/xacc-groups.html Btw, you can safely say a wholehearted "yes" to your friend in response to his question. If he wants to have the accounts organized in a nice hierarchical fashion, he will need to build that hierarchy *before* importing. He will also need to specify the mapping from category name to GNUCash account name (GNUCash provides a nice interface for doing this). Jason D Rennie www.ai.mit.edu/~jrennie/ MIT: (617) 253-5339 [EMAIL PROTECTED] MITRE: (781) 271-7249 [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: question about importing .qif files
As I just sent to Bill in an email about the QIF importer failing to usefully import data from screwy online account statements: Richard Wackerbarth wrote: > > On Fri, 21 Jul 2000, James A. Treacy wrote: > > At a minimum, could the importer be modified so that you can select which > > field is used to select accounts when importing, e.g. the Memo field > > instead of the category (L in .qif)? When importing data from my bank, all > > the transactions appear to come from a single, blank category. This means > > all transactions need to be dumped into a single account and then manually > > moved around. Using the Memo field would allow most of the entries to be > > automatically placed in the proper place. > > Could? yes. Should? I'll argue no. The problem is really that the bank does > not create an appropriate QIF file. Should? I'll go with yes. The problem is that the bank does not have sufficient data to specify a category on my transactions. However, for the most part there's a 1-to-1 mapping from payee to category. For example, everything I pay to Petsmart gets filed under "Pets." 7-ELEVEN is a special case where it could be going to the "Gas" or the "Junk Food" categories. If there were a way to configure filing transactions similar to the Netscape Mail filter, I think that would be quite usable. The filter works on "any/all conditions" "more/fewer": "select list of fields" "matches/doesn't" "pattern", "action". This logic is a million times easier to understand than, say, procmail. Not nearly as powerful, but for filing mailing list messages in different folders, a pattern similar to this one, it's sufficient. > Rather than attempt to make a generalized > translation widget that does everything for everybody, I think we should look > to customized preprocessors that each handle one particular format and > translate it into a consistent format for importing. It is MUCH more > difficult to attempt to process many variations than it is to write many > specialized translators. From the user's perspective, once he knows which > preprocessor to use for a particular source, he can direct us to it > (hopefully through stored preferences) and we can "do the right thing". How does the user pick which processor to use? How do they configure it for their personal situation? If it can't be driven from the GnuCash GUI, it will never be used by a large quantity of average (i.e. hoping to be former Quicken) users. Or me, for that matter, and I like computers. The usability question I keep asking myself is "Can I make this easy enough for my wife to use?" Not install. Not configure. Not diagnose problems. Just use. File->Import->QIF (Quicken, generic) ->QIF (Quicken, customizable) ->MsMoney ->Pocket$ for PalmPilot --- ->Install New Importer Something like this is what I see in my head. > Such a scheme is certainly easier to maintain because you don't have to > comingle old, already working, code with new warts to handle the inevitable > new input source. As a user, it is highly unlikely that I will be interested > in all the formats used by some German bank and that used by one in France > and that of the local S&L here in Texas. The code in the importer is fine, AFAICT. The GUI that drives it is incapable of handling anthing other than QIFs from Quicken. Have a default, from-Quicken-and-has-all-fields importer. Also, have one that's as-customizable-as-the-netscape-mail-filter for special cases. The user tries the generic one. If it fails, they try the customizable filter. Have online help/step-by-step assistance ready. > Frankly, I am waiting for the new "text" format. Once we have it, I'll > advocate stripping the QIF importer out of Gnucash proper and changing it > into a reformatter that translates from QIF to "gnucash text". This > translation step should be combined with appropriate additional commands to > form part of an extensible user menu for acquiring additional data. So you're saying I should download the QIF, install, configure and run "Joe's magic QIF processing script for Your Credit Card's screwy files v0.2.1" on it, and import the output file? As long as the GUI shields me from having to drop to a shell to do it, I don't care what happens under the hood. What I need in a QIF importer is a way to configure otherwise unassigned transactions to end up in the right place, given the info that I *do* have available to me, by telling it where to find the file, and which filter to use, and nothing more. And a way to synch with my PalmPilot, but that's another story... =) -- ebm +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Eric B. Mitchell mailto:[EMAIL PROTECTED] | | tel: (301) 809 - 3534Altair Aerospace Corporation | | tel: (800) 7 - ALTAIR4201 Northview Dr. Suite 410 | | fax: (301) 805 - 8122Bowie, MD 20716 | +=-=-=-=-=-=-
Re: question about importing .qif files
"James A. Treacy" <[EMAIL PROTECTED]> writes: > At a minimum, could the importer be modified so that you can select which > field is used to select accounts when importing, e.g. the Memo field > instead of the category (L in .qif)? Automatic guessing of the account is on my feature list for the next revision of the QIF importer. It will require a verification step that can be shared with some other new features, and I'm planning to do them all at once. Just as a background excuse, the current version is mainly targeted at people who are importing en masse from a set of Quicken books. In that case, the category fields are there. Features like detection of redundant information (importing transactions already in your gnucash books) and auto-guessing of accounts are mainly useful for folks importing QIF fragments downloaded from their banks. That's a very important use of the QIF format, but it's not what the current importer is good at. Hopefully that will change in the next few weeks. Thanks, Bill Gribble ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
