GnuCash (formerly X-Accountant) Project Goals
GnuCash
(previously known as X-Accountant) is a personal finance
accounting application. The project goals are to create a world-class
GPL'ed Open Source personal financial application for GNU/Linux and other
Unix's. The project is the result of a merger
of the GnoMoney project with Xacc development. There are currently
two versions: xacc-1.0.18, and xacc-1.1.x. The version 1.0.18
is written in Motif, and is considered to be stable/production quality.
You can read more about X-Accountant at its home page
http://www.cs.hmc.edu/~rclark/xacc/index.old.html.
The GnuCash pages
provide overview & introductory material about GnuCash, and in
general present a glossier, more accessilbe format. This page is
aimed at developers, not users.
The version 1.1.x is *unstable* (may not even compile), and is in
active development. This page attempts to describe the current
goals & status.
We believe that a GNU GPL project should provide goals and motivations
at both the large and the small scales, in order to focus and motivate
the developers. Over-arching and grand goals are difficult to grasp
and carry out; yet their lack serves only to dissuade the grand
thinkers. A list of detailed goals may be mind-numbing to the casual
reader; yet, without them, the roll-up-your-sleeves-and-do-it
coder cannot know where to begin. Detailed goals lend a concreteness
to the discussion: they can be architected, designed and coded at any time
by coders of any ability. Thus, we present a list of goals, large and
small, with the hope that the small goals will fall quickly, and the
large ones shall turn into a multitude of small ones.
News
- September 1998
- Version 1.1.18 is begining to get stable; most things work the way they're
supposed to. New features include variety of ways of viewing an account,
a simple query engine, and support for multiplecurrencies.
- April 1998
- The domain "gnucash.org" has been registered; web site is up.
- 10 April 1998
- Work on OFX support, and user-prefrences, has begun in earnest.
- 10 March 1998
- Source is available with CVS. See instructions at bottom.
- 4 March 1998
- The folks involved with
WaterMark,
GnoMoney,
and
X-Accountant
have tentatively agreed to join forces to work on a unified
personal-finance project. Subscribe to the xacc mailing list
for more info.
Meta-Architecture Goals
-
Create and 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 current Motif GUI is just
one possible manipulator of the data; other GUI's,
some simple, some complex, some possibly based on other graphical
toolkits (Qt, gtk, emacs) should be possible.
The View of the data is a modern way of saying "report".
One typically does not view, or want to view all of the data,
but only a subset: say, only the transactions for the month of May,
or only the account totals for certain accounts. The concept of "View"
in fact consists of two very separate ideas: the Query Engine
and the Report Generator. The Query Engine is used to extract
a list of transactions from the Model database, based on a set of dates,
a set of types, or other criteria. This list is then typically
edited by the controller, or possibly printed. The Report Generator
is used to create summary reports about average account balances,
or profit&loss statements, or cash-flow statements, or may be graphed
as pie charts of asset allocations, or graphs asset value over time.
-
Create a mechanism for obtaining data from multiple financial sources.
Currently, GnuCash stores data in its own file format; it can also
import Quicken(TM) QIF files. However, other sources & sinks of data
might be stock-quote web sites, on-line banking interfaces such as OFX,
access to SQL databases, such as those of Linux-Kontor, or CORBA interfaces,
such as the GL Ledger submission to the OMG. It should be possible to have
any of these at as data sources, and with the appropriate security mechanisms,
it should also be possible for a user of GnuCash to manipulate the data
at the other end.
In particular, with respect to OFX & online banking, one should be able to think
of GnuCash as a very special browser, capable of browsing financial web sites.
Instead of talking HTML/HTTP, it would talk OFX or Gold with the remote
server. Besides just statically viewing ones bank account, it should also
allow bill payment and other account manipulation.
-
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.
Concrete Architectural and Development Goals
The following is a list of the larger, more abstract, and more difficult
architectural goals.
- 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.
Graphs, charts, etc. too ...
One hard part of reporting is designing a configurable interface,
so that people can build custom reports.
Status:
- Simple HTML output is implemented. GnuCash will even act as a one-shot
web server.
- 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. Gui glitz. Packaging.
Status:
- Jeremy Collins put together the initial web site.
- Volunteers needed to put together mailing list archives, etc.
- 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:
- Work on an OFX DTD parser has begun. headers generated
correctly. Constrcutors generated almost correctly.
Parser work done by Linas.
- Simple scripts have been run against real-live OFX servers.
Ueli Rutishauser
has been able to do e*trade transactions to a real account.
- Budgeting
- Ability to handle budgeted future transactions.
Status:
A design doc has been started.
- Ledger Widget
- Create a more powerful ledger widget. Currently, the X-Accountant
uses the powerful XbaeMatrix widget to display the ledger windows.
This is a good widget for displaying and maintaining tables.
However, it could, and should, be further customized to handle
the needs of accounting use. Thus, it should be possible to
designate cells as being date cells, and provide completely
automated handling of date entry within these cells. Similarly,
it should be possible to designate monetary cells which can handle
input. General text fields, for the description and the memo,
should be endowed with quick-fill abilities, allowing completion
by comparing the current types text to previous entries. Finally,
there should be pull-down (combo-box) cells that can contain
pull-down item lists. Each of these functions are currently
implemented in X-Accountant; however, there is no separation between
these features and the specific accounting functions. A clean
separation would make the design and implementation of new ledger
windows much simpler and easier.
Current Status: the latest beta-development releases (version
1.1.x) contain such an object.
- Currently Motif-based
- GTK port mostly work, but is hung up on the inadequacies of
underlying table widget.
- No Qt port yet of the register.
- the simple single-account ledgers (incl. stock ledgers) seem
to be working correctly, but no heavy testing yet.
- The multiple-account ledger is very broken.
- The multi-split ledger seems to work. One can display
one line per transaction, two lines per transaction, one line
per split, or a dynamic-expansion version of these.
- GTK version published, thanks to Rob Browning.
(other comments above are for motif version).
- No curses or emacs version yet.
- Taxes: For handling e.g. new zealand GST tax (12.5%) or british VAT,
it would be enough to add a checkbox to say y/n, add tax ...
(of course other schemes would be more sophisticated.)
- Linas Vepstas is handling the "GUI-independent"
parts of the register, as well as the Motif code.
- Ted Lemon <mellon@hoffman.vix.com>
is creating/fixing/extending
the underlying gtk widget to have the features that GnuCash needs.
- Engine, Financial Objects
- The current system makes a distinction between the data (account,
transaction) and they GUI that displays it. The data is embeded
within and controlled by the "Engine", which is a set of routines
to access accounts, transactions, etc. The flexibility and features
of the engine can be improved, and in particular, the sophistication of
the query generator, and the level of multiple-currency support.
But possibly the most important task is to review the paradigm
and adjust it to bring it in line with a transaction-processing
model.
Current Status:
- The basic engine has been detangled from
the GUI elements, as of version 1.1.4.
- Binary file I/O mostly detangled into a separate module.
- Prototype for transaction logging in place
- Backup files automatically created & timestamped.
- BeginEdit()/CommitEdit() routines mostly in place,
These "Transaction processing constructs"
should simplify creation of an SQL back end.
- Multiple currency support is shaky.
- Query engine is minimal/sparse in capabilities.
- Linas is handling the engine code.
- Extension Language Support
- Currently, the application is wired together entirely with
C code. A goal of the project is to replace this wiring with
a highly-configurable extension-language interface.
The overall architecture is envisioned to be as so:
All code, including the transaction engine, the file I/O routines,
the menus, and the ledger, will be abstracted into
compact modules that can function independently of each other.
At the highest level, there will be a infrastructure with
extension language interfaces that will "wire together" the
various modules.
Such "wiring together" will consist of a dispatch infrastructure
that will allow arbitrary menu entries to be hooked to arbitrary
modules. The configuration for menu entries, and thier associated
callbacks, will be specified in an ext-lang configuration file.
At the final stages, it is hoped that new modules can be imported
without requiring that the application itself be recompiled & relinked.
Status:
- Work has begun.
- The transaction engine interfaces are avaialable via
SWIG.
- The main loop is controlled by the Guile scheme interpreter.
- Rob Browning is the reigning expert.
- Multi-user Support
- Multi-user support should be added with either an SQL backend
to the engine, and/or through CORBA interfaces to the engine.
Project Kontor and also FreeMoney is working on SQL schemas;
Kontor is also working on Java RMI/CORBA interfaces.
The following industrial-strength features are still needed:
- transaction-oriented queuing of updates
- event subscription channel for updates
- user authentication
- user authorization
- non-repudiability
- encryption of network connections
- SQL I/O
- A module is necessary to allow data to be fetched from an SQL
database, and for that database to be updated. Some thoughts:
SQL databases do not need to be locked during editing: instead,
an optimistic approach, similar to that employed by CVS (concurrent
version system, a mechanism for storing versions of source code)
could be used: if the edits conflict with changes made by others,
the edit could be rejected en-masse, allowing the user to merge and
correct their changes. This is a very important note: updating
SQL does NOT require locks to be held for long periods of time!
Incremental Development Goals
The following is a list of goals and "bug fixes" that should be solved
immediately, independent of the major goals.
- User Interface Ports
- Port the package as a whole to gtk/gnome, Qt, Emacs.
Status:
- Jim Pick <jimpick@jimpick.com> may be working on an emacs version...
- Daniel R Risacher <magnus@alum.mit.edu> is taking over the overall
gtk/gnome work from Jeremy Collins.
- Qt code submitted by ...
- 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:
- Most English-language messages have been
#defined and moved to a single header file. (messages.h)
- Plan to use gnu gettext() for the message catalogues.
- Looking for routines that can parse and print
monetary values in different formats, as well as date/time
parsing/printing routines. (gnucash contains such parsing
routines, but they're not very powerful or i18n'ed.)
- Henning Spruth has translated the README into German.
-
- 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:
- Rob Browning has put together a basic infrastructure
that unifies command-line flags with sceme-based config files.
- 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: there exists the ability to merge
accounts from multiple files, and the ability to hide/show
Income/Expense Account types.
- 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:
- Design Doc contributed by Bob Drzyzgula
- 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.
It should also be possible to sweep through the date, and find all
dangling transactions.
Current status:
- The engine has a couple of flags in it that control this;
however, they are compiled in, there is no way to change them
from the gui.
- 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.
Status
Well, just to show that we are getting things done.
- Getting Source with CVS
- A read-only version of the cvs tree is available on the net.
To access it, first, login, as so:
cvs -d :pserver:cvs@linas.org:/home/cvs/cvsroot login
The password is "guest". To get a copy of the source, do a
cvs -d :pserver:cvs@linas.org:/home/cvs/cvsroot checkout xacc
Note that various versions can be accessed with tags.
For example, the tag xacc-10b17 will get you version
1.0.17 and the tag xacc-11b6 will get you version 1.1.6
In particular, the latest code in the 1.0.x series (the stable series)
is available on the branch xacc-10-patch. For historical
record, you can view Robin Clark's original source from October 1997
at xacc-09a. Things have changed a *lot* since then.
(March 1988)
- Version 1.1 Alpha
- The Alpha development version 1.1 is out. Features include:
- Data engine cleanly separated from GUI
- Redesigned register infrastructure will make it much easier to
create new/customer register displays, and to port to other GUI's.
- Splits have been added to the engine; the GUI does not yet expose them.
- Source available via anonymous CVS
- Work on GTK ports have begun (thanks to Jeremy Collins & Rob
Browning)
(January 1998)
- New Improved Web Site
- A spiffy web site for all of this is needed, with good graphics and
exciting text!! A mailing list, mailing list archives, and a live
CVS tree are all bonuses. (December 1997)
- Splits
- When performing a transfer, it is well-useful to allow the transfer
to be "split" between several accounts. To implement a split,
the best direction might be to have each transaction be a pointer
to a set of splits, with each split having it's own distinct
credited account, memo field and currency value. Suggestion is to
leave the debited account pointer in the main transaction, and have one
credited account pointer in each of the splits. Also, suggest
leaving a "cleared" flag in the main transaction, *and* putting a
separate cleared flag in each split as well. This allows the
cleared flag to be independently set for both the debited & credited
accounts.
Status: Essentially more-or-less done (July/August 1998)
Misc Bugs
- Allow command line to specify qif
- motif -- register colors are bogus
- place num trans in account in the main window.
- cbb-export.qif seems to come in with the wrong sign
- Ability to change bank account name -- check for prexist & merge?
- ability to reparent bank account,
- ability to merge accounts
- ability to change account type.
Volunteers
Your name here as project contributor!
- Linas Vepstas is maintaining the current GnuCash
and is attempting to coordinate the project work.
- Jeremy Collins , originated the GnoMoney
project, created the intial GTK port, and set up the GnuCash web site.
- Rob Browning (rlb@cs.utexas.edu)
ex-cbb'er, has ported the register to gtk, built a generic preferences
infrastructure, got the extension language pieces to work.
and has done some work on a GTK-based graphing package.
- Robin Clark wrote the *original* X-Accountant,
which was later renamed as GnuCash.
- Daniel R Risacher is working on a
GTK ledger/register/spread-sheet infrastructure.
This list only mentions the currently active developers; many, many others
have contributed fixes and patches. I've tried to credit them in the README.
See also Merger
References
Draft version 0.24 -- September 1998
Linas Vepstas linas@linas.org