GnuCash Project Goals

The people behind GnuCash aim to create a world-class GPL'ed Open Source Personal Financial Application for GNU/Linux and other Unix's. This page aims to review some of the technical and development issues surrounding this product, to be a kind of 'FAQ' for developers and contributors. To get a better idea of what GnuCash is and what it does, visit it's home page.

There are currently several different versions of GnuCash. The current stable, production release is gnucash-1.2.x and is Motif based. However, development has all but switched entirely over to Gnome; the Motif version will probably eventually fall to the wayside. (Note that other versions, such as KDE, Java or PalmPilot have been discussed and/or started. More about this below). The latest Gnome version, and any latest version in general, is currently available only via CVS. There are precompiled versions available, but these are usually only for the stable releases. Don't use the unstable versions unless you are looking for excitement and adventure.

This document is divided into several sections. The first deals with archititectural and philosophical design issues. The second deals with interesting technologies. The third deals with desirable features and functions.

Architectural Goals

There are some over-reaching design principles and philosophies that we hope to maintain. Some of these concepts and terms are introduced in this section.

First, one must maintain a clean separation between the data structures and the GUI that manipulates them, along the lines of a Model-View-Controller paradigm. Lists of accounts and the transactions in them can be thought of as a representation of financial data, a Model. The GUI that adds, modifies and deletes these should be thought of as a manipulator of the data, a Controller. The Motif or Gnome GUI's are just two possible manipulators of the data; others, based on e.g. Qt/KDE, emacs, Java applets or Java servlets should be possible.

The View of the data is a subset or slice of the data described by the Model. The View may consist of only the transactions for the month of May, or only the account totals for certain accounts. The View is used in part to generate the reports and graphs, but it is also that which the Controller interacts with.

However, GnuCash also needs to deal with multiple distributed data sources: stock quotations from the net or transaction confirmations from online banks and brokerage houses, or more mundane sources, such as file imports, or merger of data from several users. In this language, the concept of a global Model-View is dated, and somewhat inappropriate. Rather, one is worried about how data is represented in the local address space of the GUI, how the GUI manipulates it, how date is brought in and merged from external sources, and how that data is again output, whether to a file or a local or remote database. Thus, the View is essentially a local data cache: its the data that is immediately present and being displayed, reported, and manipulated. The Model is the abstraction of that data that the GUI (the controller) can act on.

In GnuCash, the Model is implemented via the Engine API, and the View is the data that is currently in the Engine. Thus, the Engine is a set of programming API's that the GUI (or a script, or even a clever command-line-addict) can use to manipulate the data. Currently, the Engine is fairly poor, and matches the data types and formats that the GUI can manipulate. These include transactions, transaction entires (splits), accounts and account heirarchies. The Engine has a very simple apply/commit model, and a simple query mechanism for generating reports and views. The Engine currently handles only a small set of data sources: it can import and merge in QIF's, it can read and write its own binary byte stream, and can get stock quotes from the net. However, since the Engine is meant to be the interface between the GUI and the financial data, it is meant to be able to do much more.

In particular, it should be possible to back the Engine onto an SQL dataabase, and thereby enable multiple users and/or intrface to more complex accounting ssytems. The engine should also be expandable to handle other sources of data, such os OFX, Integrion GOLD, the Open Trading Protocol, the OMG CORBA General Ledger submission, the IBM San Francisco business objects, or closer to home, Linux Kontor. In particular, it should be possible to use GnuCash not only to view data from these sources, but also to manipulate it and send it back.

The above structure then leads one to view GnuCash not so much as a tightly integrated application, but a loose federation of parts objects, libraries and interfaces. In order to facilitate the glueing together of these parts, as well as simplify the questions of customizablity, change and rapid development, GnuCash makes use of an extension language to glue the pieces together. The extension language that is most central to Gnucash is Scheme, although some of the interfaces are also available through Perl.

Under construction

The stuff below dates back to Summer 1998 and is hrribly out of date.

Feature Requirements

Create both a personal-financial accounting system, as well as a business accounting framework. Although these two goals may seem at odds with each other, there is no reason why they could not share a considerable amount of framework. The goals of a personal finance system is a system that is easy to use, has a simple yet powerful menu system, provides graphs, charts, and interfaces to on-line banking and stock systems. The goals of a business system is multi-user capabilities built on an SQL database and/or CORBA objects for multi-user use, with support for inventory control, shipping & receiving, billing, accounts payable & receivable. A pie-in-the-sky system might even include interfaces to on-line shopping carts, credit-card clearing interfaces, or even a subset of SAP R/3 (TM) functions. Note that all of these systems require at their base both a strong model of a "financial transaction", as well as a ledger window, and a report generation mechanism. The tools created to allow one should be portable enough to be deployed in the other application as well.

Features and Functions

Graphs, Reports
Add the whole host of reports, including Net Worth statements, Balance Sheets, and Profit & Loss statements. These should be printable: it might be best to create them as ordinary HTML pages, and use the printing abilities of the browser. In an ideal situation, the user should be able to create custom reports.

Other output format possibilities include SGML and XML. In the long run, these are preferable to HTML, since DSSSL and Jade (James DSSSL Engine can be used to convert to RTF, Postscript, etc. XML is the wave of the future.

The Report Generator should be a "dockable" subsystem of the whole. Thus, it should be possible to run the report generator in a stand-alone, read-only fashion without having to start up the main application.

Graphs, charts, etc. too ...

One hard part of reporting is designing a configurable interface, so that people can build custom reports.

Status:

Web Site Maintenance & Marketing
Put together an active, relevent web site. Mailing list archives. Screen shots. Announces on c.o.l.a, freshmeat. Put minor news items, etc. on web site news. Bug tracker. Maintain repository of co-requisite tools & packages.

Status:

OFX support
Provide the SGML DTD parsers to handle the OFX reports that many banking institutions are providing, or will soon be providing, to retail customers. See below for OFX references. OFX is an open spec from Microsoft, Intuit, & Checkfree, and will be supported by Integrion. The OFX DTD's are included in the 1.1 distributions. See OFX HomePage for details.

Status:

Budgeting
Ability to handle budgeted future transactions.

Status:

More ...

User Interface Ports
Port the package as a whole to gtk/gnome, Qt, Emacs.

Status:

Internationalization
All menus, markup and help-text should be internationalized, so that GnuCash could be usable in any country. This would include the printing of currency values in the local country conventions.

Current status:

Icons, Glitz, Icons, Glitz
A set of pretty icons and button pixmaps should be created for minimized windows, and for the various buttons. A user-configurable button-bar would be nice too. This should probably be coupled with the creation of an X resource file, which does not currently exist.

User Preferences
Create menu system & file format for manipulating user preferences. Preferences include things like showing/not showing categories, forcing double-entry, etc.

Current status:

Categories
Provide a default list of "Categories" (Income/Expense Accounts). These are categories such as "Automobile Expense", "Bank Interest Income", and "Employment Income". The user should be able to select a default set of accounts, and have those be created. To actually implement this, it might be best to simple create a file with these in them, and load that file. A mechanism should be provided to allow the user to weed-out the unwanted accounts without hampering their ability to use them at a later date, if desired.

Current status:

Recurring Transactions
Add support for automatic, recurring transactions, e.g. mortgage payments, fixed-interest bonds, bank accounts, etc. Note that the design for this could be very different, depending on whether the multi-user functions are available or not. Note also, maybe the engine needs to support two dates per transaction: expected, and actual ?? Current status:

Navigation
Menu navigation using the keyboard should be possible. Although menu mnomenics exist, they seem to be broken. Similarly, tab-key navigation should be possible. Currently, it is possible to use the tab key to navigate from field to field in the register window, to user arrow keys to navigate menus, and quick-fill to automatically complete fields. However, it is not possible to tab over to the "Commit" button. It should be.

Folder Tabs
Currently, Income/Expense accounts can be shown or hidden by selecting from a menu. It would be nice to be able to examine different account types (Asset, Liability, Income, Expense, Payables, Receivables, Inventory) by selecting a tab folder.

Fly-Over Help
When the user pauses the mouse over a button, "fly-over" pop-up help windows should appear.

Simplified Stock Ledger
Stocks and Mutual funds are handled by placing them each in their own account. Each account can be viewed individually. If all of the stock accounts are children of a master trading account, then the trading account can be viewed and modified in a General Ledger window. The current stock general ledger window is a bit obtuse, and difficult to understand and use. A simplified but still powerful ledger window is desperately needed.

Forced Double-Entry
The system supports double-entry: every transaction indicates a pair of accounts: one is debited, and one is credited. Double-entry is a powerful way of ensuring the integrity of of the financial data. Currently, while double-entry is supported, its use is not forced: the user can create dangling transactions, where only one account is indicated. Although this is acceptable for home use (even desirable, since it allows the casual user the simplicity they desire), it is not acceptable for business use. It must be possible to enable forced-double entry, so that a transaction cannot be completed until two accounts have been specified.

Current status:

emacs, vi, motif, kde, gnome Key Bindings for Text Fields
Make sure that text fields can handle the vi & emacs key bindings, so that e.g. emacs-style ctrl-a, ctrl-k does the right thing.

Bonds & Interest Bearing Instruments
Support should be added for Mortgages, Bonds, CD's and other instruments (e.g. savings accounts) that pay interest on a regular basis. It should be possible to specify the interest rate, the payment schedule, and other regularly recurring transactions.

Household Assets
Add an example showing how regular household assets (house, car, jewelry, etc.) should be treated. In particular, show how appreciation and depreciation should be treated.

Inventory, Job Costing
Add the business features needed to maintain a stock of items for sale, estimating jobs.

Payables & Receivables
Add features to track sales receipts and other pending sources of income, as well as owed sums.

Check Printing
Create a check-printing ability.

Locks
When splits are implemented, and the parent transaction has been marked as cleared, the record should be locked, so that further modifications to the amount can't be performed (or at least, a warning is generated. This prevents accidental garbaging up of old transactions.)

Grayed-out Form Help
Create grayed out entries in the ledger, titled "Memo", "Description", etc, helping users understand what should be typed into each field.

Accounting Periods
Ability to permanently lock records as non-editable. This should be straight-forward by using the "reconciled" field to hold "locked", and not allowing the GUI to edit locked records.

Quicken(TM) Export
Ability to export Quicken QIF files. Quicken import is implemented and mostly works. (Note: Quicken import worked in v 1.0, but got slightly broken in v 1.1 It no longer merges duplicate transactions when importing two or more QIF files. This should be easy to fix, as the "merge" routine is there in the code somewhere; its just not called because it was never restructured for the vv 1.1 engine.)

Transaction Window Fixes
The transaction window should allow the user to specify a share price (when purchasing/selling shares) as well as the load and/or fees associated with the purchase. Fees, of course, are handled as separate transactions: however, it should still be possible to specify the fees, the transfer, and other details from a single window.

Status: Some basic reorganization of register was done to support mixed multi-line split display. However, the actual display of such things remaions unimplemented.

Tab-delimited ASCII file format
People *like* to be able to read file contents in ASCII. There are many Unix tools for manipulating ASCII. An ASCII equivalent of the current file format should be easy to develop ... just substitute the writes with printf's. The tab-delimited format should be compatible with that of /rdb. The /rdb format is like so: 
    field-name  tab  fieldname  tab fieldname   \n
    ------------------------------------------  \n
    value       tab   value     tab value       \n
    value       tab   value     tab value       \n
    etc ...
Its a very simple, very basic flat table format. It should match the SQL schemas in order to minimize I/O complexity and incompatibility.

Volunteers

Your name here as project contributor! This list only mentions some of the recently active developers; many, many others have contributed fixes and patches both large and small. I've tried to credit them in the README.

References

Draft version 0.25 -- October 1998
Linas Vepstas linas@linas.org