Re: Use of Sleepycat DB
On Mon, May 15, 2000 at 10:36:44PM -0700, Rob Walker wrote: On Mon, 15 May 2000 22:45:16 -0500, Christopher Browne [EMAIL PROTECTED] said: Christopher On 15 May 2000 22:10:21 CDT, the world broke into rejoicing as Christopher Rob Browning [EMAIL PROTECTED] said: However, after poking around in the db docs (from now on, when I say db here, I mean the sleepycat db), I'm wondering if this might be much better candidate for that job than "rolling our own" fs subtree approach. For now, I'm putting aside the question of whether or not we might want to break out the current engine data as db tables. For now I'm just interested in considering if using db might be the best way to give us the "sectional data store". Christopher Lots of "food for thought." okay, I will be the curmudgeon (sp?), here " Berkeley DB is Open Source. It's free for use in other Open Source projects, like PostgreSQL. If a developer wants to use it in a proprietary application, then the developer needs to pay Sleepycat a licensing fee -- that's how we make our living. But Open Source projects don't have to pay us anything. You can download the full package from our Web site at www.sleepycat.com. " doesn't sound too GPL to me. Does this pose a problem with the GPL'ness of gnucash? From the same website, section "Licensing": "If you build an application that you do not redistribute outside of your site, or if you build an application and your source code is freely available and redistributable by others, you may use Berkeley DB at no charge. You must, of course, abide by the terms of the copyrights that apply to the Berkeley DB software. If you redistribute your application outside of your site and your source code is not freely available and redistributable by others, then you require a commercial license from Sleepycat Software." In the actual license they go on to say basically that if you _redistribute_ their source code, you must retain the copyright notice and information on where to get it. For the purposes of gnucash that should not pose any problem. In the FAQ they even say about commercial products: "21. Do I have to license Berkeley DB to create an application for a single customer? Not usually. The easy solution to this problem is to download Berkeley DB onto the customer's machine when you create the application. If you do that, you will not have redistributed Berkeley DB, and do not require a commercial license. You must make your customer aware of the restriction against redistribution, of course, so that they do not redistribute Berkeley DB, e.g., they may not install the application in thousands of sites around the world." That is, even someone offering commercial services for gnucash need not pay a license fee to them. Apart from all this, the whole db looks very good to me. I concur with my predecessors in this thread: Let's think about using it. The advantages of the Berkeley db are too great to ignore. Just my 2 cents, Jan . . .. .. . . . .. . .. .. ... ... .. . . . .. Jan Schrage [EMAIL PROTECTED] http://www.unix-ag.uni-kl.de/~schrage PGP: http://pgp5.ai.mit.edu/pks-commands.html PGP signature
Re: gnucash 1.3.7 bugs.
On Mon, May 15, 2000 at 05:56:14PM -0700, Dave Peticolas wrote: Hi Jon, here is what happened. We recently discovered that we have been using the terms 'debit' and 'credit' incorrectly in GnuCash. In standard accounting practice, a debit is an increase in assets, such as a deposit to a bank account, and a credit is a decrease in assets, such as a payment, credit card charge, etc. Starting in 1.3.7, we began using the terms according to the sense above, thus the change in column position of items in the reconcile window. I apologize for any confusion. Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. -- Randolph Fritz Eugene, Oregon, USA
Re: Multiple currencies
Tamas Nagy wrote: Is there any way to change the balance currency in the main window to other than USD? What version of GnuCash are you using? In 1.3.7 the balances of the individual accounts should display the account's currency. The currency in the status line is determined by the locale, so try export LC_ALL=hu_HU Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/
Re: gnucash 1.3.7 bugs.
"Jon A. Christopher" [EMAIL PROTECTED] writes: I'm not using gnucash's double-entry features. Perhaps that'd be the best solution---if using single-entry, use the informal meanings of credit/debit, and if you're doing double entry, use the formal ones. Or just punt and call the columns "funds in" and "funds out" ;) We've been discussing whether to eliminate the option of "single entry" completely. Presumably this would inconvenience you :) Can you describe what it is that keeps you from using the default (double entry) mode of operation of gnucash? If you can explain it, maybe we can fix whatever it is that's a barrier to you. Bill Gribble
Re: A Currency bug in 1.3.7
Arnold Troeger wrote: I have a couple of problems with gnucash 1.3.7: 1) Total assets are calculated from all the categories independent of the category's currency. I have accounts defined in US Dollars and Thai Baht. It was a bit surprising to find that I had so much money. This is a known bug, but we don't have a good solution to it yet. 2) This is not a bug but a suggestion. Would it be possible to increase the number of decimal places in the price column of Currency accounts? Converting from Dollars to Baht typically ends up with a rate of about 0.3something. I would like that, too. Preferably 5 decimal places, because the euro exchange rates are defined to 5 decimal places. Dave: I think this should take you less than 5 minutes, so can you change this? Thanks in advance! 3) Not a bug but another suggestion. You have "from" working for the currency acounts. Would it be possible to set up the bought and sold accounts to transfer the foreign currencies into an account? I can transfer Dollars into a currency account, but I cannot transfer Baht out of the same account. Have you set the security of the currency account to Baht? To transfer an amount from one account to another the two accounts must share a common currency and/or security. Read more about this in the documentation. Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/
Re: on-line banking qif import
Christopher Browne [EMAIL PROTECTED] writes: Ouch. I'm starting to get a tad concerned about how "fuzzy" this matching is starting to get. Well, as long as the user has to put a "stamp of approval" on the matches, I think it's OK. I'm currently working on an overhaul of the QIF code that will support this as an optional step in the import. I don't think the heuristics will be that hairy... really the amount plus a date window is a fairly unique identifier. This sort of suggests that the system shouldn't quietly drop the transactions, but rather list them in parallel [e.g. - side by side] and provide the option of doing some combination of: a) Drop the one on the books in favor of the one being loaded, b) Drop the one being loaded, c) Keep both, d) [This starts getting questionable...] Merge data for the transactions together, say pulling all the non-blank fields from the input file in to replace what's in GnuCash. I think (d) is an important option. Often the bank has some information (tracking numbers, etc) that you don't have when you enter the transaction, and you have memos and such that the bank doesn't have. Bill Gribble
Re: Use of Sleepycat DB
Rob Walker [EMAIL PROTECTED] writes: okay, I will be the curmudgeon (sp?), here That's exactly what I want. I'd rather figure out any problems now, rather than later. With respect to the license, I thought of that while I was poking around last night. I'm not sure if this plays nice with the GPL or not. I'll ask the license "lawyers" I know, and perhaps the GNU people, but in the worst case, I wouldn't be surprised if the sleepycat people would be willing to offer it under the GPL as well as the current license (presuming they have the authority to do so). We'll see. Though I'm still reasonably impressed with sleepycat, I did have the following further observations as I poked around last night: - The current db release in Debian is 2.7.7.1.c. It *looks* like maybe this is the current "stable" version, but it's the last of the 2.X line, and the docs on the sleepycat web site are actually describing 3.X, which is the one they *strongly* recommend people download and use. So maybe 3.X is the current stable version. - Consequently, some of the features described in the wesite docs are only available in 3.X, not 2.X. - It appears the db format has changed in the past, and changed again from 2.X to 3.X, requiring a dump and load to migrate. This isn't a big deal, but it's somewhat inconvenient. This might be another argument for starting with 3.X, but it's also an issue that's likely to crop up in the future. I suspect, though, that we may be able to handle this internally in gnucash, without bothering the user, but I'm not positive of that. - The db_dump and db_load programs (that use the text format), don't handle db's with custom sort orders (for btree db's), etc. So for some db's you have to take the source to db_load and write your own that uses he "right" put() function with the right custom procedures (basically the same put() that you use in your app). - Finally, as compared to using something like scheme forms or xml, the text output format used by their db_dump program may not be as user friendly as we'd like. Though we could perhaps copy/paste their db_dump/load code (and as mentioned above, we may need to), and make the format as user friendly as we like. More thoughts? -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: gnucash 1.3.7 bugs.
Randolph Fritz [EMAIL PROTECTED] writes: Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. If we get a good description of all this, we should stick it in the docs. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: gnucash 1.3.7 bugs.
Michael Gerdts [EMAIL PROTECTED] writes: Since both types of users have to adhere to the same laws and spend money in rather similar ways, it makes a lot of sense to have a configurable system that allows some folks to have "credit", "debit", and "double entry", while allowing others to have "money in", "money out", "income categories", and "expense categories". I agree about the labels; while I prefer to see the accounting way, it makes sense to have "common sense" names for the column headers... which there already are for the bank and credit card registers that everyone looks at. Not too long ago, there were "common sense" labels for everything: liabilities, assets, expenses, income. The problem was that they didn't make much sense. If you can come up with a set of good one-word column headers that makes sense for expense, income, asset, liability, and equity accounts I'm sure they would be appreciated. I don't understand the objection to double entry. From the user perspective, what's the difference between accounts and categories? There's not one AFAICT. The only "oddity" is that in double entry you are forced to pick a "category" for every transaction. Big deal. That's what "misc" is for. Bill Gribble
Re: gnucash 1.3.7 bugs.
Randolph Fritz [EMAIL PROTECTED] writes: Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. When you make a deposit in a bank account, the bank OWES YOU money. You become a "creditor" and the bank is a "debtor", just as if you had loaned the bank money. Which you have. A "credit" is a "payment by a debtor on an amount due" by both common sense and accounting practice. Therefore, a withdrawal of money from the bank, which reduces the balance of the account and therefore the amount that the bank owes you, is a "credit". A "debit" is etymologically a "debt", i.e. an increase in the amount owed by a debtor, again in both common sense and accounting practice. Therefore, a deposit of money into the bank, which is an increase in the balance of the account and of the amount of money that the bank owes you, is a "debit". I had to have this explained to me a million times but now it makes perfect sense and I can't even think of a withdrawal being a "debit" any more (how's that? I don't owe the bank any money!) Bill Gribble
Re: Use of Sleepycat DB
On 16 May 2000 10:16:58 -0500, Rob Browning [EMAIL PROTECTED] said: rlb - It appears the db format has changed in the past, and changed rlb again from 2.X to 3.X, requiring a dump and load to migrate. rlb This isn't a big deal, but it's somewhat inconvenient. This rlb might be another argument for starting with 3.X, but it's also an rlb issue that's likely to crop up in the future. I suspect, though, rlb that we may be able to handle this internally in gnucash, without rlb bothering the user, but I'm not positive of that. pop up window, text reading, "the file format has been changed in gnucash 1.2.4.5, while this file was written by a previous version. While gnucash can 1.2.4.5 can read and write this version of the file, there is no guarantee that future versions of gnucash will be able to read and write this file. Would you like to update this file to the new version now?" rob
Re: gnucash 1.3.7 bugs.
On 16 May 2000 10:40:15 -0500, Bill Gribble [EMAIL PROTECTED] said: Bill Not too long ago, there were "common sense" labels for Bill everything: liabilities, assets, expenses, income. The problem Bill was that they didn't make much sense. If you can come up with a Bill set of good one-word column headers that makes sense for Bill expense, income, asset, liability, and equity accounts I'm sure Bill they would be appreciated. expense == out income== in asset == good stuff liability == bad stuff equity== worth not quite all one word, maybe just s/stuff//, I don't know. rob
Re: gnucash 1.3.7 bugs.
On 16 May 2000, Bill Gribble wrote: "Jon A. Christopher" [EMAIL PROTECTED] writes: I'm not using gnucash's double-entry features. Perhaps that'd be the best solution---if using single-entry, use the informal meanings of credit/debit, and if you're doing double entry, use the formal ones. Or just punt and call the columns "funds in" and "funds out" ;) We've been discussing whether to eliminate the option of "single entry" completely. Presumably this would inconvenience you :) Can you describe what it is that keeps you from using the default (double entry) mode of operation of gnucash? If you can explain it, maybe we can fix whatever it is that's a barrier to you. Bill Gribble Eliminating single-entry would be a mistake IMHO. Who wants to learn a new system of accounting just to balance their checkbook? Not me. I'm a programmer and geek, but for some things, I just want to use the bloody software, not become one with it. I'm sure I could figure out the double-entry system, but I don't really want to go to extra effort for something as trivial as money after all. Gnucash as it is right now (except for the unfortunate column names) is perfect for people who just want to balance their checkbook. I know it'll do much more, and more is planned, but that's not functionality I'm currently interested in. Don't most programs start out in the simplest mode of operation, and then allow users to optionally add complexity? I think that's the best way for gnucash to go, certainly not the route of removing the simpler mode of operation! If gnucash goes entirely double-entry, I'll probably just not upgrade from the current version (which would be unfortunate), and if serious bugs manifest themselves, I'd probably go with another program. Please don't remove the single-entry mode! Regards, Jon -- Dr. Jon A. Christopher / [EMAIL PROTECTED] | Project URLs: Department of Biochem./Biophys./ spock: http://quorum.tamu.edu/spock Texas AM University MS-2128 / lesstif: http://www.lesstif.org/ College Station, TX, 77843 / personal: http://quorum.tamu.edu/jon
Re: A Currency bug in 1.3.7
On Tue, May 16, 2000 at 03:35:26PM +0200, Herbert Thoma wrote: Arnold Troeger wrote: I have a couple of problems with gnucash 1.3.7: 1) Total assets are calculated from all the categories independent of the category's currency. I have accounts defined in US Dollars and Thai Baht. It was a bit surprising to find that I had so much money. This is a known bug, but we don't have a good solution to it yet. Really? This happened for me for 1.3.6, but with 1.3.7 GnuCash seems to just ignore any foreign currency accounts. Not perfect, but better. Are there any plans to get automatic price quotes for currencies? There seems to be such a service at oanda.com, for instance. Best, Dylan Thurston
Re: gnucash 1.3.7 bugs.
How about, as a first step, we make the reconcile window be configurable to use, e.g., 'Funds In' and 'Funds Out' instead of debit/credit as you suggest? Something like that is probably necessary. Gnucash looks to me like one of the crucial tools that will get Linux onto desktops everywhere. But that's going to be a lot harder if "normal" users find the interface confusing. I think it's more important for people to be able to handle their finances without getting confused or worrying about getting things wrong than having the technically correct terminology. My two cents... jon Jonathan Corbet Executive editor, LWN.net [EMAIL PROTECTED]
Re: gnucash 1.3.7 bugs.
In regard to: Re: gnucash 1.3.7 bugs., Michael Gerdts said (at 10:24am on...: This issue really seems to beg the question of who the target audience is. If it is accountants, it makes good sense to do things like accountants do. If it is the average joe that thinks that accountants are as nerdy as UNIX geeks but lacking personality, the more casual presentation of accounting should appear wherever there is a choice to be made between casual and technically accurate presentation. That's pretty much exactly what I was thinking too. Apps like "Quicken" use sound accounting principles but they aren't targeted at professional accountants, so their interfaces are designed to be intelligible by Joe User. A professional accountant may scoff at the interface, but the simple interface on Quicken or MS Money is very good for its target audience. Since both types of users have to adhere to the same laws and spend money in rather similar ways, it makes a lot of sense to have a configurable system that allows some folks to have "credit", "debit", and "double entry", while allowing others to have "money in", "money out", "income categories", and "expense categories". And then when the average joe changes majors from history to business, a simple changing of preferences makes the personal finances turn into something that resembles things that he/she is learning about in accounting 101. Perhaps, depending on how much work this turns into for the developers. Maybe the "know thy target audience" answer will obviate the need for this much flexibility. It's nice to have the flexibility, but there will be a cost associated with it. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: gnucash 1.3.7 bugs.
On Tue, 16 May 2000, Tim Mooney wrote: And then when the average joe changes majors from history to business, a simple changing of preferences makes the personal finances turn into something that resembles things that he/she is learning about in accounting 101. Perhaps, depending on how much work this turns into for the developers. Maybe the "know thy target audience" answer will obviate the need for this much flexibility. It's nice to have the flexibility, but there will be a cost associated with it. The cost may not be as bad as it seems. Since we already have the abstraction for "furrin" languages, we already have most of the hooks in place to handle alternate textual strings in the displays. The biggest hassle is likely to be the documentation.
Re: Use of Sleepycat DB
Rob Browning writes: With respect to the license, I thought of that while I was poking around last night. I'm not sure if this plays nice with the GPL or not. I think it would require an exception clause: everyone who holds copyright to any GPL'd gnucash code would have to agree to a license addendum saying "this software may be linked with Berkely DB" or something similar. I'm certainly willing to agree to such a thing for my one tiny little patch: in fact, I'm willing to assign it to Linas or Dave or someone. I wouldn't be surprised if the sleepycat people would be willing to offer it under the GPL as well as the current license (presuming they have the authority to do so). I just casually glanced through the Sleepycat license, but it looked to me like they would be giving up nothing by releasing under the GPL. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Use of Sleepycat DB
On Mon, May 15, 2000 at 10:36:44PM -0700, Rob Walker wrote: On Mon, 15 May 2000 22:45:16 -0500, Christopher Browne [EMAIL PROTECTED] said: Christopher On 15 May 2000 22:10:21 CDT, the world broke into rejoicing as Christopher Rob Browning [EMAIL PROTECTED] said: However, after poking around in the db docs (from now on, when I say db here, I mean the sleepycat db), I'm wondering if this might be much better candidate for that job than "rolling our own" fs subtree approach. For now, I'm putting aside the question of whether or not we might want to break out the current engine data as db tables. For now I'm just interested in considering if using db might be the best way to give us the "sectional data store". Christopher Lots of "food for thought." okay, I will be the curmudgeon (sp?), here " Berkeley DB is Open Source. It's free for use in other Open Source projects, like PostgreSQL. If a developer wants to use it in a proprietary application, then the developer needs to pay Sleepycat a licensing fee -- that's how we make our living. But Open Source projects don't have to pay us anything. You can download the full package from our Web site at www.sleepycat.com. " doesn't sound too GPL to me. Does this pose a problem with the GPL'ness of gnucash? It will cause inconvenience for distributions. A dependence on something that is not true Open Source (follows the DFSG) causes a package to go in contrib. Withe a license as described above, Berkeley DB would have to go in non-free and gnucash would go in contrib. But I thought Berkeley DB was already in glibc, right? There is a README in the glibc documentation in the redhat dist that reads: As a special exception, when Berkeley DB is distributed along with the GNU C Library, in any program which uses the GNU C Library in accord with that library's distribution terms, it is also permitted for Berkeley DB to be loaded dynamically by the GNU C Library to implement standard ISO/IEC 9945 and Unix interface functionality. Sleepycat Software, Inc. dave
Re: Use of Sleepycat DB
John Hasler [EMAIL PROTECTED] writes: I just casually glanced through the Sleepycat license, but it looked to me like they would be giving up nothing by releasing under the GPL. I've contacted them and the FSF, so we'll see what they say. I've already gotten an inital response, which sounds promising, and I'm waiting for permission to repost that mail here. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Re: Use of Sleepycat DB
"James A. Treacy" [EMAIL PROTECTED] writes: It will cause inconvenience for distributions. A dependence on something that is not true Open Source (follows the DFSG) causes a package to go in contrib. Withe a license as described above, Berkeley DB would have to go in non-free and gnucash would go in contrib. Actually libdb2 (which is the full sleepycat DB) is in Debian's main distribution. I presume the license lawyers have looked at it, but perhaps not. I don't think DB2 violates the DFSG, but I'd have to think harder about it to be sure. It doesn't have any discriminating clauses against any free software, and I don't think the DFSG cares what restrictions are placed on non-free software... -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Documentation
On 16 May 2000 10:29:25 CDT, the world broke into rejoicing as Rob Browning [EMAIL PROTECTED] said: Randolph Fritz [EMAIL PROTECTED] writes: Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. If we get a good description of all this, we should stick it in the docs. Dare I comment, again, that a presentation of this is already there? Possibly not in as much gory detail as the recent discussion, but it's certainly there... It probably went in back in December when I did some major revisions to the documentation. Look for: xacc-double.html In particular, look for the phrase "Not-quite-an-aside." -- Windows 'XCV - A 32 bit patch for a 16 bit interface to an 8 bit OS designed for a 4 bit chip from a 2 bit company that can't stand 1 bit of competition... [EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/lsf.html
Re: Use of Sleepycat DB
On 16 May 2000 10:16:58 CDT, the world broke into rejoicing as Rob Browning [EMAIL PROTECTED] said: Rob Walker [EMAIL PROTECTED] writes: okay, I will be the curmudgeon (sp?), here That's exactly what I want. I'd rather figure out any problems now, rather than later. With respect to the license, I thought of that while I was poking around last night. I'm not sure if this plays nice with the GPL or not. I'll ask the license "lawyers" I know, and perhaps the GNU people, but in the worst case, I wouldn't be surprised if the sleepycat people would be willing to offer it under the GPL as well as the current license (presuming they have the authority to do so). We'll see. The "lawyering" of this would doubtless be of interest with other projects too. Though I'm still reasonably impressed with sleepycat, I did have the following further observations as I poked around last night: - The current db release in Debian is 2.7.7.1.c. It *looks* like maybe this is the current "stable" version, but it's the last of the 2.X line, and the docs on the sleepycat web site are actually describing 3.X, which is the one they *strongly* recommend people download and use. So maybe 3.X is the current stable version. - Consequently, some of the features described in the wesite docs are only available in 3.X, not 2.X. - It appears the db format has changed in the past, and changed again from 2.X to 3.X, requiring a dump and load to migrate. This isn't a big deal, but it's somewhat inconvenient. This might be another argument for starting with 3.X, but it's also an issue that's likely to crop up in the future. I suspect, though, that we may be able to handle this internally in gnucash, without bothering the user, but I'm not positive of that. Debian's release of libdb2 comes with "db_dump185", which is rather suggestive of a past migration. I suspect this won't be a _huge_ issue. - The db_dump and db_load programs (that use the text format), don't handle db's with custom sort orders (for btree db's), etc. So for some db's you have to take the source to db_load and write your own that uses he "right" put() function with the right custom procedures (basically the same put() that you use in your app). If we used a customized sort order, one of the early utilities ought to be a custom dump/load, so I don't see this as an immense problem. - Finally, as compared to using something like scheme forms or xml, the text output format used by their db_dump program may not be as user friendly as we'd like. Though we could perhaps copy/paste their db_dump/load code (and as mentioned above, we may need to), and make the format as user friendly as we like. I did a bit of fiddling around with db_dump and db_load last night; it is, indeed, a tad less directly "friendly" than one might wish for. That comes directly out of the fact that dblib supports somewhat structured data, as opposed to the traditional "raw hash tables." The format isn't downright nasty (well, if you forget the -d flag, it looks pretty nasty...), and is certainly a whole lot better than fighting with a binary format. An interesting contrast may be taken with CDB, the "constant database," which is largely a read-only format. It has a slightly friendlier data format, albeit one that still mandates a quite strict format to the input. [Entertaining utility of the month: Bun. It uses the CDB format for storage, and essentially replicates cpio/tar's functionality, albeit sans compression. The cool part is that since it uses a well-specified "hash table" format, it is _trivial_ to write programs to walk through data files and look at what's in them. I don't think tar or cpio are particularly easy to hack around with...] -- Rules of the Evil Overlord #210. "All guest-quarters will be bugged and monitored so that I can keep track of what the visitors I have for some reason allowed to roam about my fortress are actually plotting." http://www.eviloverlord.com/ [EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/lsf.html
start of new accounting period
We went round and round on this a while back, but I don't remember all the conclusions. Has anybody written code to be able to delete every transaction in every account to prepare for a new accounting period? It would be really cool if it also adjusted the opening balance to be the prior ending balance, but that is a nicety. I ask because I'm getting ready to start recording my January transactions - yeah I know I'm behind. I've archived my 1999 file and want to start the new accounting period with no transactions, the same accounts, and the same starting balance that I ended the last period with. It would be nice to not have to delete hundreds of transactions by hand or reenter 50 accounts by hand. So, any help would be much appreciated. Are others interested in this as well? Rob Coker
RE: gnucash 1.3.7 bugs.
"Jon A. Christopher" [EMAIL PROTECTED] writes: Eliminating single-entry would be a mistake IMHO. Who wants to learn a new system of accounting just to balance their checkbook? Does he mean that he only has one category/account? - checking. So, he's just using gnucash like a simple calculator or maybe a preprogrammed spreadsheet? I don't get it. Rob Coker
Re: start of new accounting period
Rob Coker writes: Has anybody written code to be able to delete every transaction in every account to prepare for a new accounting period? Wouldn't it be simpler to just extract the chart of accounts and use it to start a new file? In fact, a chart of accounts editor of some sort would be nice. Creating dozens of expense accounts by going pointy-clicky over and over is rather slow. It would be really cool if it also adjusted the opening balance to be the prior ending balance, but that is a nicety. Or extract the closing balances from the old file and insert them as opening balances in the new one. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
merging imported transactions
On Mon, 15 May 2000, Christopher Browne wrote: d) [This starts getting questionable...] Merge data for the transactions together, say pulling all the non-blank fields from the input file in to replace what's in GnuCash. I'd like some sort of merging. Can we come up with simple rules that work for everyone? For instance, the transactions in the .qifs that I get contain a date, an amount, and a description like "CHQ#00453-0041094785". The existing transaction that I typed in contains a different date, the cheque number "453", the description "CHQ#00453", a memo, and a transfer account. Assuming that the matching rules were loose enough for GnuCash to match them up, I'd like the merge to keep the imported description and the existing cheque number, memo and transfer account. What about the date? Does existing accounting practice say which date to use? Do different countries have different practices?
Re: Use of Sleepycat DB
John Hasler [EMAIL PROTECTED] writes: I don't see why gnucash needs such a thing, though. We may or may not be interested in it as a database for our financial data. The current question is simply, does it give us a superior solution to the "storing things associated with a given account group that would otherwise have to be in multiple files" problem. For example, right now we just have the engine data in the .gnc (or .xac) file, but we need to start storing a lot more data that's associated with the account group, but not strictly speaking, data that should be mingled with the engine data, things like budgeting info (which might actually eventually go in the engine eventually), recurring transactions, per-user preferences for a given account group (window placements, colors, whatever), multiple-user locks, etc. This may or may not be exactly the set of things that we want, but it seems clear that we need to store more data with each account group than we are storing now. Before I started thinking about the Sleepycat DB, the leading contender to solve this problem was the implementation of a home-grown API that would just store the data in multiple files in a subdirectory, but this is arguably less intuitive, and more hassle for the end user, than storing everything in one "sectional file". This is what the Sleepycat DB (or just the stripped down version that's in libc) might give us, and it might also give us a straightforward migration path for the engine data if we decide we want a fancier storage mechanism. So instead of having: my-gnucash-file.gnc/data my-gnucash-file.gnc/budget my-gnucash-file.gnc/recurring-transactions my-gnucash-file.gnc/someuser.lock we'd just have my-gnucash-file.gnc which is a db2 file and would contain the above files as Sleepycat subname databases. Anyway, this is the motivation for the current discussion. Hope it makes my motivation at least somewhat clearer, even if you're not convinced. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930
Memos for transactions?
I just noticed a consequence of Memos being associated with Journal Entries and not Transactions: Even for a simple transaction without splits, only one side of the transaction sees the memo. Furthermore, which side sees the memo is different in the "Double Line" and "Multi Line" views. This seems undesirable, but I don't see an obvious fix. --Dylan Thurston
Re: Terminology
On Mon, May 15, 2000 at 11:34:17PM -0500, Christopher Browne wrote: Surprise, you are using a double-entry ledger system :) That is, unless you are leaving all of your 'transfer from' fields blanks, all of your entries in checking account have a matching entry in an expense, income, etc. account. I suppose we could make the meaning of 'debit' and 'credit' configurable. It's really unfortunate that the informal meanings of the terms are exactly opposite the accouting meanings. Blame the evil bankers. They report things from their perspective that is exactly opposite to yours. I just noticed that they (the banks) do this even in the little check registers they give you for your checkbook. This is guaranteed to confuse people. --Dylan Thurston
1.3.7 build error in po/
-BEGIN PGP SIGNED MESSAGE- I just pulled down the 1.3.7 SRPM and tried to build. I got the following in the po subdirectory: make: *** No rule to make target `en.gmo', needed by `all'. Stop. CATALOGS is set to en.gmo but I don't have a en.anything. I have en_GB.po roland - -- PGP Key ID: 66 BC 3B CD Roland B. Roberts, PhDUnix Software Solutions [EMAIL PROTECTED] 76-15 113th Street, Apt 3B [EMAIL PROTECTED] Forest Hills, NY 11375 -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQCVAwUBOSIWXOoW38lmvDvNAQFWUgQAtiIOA4x6QEZCoWwHWom77IHNomdsjkiW Ka2VHVKvj8fms2he1ND6Z72JPW7lBYEv8wyL2jqvfxitgNerORXlX+4MMnWu1BcK Ej85DfSbvVNk91sRfca3RBN0ggl1y87gQokqIR6IWDybrMSeUf6Bqha9YeMn3OsQ LpkGvAj0sDI= =div2 -END PGP SIGNATURE-
Re: Use of Sleepycat DB
Rob Browning writes: Anyway, this is the motivation for the current discussion. Hope it makes my motivation at least somewhat clearer, even if you're not convinced. I'm convinced. I'd prefer to have the journal entries in a fixed record length append-only text file, but I know I'll never talk anyone into that. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: gnucash 1.3.7 bugs.
How about, as a first step, we make the reconcile window be configurable to use, e.g., 'Funds In' and 'Funds Out' instead of debit/credit as you suggest? Something like that is probably necessary. Gnucash looks to me like one of the crucial tools that will get Linux onto desktops everywhere. But that's going to be a lot harder if "normal" users find the interface confusing. I think it's more important for people to be able to handle their finances without getting confused or worrying about getting things wrong than having the technically correct terminology. What we *have* to avoid is using the technically correct terminology with an incorrect meaning. An option for using informal language is perfectly OK by me, as long as the informality does not consist of using correct words with incorrect meanings.
RE: start of new accounting period
Saving the chart of account is like doing a save without all the transactions. If you add to this saving the closing balances as opening balances you have what is required. You could then save the current state to filename+period and set it read only. Save without transactions and closing ballances as opening as filename. Then load this file. How does this sound? Would it be difficult to make the above changes? Regards, Chris -- From: John Hasler[SMTP:[EMAIL PROTECTED]] Sent: Wednesday, 17 May 2000 12:45 To: [EMAIL PROTECTED] Subject: Re: start of new accounting period Rob Coker writes: Has anybody written code to be able to delete every transaction in every account to prepare for a new accounting period? Wouldn't it be simpler to just extract the chart of accounts and use it to start a new file? In fact, a chart of accounts editor of some sort would be nice. Creating dozens of expense accounts by going pointy-clicky over and over is rather slow. It would be really cool if it also adjusted the opening balance to be the prior ending balance, but that is a nicety. Or extract the closing balances from the old file and insert them as opening balances in the new one. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Use of Sleepycat DB
On 16 May 2000 22:58:45 CDT, the world broke into rejoicing as John Hasler [EMAIL PROTECTED] said: Rob Browning writes: Anyway, this is the motivation for the current discussion. Hope it makes my motivation at least somewhat clearer, even if you're not convinced. I'm convinced. I'd prefer to have the journal entries in a fixed record length append-only text file, but I know I'll never talk anyone into that. That is something that CBB did, at my behest, back in the mid'90s, with regard to logging changes. (I actually once went through and replayed the log through the engine to reconstruct a data file; it most definitely worked.) Feel free to argue for there to be a "monotonically increasing" text file that contains _logs_ of the changes. I'd argue the same; it can go a _LONG_ way towards establishing peoples' confidence in the system. Scenario: "Ah. We can watch exactly what's going on, just by running tail -f ~/finances/gnucash.log And if something goes bad, I can make a copy of that file, take out the offending lines that made GnuCash crash, and load it back in, thus meaning we lost _no_ work..." Note that by doing this, it no longer matters if the "database" data gets stored in some bizarro database format only readable by GnuCash; all we need do is play with the transaction logs, and we can fix the contents as needed. -- `I am convinced that interactive systems will never displace batch systems for many applications.' - Brooks, _The Mythical Man-Month_ (And this does indeed seem true. MVS/CICS systems have *NOT* gone away...) [EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/lsf.html
