Coming soon: gnucash 1.8

[Posted December 4, 2002 by corbet]

When attention turns to what Linux needs if it is ever to attain desktop World Domination, the first thing that comes to mind is usually office suites. But personal and business finance software is also an important part of a desktop system. The state of the art for Linux financial applications has always lagged far behind what can be found in the proprietary world, and that deficit certainly does not help get Linux onto more desktops.

The leading free finance package for Linux is gnucash. LWN has looked at gnucash a couple of times in the past, and your editor has used it for his (depressing) finances for almost three years. Gnucash gets the job done, but it long lacked the features found in commercial finance programs; it has also never been something that could challenge small business packages like Quickbooks. The gnucash developers have not been idle, however; much work has gone into the 1.8 release, which is due to hit the net on January 5. When the 1.7.4 beta release was announced, your editor grabbed a copy to see what the gnucash team has been up to.

gnucash 1.8 will have quite a few new features, including:

Scheduled transactions have long been at the top of the gnucash wishlist. At last, gnucash will keep track of upcoming transactions and help you put them into the register (or do it automatically) when the time comes. The gnucash interface for scheduled transactions takes a little getting used to, but it's highly functional. About the only feature your editor missed is the ability to generate a projection of future account balances based on the scheduled transactions.
gnucash finally understands mortgages and other loans. Combined with scheduled transactions, this feature makes it easy to track loan balances, escrow accounts, etc.
Small business accounting is now part of the gnucash feature set. gnucash will now track customers and vendors, run payable and receivable accounts, generate and track invoices, etc. There is also basic support for per-customer terms and tax tables. LWN is currently looking for a Linux-based accounting package (suggestions, anybody?), so we are highly interested in the new gnucash features in this area. Unfortunately, it does not seem that gnucash is really ready to run businesses quite yet. Documentation of the business features is lacking (though that may be fixed up by the 1.8 release), numerous problems remain (i.e. you can't put your company's address onto invoices in anything but image form), and important features (i.e. payroll) are lacking. But things are heading in the right direction.
Open Financial Exchange (OFX) support - at least for import. gnucash 1.8 also support the Home Banking Computer Information protocol, which is used in Germany. We were not able to test out these features.
Improved documentation, which is now packaged separately. The quality of the documentation is improving, but numerous holes remain.
More and improved reports. You want pie charts, or nice listings of just how much your stock portfolio has lost? gnucash will do them for you better than ever.

As a personal finance application, gnucash 1.8 is truly ready for prime time. All it needs is a few rough edges filed off, and a small set of additional features (i.e. budgeting), and it will be fully competitive with the proprietary packages.

As a business accounting package, gnucash has some ground to cover yet. This is actually an interesting state of affairs: gnucash has had many of the basics, such as double-entry accounting and an (almost undocumented) PostgreSQL backend, for a long time. Conversations with the gnucash developers indicate the the new gnucash business features are the results of a single developer's efforts. Can it be that the free software community is unable to come up with the resources to build a top-quality business accounting package on top of a proven platform? We should be able to do better than that.

gnucash will eventually be able to address the business market - the code has been slowly but steadily getting better for years. In the mean time, there really is no need to use proprietary packages for personal finance; gnucash 1.8 will be more than good enough.

Grammar usage: eg vs ie

Posted Dec 5, 2002 4:45 UTC (Thu) by simon_kitching (guest, #4874) [Link] (2 responses)

Don't you hate people criticising grammar ? :-)

However, this one is getting so prevalent (and LWN is such a shining light of journalism) I can't resist:
(from http://www.jpschoemer.com/MostCommonErrors.html)

e.g., exemplia gratia, means for example;
i.e., id est, means that is to say, and references words synonymous with the preceding statement.

I believe both usages of "i.e." below should be "e.g.":
(i.e. you can't put your company's address onto invoices in anything but image form), and important features (i.e. payroll) are lacking.

The acronym "i.e." implies that the explanation you are making is the only possible explanation, while "e.g." is an example.

If payroll were the only lacking feature, then "i.e." would be appropriate.

Sorry :-)

Grammar usage: eg vs ie

Posted Dec 11, 2002 21:45 UTC (Wed) by Pananix (guest, #8512) [Link] (1 responses)

As I'm a bit of kibitzer myself, so I'll see your grammar and raise you punctuation.

BTW, I only mildly despise people who correct grammar, and only when their punctuation is hosed ;-).

The abbreviations e.g., i.e., et. al., are _always_ followed by a comma. Only your definitions contain the correct punctuation.

If you're going to criticize, it would be best to get it all correct: grammar, spelling, and punctuation. (And depending on your source for punctuation, the comma following the word spelling in the previous sentence is correct -- or not.)

Grammar usage: eg vs ie

Posted Dec 13, 2002 15:48 UTC (Fri) by sl70 (guest, #1585) [Link]

I'll see your punctuation and raise you pedantry.

Technically, there should be no period after the ``et'' in et al., as et (meaning ``and'') is a complete word in Latin. Similarly, etc., back in the old days, was written et c. (with a space and no `.' after et), standing for et cetera (meaning ``and other things''). And if we're going to get REALLY picky (OK, I'm getting really picky), etc. should be used to mean ``and other (inanimate) things'' and et al. (from et alia) should be used to mean ``and other people.'' I find et al. frequently misused where etc. should be used.

Dependencies

Posted Dec 5, 2002 4:46 UTC (Thu) by torsten (guest, #4137) [Link] (7 responses)

Last I read, installing GNUcash meant dependency hell - mostly because of many, varied, necessary libraries that must be installed. I would have preferred mention of these.

I run a minimum system, I don't like to have extra crap lying around. Knowing how much goes into using this package would be helpful.

Dependencies

Posted Dec 5, 2002 9:01 UTC (Thu) by aglet (guest, #1334) [Link] (6 responses)

"Dependency hell" as you call it could also be called modularity and code re-use... the fact that you don't actually have anything else that also uses GNUcash's dependencies is perhaps a shame, but is your disk space really that precious? It is a heavyweight desktop application, after all, not some embedded application.

If managing the dependencies is a problem, take it up with your distribution vendor -- most modern distributions have some mechanism (eg up2date, apt-get dist-upgrade) for dealing with it...

Would you rather have a giant opaque GNUcash package containing specific versions of the libraries it uses?

Dependencies

Posted Dec 5, 2002 9:16 UTC (Thu) by ekj (guest, #1524) [Link] (5 responses)

It *is* a problem. Case in point. I had Mandrake 8.1 and wanted to run the newest gnucash, this was when my distro was maybe 5 months old or so.

urpmi gnucash*

Complained that it needed to upgrade ~25 libraries, about 5 of which urpmi knew of no source for. No problem I said, go ahead. But then it turned out that this would break many of my older applications, so they would *also* need to be upgraded. In principle it should be possible to have two different versions of the same lib, in practice this works sometimes, and othertimes not.

So, to run this one program I would have been forced to:

Locate the 5 missing libraries (i.e on rpmfind.net)
Update the 25 libraries.
Update the ca 100 programs that depended on a particular version of one of these libraries.

All to run this one program. Oh yeah, and I forgot to mention, this only works if *all* of the things from the steps above are compiled with the same compiler. You see C++ is not nessecarily binary-compatible even if compiled from the same sources, it also needs to be compiled with the same compiler. (or atleast a similar one.)

This is not a reasonable amount of effort to put into installing a single program. What it means in practice is that I, and probably very many others, have completely given up on trying out new betas and CVS-versions and suchlike of Gnucash, and instead stick with the version that comes in our distro and "just works". This is a pity, because it reduces the amount of testing a new version gets before it becomes the official one.

Dependencies

Posted Dec 5, 2002 9:59 UTC (Thu) by aglet (guest, #1334) [Link] (2 responses)

Ah, but beta testing is different to just wanting to run the application (which is what I nuderstood the previous poster to be saying). Perhaps you should keep a small "bleeding edge" partition if you can't manage to keep your stable stuff working as well as running recent betas? Maybe a switch in distribution would help -- I drag in a few packages from the Debian unstable & testing distributions into my stable laptop, it seems to work fine...

It might be useful for the GNUcash people to provide giant statically-linked binaries specifically to enable easy beta testing -- this might well increase the exposure & therefore coverage of testing, as you imply.

Dependencies

Posted Dec 5, 2002 12:04 UTC (Thu) by ranger (guest, #6415) [Link] (1 responses)

Debain isn't the only distro out there of course. There's no need to switch distros, upgrading to Mandrake 9.0 should be sufficient, at most the user could add a cooker source to urpmi to install the required libraries (and remove it afterwards, to prevent getting a whole bunch of other possibly semi-broken software).

But, installing the deps on a pre-Gnome2 distro to be able to run a development version of GTK/Gnome software is probably not feasible, at least not without requiring upgrades on much of the software (since many of the dependencies are complex, to allow gnome1.x software to co-exist with Gnome2 may require upgrading Gnome1.x libraries, requiring software depending on those libraries to be upgraded also).

Why doesn't one see this with KDE though, I wonder ...

Dependencies

Posted Dec 11, 2002 23:22 UTC (Wed) by Wilddev (guest, #8514) [Link]

I'm not quite sure what you're implying here, but GnuCash 1.8.0 is a GNOME 1.4 application and doesn't require any GNOME2 libraries. Also as someone actively involved in GNOME I know that GNOME 1.4 and GNOME2 happily co-exist allowing you to run applications developed for either platform as required.

Dependencies

Posted Dec 11, 2002 23:18 UTC (Wed) by Wilddev (guest, #8514) [Link]

I'd like to point out that mdk 8.1 _comes_ with GnuCash 1.6.2. The only dependency problems you should encounter with the new version of GnuCash over the one supplied as part of mdk 8.1 is an upgraded g-wrap library. There is no 25 library upgrade problem. If, however, you are running KDE as your desktop, then of course as GnuCash has currently only a GNOME 1.4 based front end you will need to install enough of GNOME to run it. (a KDE developer has recently started working on a KDE based interface for the GnuCash engine incidentally).
There is quite a bit of misinformation about GnuCash's requirements out there. GnuCash is no more difficult to install with GNOME 1.4 already installed than any of the other GNOME Office applications (Gnumeric, Evolution, Abiword, etc).

Dependencies

Posted Dec 18, 2002 17:54 UTC (Wed) by dbreakey (guest, #1381) [Link]

This is not a library issue, but a packaging issue; unfortunately, I don't think that anyone has come up with a reasonable, usable solution for this. Consider the following:

Most libraries are backwards-compatible, at least to some degree. Developers of these libraries generally, as far as I can tell, try to ensure that libraries sharing the same major release number remain backwards-compatible.
Your distribution vendor is putting their reputation on the line by packaging everything together to provide a working system.
Your distribution vendor probably just doesn't have the time (most don't) to verify that earlier library versions still work with the latest and greatest version of any given application. Sadly, most vendors probably don't even have enough time to rely on the release notes to tell them this either.

Therefore, in order to continue producing a distribution that meets their desired level of quality (whatever that might be), most vendors only spend their time testing and validating the latest—or at least whatever point on the curve they want to be at; some vendors prefer to hang back a bit from the absolute latest sutff, while others like to live on the bleeding edge—releases of any given application.

The downside to this is that users, in order to upgrade to the latest version of one particular application, may be required to upgrade a large portion of their system in order to satisfy dependancies—dependancies which are determined by the vendor and hard-coded into the package information.

If you don't want to do this, you may want to start using one of the increasing number of "build from source" distributions, which will probably give you far more control over the exact content of your system.

Gtk2 planned for 1.9.x?

Posted Dec 5, 2002 5:31 UTC (Thu) by Strike (guest, #861) [Link] (1 responses)

I know that this is sort of a more "minor" issue, but when is the GTK2 port scheduled? Does anyone know? Yes, I realize that for now, GnuCash is concentrating on catching up in the feature arena. But, for those of us who are perfectly content with its feature set, it might be nice to begin down the path that all the other big GTK/GNOME apps (Evolution, Galeon, GIMP, XChat, etc.) have started down - the GTK2 port path. Granted, Evolution hasn't officially started porting yet (at least, there's no 1.3 branch in CVS that I know of ... yet), but it has been announced as their intent. In fact, it's their sole intent for this branch.

Gtk2 planned for 1.9.x?

Posted Dec 11, 2002 23:24 UTC (Wed) by Wilddev (guest, #8514) [Link]

GNOME2 development will start once we have completed work on 1.8 probably early next year.

Everyone who is fluent in Scheme, raise your hand...

Posted Dec 5, 2002 6:03 UTC (Thu) by dank (guest, #1865) [Link] (4 responses)

The editor asks why few people are contributing to GnuCash.
One possible reason is it's largely written in Scheme,
a language known by few. The GnuCash crew all love Scheme
and would rather quit the project than use any other language.
Result: a program nobody has much of a chance of understanding.
I do wish them well; perhaps they will singlehandedly save
Scheme from oblivion.

Everyone who is fluent in Scheme, raise your hand...

Posted Dec 5, 2002 9:06 UTC (Thu) by aglet (guest, #1334) [Link]

*raises hand*

The Sawmill window manager is also a heavy user of Scheme. And Emacs Lisp is not hugely different. I have no idea how many bazillion lines of Emacs Lisp have been written....

Incidentally, anyone wanting to learn Scheme could do worse than fiddle with either Sawfish or Emacs, alternatively if you prefer books pick up a copy of the MIT textbook "structure and interpretation of computer programs".

Everyone who is fluent in Scheme, raise your hand...

Posted Dec 5, 2002 16:10 UTC (Thu) by jschrod (subscriber, #1646) [Link]

/raise my hand.

Don't need gnucash, though.

Joachim

Everyone who is fluent in Scheme, raise your hand...

Posted Dec 5, 2002 20:48 UTC (Thu) by jdavisp3 (guest, #4881) [Link]

This is a very common misconception about GnuCash.

There are pieces of GnuCash, such as reports and graphs,
which are written in Scheme, but there are also very large
pieces, inluding much of the GUI, written in C. There are
far more lines of C in GnuCash than there are lines of Scheme.
You can contribute a lot to GnuCash without knowing any Scheme.

Everyone fluent in C raise your hand...

Everyone who is fluent in Scheme, raise your hand...

Posted Dec 12, 2002 0:14 UTC (Thu) by conrad_c (guest, #8516) [Link]

As others have pointed out, large chunks of the application are coded in languages other than scheme. But even if that wasn't the case, is coding the only way to contribute?

Hands up all those fluent in a real-world language, like, say English (or even American.. :-)).

Our docs can always use an extra pair of eyes (although the current docs developer is doing a fantastic job). And theres plenty of translation work to be done.

Coming soon: gnucash 1.8

Posted Dec 5, 2002 9:24 UTC (Thu) by zitran (guest, #5254) [Link] (3 responses)

To your question:

"LWN is currently looking for a Linux-based accounting package
(suggestions, anybody?)"

Have a look at sql-ledger.org. This one is written in perl and a lot
seems to be going on here. Current version is 1.8.7 but 2.0 is scheduled
for release in mid December.

sql-ledger is browser operated, features multiple user support with
individual rights and is based on PostgreSQL, with options for Oracle
available and DB2 in the "tube".

The program has been localised to quite a few languages and countries. We
are ourselves just installing it for production use and have added a few
things to it as well (Finnish localisation with DES-crypted bank
connection, Finnish standard chart of accounts as well as P&L and Balance
statements according to Finnish accounting legislation (these are quite
structured)

The feature I miss most is payroll, which I hope will start developing
soon.

Best rgds

Paul Saris

Coming soon: gnucash 1.8

Posted Dec 12, 2002 7:46 UTC (Thu) by Kluge (subscriber, #2881) [Link]

I don't know anything about business accounting, but the people at Linuxworld (www.linuxworld.com/site-stories/2002/0225.xterminal13.html, www.linuxworld.com/site-stories/2002/0311.xterminal14.html) seem to think that NOLA (nola.noguska.com) is good enough to consider for their own use.

Coming soon: gnucash 1.8

Posted Dec 12, 2002 18:13 UTC (Thu) by joib (subscriber, #8541) [Link]

In addition to sql-ledger (which is quite nice) there is also compiere (www.compiere.org). It is based on java, and unfortunately requires oracle. But they're working on a postgresql port, due 1H2003.

Compiere is more like a full-fledged erp application, it includes lots of stuff besides accounting.

Then there's also gnu enterprise (www.gnue.org), which is more like an appserver+form builder etc, but they plan to include an accounting package eventually.

Coming soon: gnucash 1.8

Posted Dec 17, 2002 21:11 UTC (Tue) by palin (guest, #8654) [Link]

SQL-Ledger 2.0 is already out.

Too much accounting, too little budgetting

Posted Dec 5, 2002 14:16 UTC (Thu) by nstraz (guest, #1592) [Link]

I tried GNUcash recently and I don't like how everything is pushed into accounts. I want to track my existing bank accounts and loans, not manage a ledger for a small business. I want to look into the future to see what my cash flow will look like when I have to take unpaid time off. I haven't been able to find an application like this on Linux yet.

I'll make one recommendation. Make it easier to import data! It's a real pain to categorize a year's worth of transactions. If I could look at the list of transactions in detail and "paint" the transactions from a palette of categories it would make it much easier to get started.

Tried Quasar Accounting?

Posted Dec 5, 2002 14:26 UTC (Thu) by Webexcess (guest, #197) [Link] (1 responses)

I've been testing the free-beer version of Quasar Accounting (www.linuxcanada.com), and I like what I've seen so far. The commercial version includes a POS interface and inventory tracking system -- two very desirable features.

Is there anything this complete in the FS/OSS world? Has anyone had any good/bad experience with this software?

Tried Quasar Accounting?

Posted Dec 18, 2002 14:37 UTC (Wed) by diacobel (guest, #8666) [Link]

I have been running Quasar for over a year now and love it. I cannot wait for v1.3 to come out.

Coming soon: gnucash 1.8

Posted Dec 5, 2002 15:00 UTC (Thu) by mcatkins (guest, #4270) [Link] (4 responses)

One thing that hasn't been mentioned, as far as I've seen, is
that until gnucash supports VAT, it won't be even on the list for
consideration for most companies here in Europe. This is *much*
more important for me than, say, payroll.

I am, of course, assuming that VAT hasn't been added in this new
release - but it isn't mentioned in the review :-)

I just wish *I* had time to add it... :-(

Martin

WHAT IS VAT?

Posted Dec 5, 2002 16:20 UTC (Thu) by smoogen (subscriber, #97) [Link] (2 responses)

Sorry for the lack of info in a post ,but what is VAT?

WHAT IS VAT?

Posted Dec 5, 2002 16:31 UTC (Thu) by a9db0 (subscriber, #2181) [Link]

VAT is the acronym for Value Added Tax, which is levied widely across Europe.

WHAT IS VAT?

Posted Dec 6, 2002 14:24 UTC (Fri) by nowster (subscriber, #67) [Link]

Sales tax, which unlike in the US, is the "label price" of a product.

Businesses can recover the VAT they pay for goods and services against the VAT they pay to the tax man on goods and services that they sell.

Coming soon: gnucash 1.8

Posted Dec 11, 2002 23:26 UTC (Wed) by Wilddev (guest, #8514) [Link]

I'm not sure if VAT has additional requirements over the US state tax requirements, but it should be very easy with the new small business module to track VAT.

GnuCash and QIF import/export

Posted Dec 5, 2002 18:54 UTC (Thu) by scripter (subscriber, #2654) [Link] (3 responses)

QIF import/export is an important, and lacking feature of GnuCash (as of version 1.6 or so -- I don't know about later versions).

I tried using GnuCash during the 1.5 and 1.6 days. In the past, I used CBB to do my personal finances, but it was degrading with updates to my OS, and it ran too slowly with my data.

I exported my data from CBB into a QIF file, and attempted to import it into GnuCash. It didn't work well. After I had added some new transactions, and decided that I wanted to move to something else, I found that GnuCash couldn't export the data into a QIF file.

I'm used to proprietary packages holding my data hostage. In this case, GnuCash held my data hostage, and I ended up abandoning the data.

GnuCash and QIF import/export

Posted Dec 11, 2002 20:44 UTC (Wed) by zImage (guest, #8511) [Link] (1 responses)

<quote>
I'm used to proprietary packages holding my data hostage. In this case, GnuCash held my data hostage, and I ended up abandoning the data.
</quote>

The data was in XML format which is quite easy to read and change and do stuff with. This is not the same as, for example, a doc file which is a closed and quite secret file format. Just because gnucash wouldn't export the data to your file format of choice, doesn't mean it held it hostage. Gnucash set your data free. You're the one who wanted to tie it up again.

GnuCash and QIF import/export

Posted Dec 17, 2002 23:36 UTC (Tue) by whelk1 (guest, #3293) [Link]

.DOC is proprietary, but not secret.

GnuCash and QIF import/export

Posted Dec 11, 2002 23:29 UTC (Wed) by Wilddev (guest, #8514) [Link]

We are planning a data export function for sometime in the 1.8 release series. Its not there yet but definately planned.

Coming soon: gnucash 1.8

Posted Dec 12, 2002 13:38 UTC (Thu) by jpmcc (guest, #2452) [Link]

"ThinSoft Accounting consists of seven robust modules with unique functions that integrate with the system as a whole. This creates a complete package for all of your firm's accounting and distribution needs.
"ThinSoft is now free and in the process of being converted to OpenSource. It will be the first Enterprise Accounting System in the world that is OpenSource."
From the Thinsoft website.

Accounting Package for LWN

Posted Dec 17, 2002 16:25 UTC (Tue) by km4hr (guest, #8644) [Link]

You say LWN is looking for an accounting package? I have installed and recommend SQL-Ledger. (See sql-ledger.org). This package is in regular use in our small family business. Other users are listed on the sql-ledger web site. Comments from an accountant working with the family business indicate the package is comparable to expensive professional products.