mirror of https://github.com/Gnucash/gnucash
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
728 lines
32 KiB
728 lines
32 KiB
<html>
|
|
<head>
|
|
<title>GnuCash Project Goals</title>
|
|
<meta name="description" content="The Linux GnuCash
|
|
project aims at creating a world-class personal finance package.
|
|
Goals include ease-of use, double entry, OFX support, charts,
|
|
and reports, and multi-user support.">
|
|
|
|
<meta name="keywords" content="linux, ofx, accounting, finance,
|
|
financial, ledger, double entry, GPL, gnu, corba, gnome, Qt, Motif">
|
|
</head>
|
|
|
|
<body bgcolor="#eeeeee">
|
|
<h1>GnuCash Project Goals</h1>
|
|
|
|
The people behind <a href="http://gnucash.org">GnuCash</a>
|
|
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 <a href="http://gnucash.org">GnuCash</a>
|
|
is and what it does, visit it's <a href="http://gnucash.org">home page</a>.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
|
|
|
|
<h2>Architectural Goals</h2>
|
|
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.
|
|
<p>
|
|
First, one must maintain a clean separation between the data structures
|
|
and the GUI that manipulates them, along the lines of a
|
|
<b>Model-View-Controller</b>
|
|
paradigm. Lists of accounts and the transactions in
|
|
them can be thought of as a representation of financial data,
|
|
a <b>Model</b>. The GUI that adds, modifies and deletes these should
|
|
be thought of as a manipulator of the data, a <b>Controller</b>.
|
|
The Motif or Gnome GUI's are just two
|
|
possible manipulators of the data; others, based on <i>e.g.</i> Qt/KDE,
|
|
emacs, Java applets or Java servlets should be possible.
|
|
<p>
|
|
The <b>View</b> 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
In GnuCash, the Model is implemented via the <b>Engine</b> API, and
|
|
the View is the data that is currently in the <b>Engine</b>. 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
|
|
<hr>
|
|
<hr>
|
|
<hr>
|
|
<h2>Under construction</h2>
|
|
The stuff below dates back to Summer 1998 and is hrribly out of date.
|
|
|
|
<h2>Feature Requirements</h2>
|
|
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.
|
|
<p>
|
|
|
|
|
|
<h2>Features and Functions</h2>
|
|
|
|
<dl>
|
|
<dt><b>Graphs, Reports</b>
|
|
<dd>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.
|
|
<p>
|
|
Other output format possibilities include SGML and XML. In the
|
|
long run, these are preferable to HTML, since DSSSL and
|
|
<a href="http://www.jclark.com/jade/"> Jade (James DSSSL Engine</a>
|
|
can be used to convert to RTF, Postscript, etc. XML is the wave
|
|
of the future.
|
|
<p>
|
|
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.
|
|
<p>
|
|
Graphs, charts, etc. too ...
|
|
<p>
|
|
One hard part of reporting is designing a configurable interface,
|
|
so that people can build custom reports.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Simple HTML output is implemented. GnuCash will even act as a one-shot
|
|
web server.
|
|
<li>Reports for profit & loss, balance sheet, & portfolio valuation
|
|
implemented as html-embedded perl scripts.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Web Site Maintenance & Marketing</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Jeremy Collins
|
|
<a href="mailto:jcollins@gnucash.org">jcollins@gnucash.org</a>
|
|
has put together the web site and is the current maintainer.
|
|
Almost everything on the list above is now available. Thanks Jeremy!
|
|
<li>Dec 1998 -- Yannick LE NY has provided French tranlations of the
|
|
lead web pages.
|
|
<li>Nov 1998 -- Many thanks to Patrick Condron
|
|
<pcondon@rackspace.com>
|
|
and <b><tt>rackspace.com</tt></b> forgh-bandwidth hosting of the web
|
|
site.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>OFX support</b>
|
|
<dd>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
|
|
<a href="http://www.ofx.net">OFX HomePage</a> for details.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Work on an OFX DTD parser has begun. headers generated
|
|
correctly. Constrcutors generated almost correctly.
|
|
Parser work done by Linas.
|
|
<li>Simple scripts have been run against real-live OFX servers.
|
|
Ueli Rutishauser <urutishauser@bigfoot.com>
|
|
has been able to do e*trade transactions to a real account.
|
|
<li> how it will intereact with the GUI is a wide-open question.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Budgeting</b>
|
|
<dd>Ability to handle budgeted future transactions.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>A design doc has been submitted by Bob Drzyzgula.
|
|
Take a look at <tt>./src/budget.txt</tt> in the source directory.
|
|
<p>
|
|
|
|
<dt><b>Ledger Widget</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Current Status:</b> the latest beta-development releases (version
|
|
1.1.x) contain such an object.
|
|
<ul>
|
|
<li>Currently Motif-based
|
|
<li>GTK port mostly work, but is hung up on the inadequacies of
|
|
underlying table widget.
|
|
<li>No Qt port yet of the register.
|
|
<li>the simple single-account ledgers (incl. stock ledgers) seem
|
|
to be working correctly, but no heavy testing yet.
|
|
<li>The multiple-account ledger is very broken.
|
|
<li>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.
|
|
<li>GTK version published, thanks to Rob Browning.
|
|
(other comments above are for motif version).
|
|
<li>No curses or emacs version yet.
|
|
<li>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.)
|
|
<li>Linas Vepstas <linas@linas.org> is handling the "GUI-independent"
|
|
parts of the register, as well as the Motif code.
|
|
<li>Ted Lemon <mellon@hoffman.vix.com>
|
|
is creating/fixing/extending
|
|
the underlying gtk widget to have the features that GnuCash needs.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Engine, Financial Objects</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Current Status:</b>
|
|
<ul>
|
|
<li>The basic engine has been detangled from
|
|
the GUI elements, as of version gnucash-1.1.4.
|
|
<li>Binary file I/O mostly detangled into a separate module.
|
|
<li>Crude transaction logging in place; should be suitable
|
|
for error/crash recovery but has not been tried by fire.
|
|
<li>Backup files automatically created & timestamped.
|
|
<li>BeginEdit()/RoolbackEdit()/CommitEdit() routines mostly in place,
|
|
These "Transaction processing constructs"
|
|
should simplify creation of an SQL back end.
|
|
<li>Multiple currency support is present but shaky/untested.
|
|
<li>Query engine is minimal/sparse in capabilities.
|
|
<li>Linas <linas@linas.org> is maintaining the engine code.
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<dt><b>Extension Language Support</b>
|
|
<dd>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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Work has begun.
|
|
<li>The transaction engine interfaces are avaialable via
|
|
<a href="http://starship.skyport.net/crew/beazley/swig.html">
|
|
SWIG</a>.
|
|
<li>The main loop is controlled by the Guile scheme interpreter.
|
|
<li>Rob Browning is the reigning expert.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Multi-user Support</b>
|
|
<dd>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.
|
|
<p>
|
|
The following industrial-strength features are still needed:
|
|
<ul>
|
|
<li>transaction-oriented queuing of updates
|
|
<li>event subscription channel for updates
|
|
<li>user authentication
|
|
<li>user authorization
|
|
<li>non-repudiability
|
|
<li>encryption of network connections
|
|
</ul>
|
|
<p>
|
|
<ul>
|
|
<li>Stephan Lichtenauer <s_lichtenauer@muenchen.org>
|
|
is working on corba interfaces.
|
|
<li>"Alexander L. Belikoff" <abel@bfr.co.il> may start work on corba
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<dt><b>SQL I/O</b>
|
|
<dd>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!
|
|
<p>
|
|
|
|
<dt><b>Network Banking</b>
|
|
<dd>Add ability to do on-line banking, billpay, etc.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Can obtain stock quotes from Yahoo (NYSE), Fidelity Investments,
|
|
T.Rowe Price, and do automated update of GnuCash data files
|
|
(with the gnc-price perl script). Need to add more data sources.
|
|
See src/quotes/Quote.pm and src/quotes/gnc-price for details.
|
|
</ul>
|
|
<p>
|
|
|
|
</dl>
|
|
<h2> More ...</h2>
|
|
|
|
|
|
<dl>
|
|
<dt><b>User Interface Ports</b>
|
|
<dd>Port the package as a whole to gtk/gnome, Qt, Emacs.
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Currently, the most functional interface is the Motif interface.
|
|
This primarily due to historical reasons, i.e. the Motif interface was
|
|
inherited from X-Accountant. Maintained by Linas Vepstas.
|
|
<li>The gnome/gtk version is second in line. It frequently doesn't
|
|
compile, although sometimes it runs. The #1 showstopper for this
|
|
port is the lack of a suitable table widget that can be used
|
|
as a Ledger. The ledger currently uses the gtk_clist widget,
|
|
but this isn't really powerful enough. Volunteers?
|
|
<p>
|
|
Most of the work has been done by
|
|
Jeremy Collins, with considerable help from Rob Browning.
|
|
Daniel R Risacher <magnus@alum.mit.edu> keeps threatening to
|
|
do something ...
|
|
<li>First draft of Qt code submitted by
|
|
Dirk Schoenberger <schoenberger@signsoft.com>.
|
|
<li>Jim Pick <jimpick@jimpick.com> may be working on an emacs version...
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<dt><b>Internationalization</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Current status:</b>
|
|
<ul>
|
|
<li>Most English-language messages have been
|
|
<tt>#defined</tt> and moved to a single header file
|
|
<tt>include/messages_en.h</tt>
|
|
<li>Plan to use gnu <tt>gettext()</tt> for the message catalogues.
|
|
<li>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.)
|
|
<li>Henning Spruth has translated the README into German.
|
|
<li>Yannick Le Ny <y-le-ny@ifrance.com> traduction en francais
|
|
et <tt>include/messages_fr.h</tt>
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Icons, Glitz, Icons, Glitz</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>User Preferences</b>
|
|
<dd>Create menu system & file format for manipulating user
|
|
preferences. Preferences include things like showing/not
|
|
showing categories, forcing double-entry, etc.
|
|
<p>
|
|
<b>Current status:</b>
|
|
<ul>
|
|
<li>Rob Browning has put together a basic infrastructure
|
|
that unifies command-line flags with sceme-based config files.
|
|
<li>Rob also is auto-generating the GUI ...
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Categories</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Current status:</b>
|
|
<ul>
|
|
<li>There exists the ability to merge
|
|
accounts from multiple files, and the ability to hide/show
|
|
Income/Expense Account types.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Recurring Transactions</b>
|
|
<dd>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 ??
|
|
<b>Current status:</b>
|
|
<ul>
|
|
<li>April 1998 -- Design Doc contributed by Bob Drzyzgula. See
|
|
<tt>src/budget.txt</tt>
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>Navigation</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Folder Tabs</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Fly-Over Help</b>
|
|
<dd>When the user pauses the mouse over a button, "fly-over" pop-up
|
|
help windows should appear.
|
|
<p>
|
|
|
|
<dt><b>Simplified Stock Ledger</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Forced Double-Entry</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Current status:</b>
|
|
<ul>
|
|
<li>April 1998 -- The engine has a couple of flags in it that control
|
|
double-entry behaviour: it can be made lax, or strict:
|
|
however, they are compiled in, there is no way to change them
|
|
from the gui.
|
|
<li> Dec 1998 -- Scruber functions implemented to crawl through data,
|
|
and find all unbalanced or orphaned transactions.
|
|
</ul>
|
|
<p>
|
|
|
|
<dt><b>emacs, vi, motif, kde, gnome Key Bindings for Text Fields</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Bonds & Interest Bearing Instruments</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Household Assets</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Inventory, Job Costing</b>
|
|
<dd>Add the business features needed to maintain a stock of items for
|
|
sale, estimating jobs.
|
|
<p>
|
|
|
|
<dt><b>Payables & Receivables</b>
|
|
<dd>Add features to track sales receipts and other pending sources
|
|
of income, as well as owed sums.
|
|
<p>
|
|
|
|
<dt><b>Check Printing</b>
|
|
<dd>Create a check-printing ability.
|
|
<p>
|
|
|
|
<dt><b>Locks</b>
|
|
<dd>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.)
|
|
<p>
|
|
|
|
<dt><b>Grayed-out Form Help</b>
|
|
<dd>Create grayed out entries in the ledger, titled "Memo",
|
|
"Description", etc, helping users understand what should be typed into
|
|
each field.
|
|
<p>
|
|
|
|
<dt><b>Accounting Periods</b>
|
|
<dd>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.
|
|
<p>
|
|
|
|
<dt><b>Quicken(TM) Export</b>
|
|
<dd>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.)
|
|
<p>
|
|
|
|
<dt><b>Transaction Window Fixes</b>
|
|
<dd>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.
|
|
<p>
|
|
<b>Status</b>: Some basic reorganization of register was done to
|
|
support mixed multi-line split display. However, the actual
|
|
display of such things remaions unimplemented.
|
|
<p>
|
|
|
|
<dt><b>Tab-delimited ASCII file format</b>
|
|
<dd>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:
|
|
<pre>
|
|
field-name tab fieldname tab fieldname \n
|
|
------------------------------------------ \n
|
|
value tab value tab value \n
|
|
value tab value tab value \n
|
|
etc ...
|
|
</pre>
|
|
Its a very simple, very basic flat table format. It should match
|
|
the SQL schemas in order to minimize I/O complexity and incompatibility.
|
|
<p>
|
|
|
|
|
|
</dl>
|
|
</p>
|
|
|
|
<h2>Volunteers</h2>
|
|
Your name here as project contributor!
|
|
<ul>
|
|
<li>Linas Vepstas <linas@linas.org> is maintaining the current GnuCash
|
|
and is attempting to coordinate the project work.
|
|
<li>Jeremy Collins <jcollins@gnucash.org>, originated the GnoMoney
|
|
project, created the intial GTK port, and set up the GnuCash web site.
|
|
<li><a href="mailto:rlb@cs.utexas.edu">Rob Browning (rlb@cs.utexas.edu)</a>
|
|
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.
|
|
<li>Robin Clark <rclark@cs.hmc.edu> wrote the *original* X-Accountant,
|
|
which was later renamed as GnuCash.
|
|
</ul>
|
|
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.
|
|
<p>
|
|
|
|
<h2>References</h2>
|
|
<ul>
|
|
<li><a href="http://gnucash.ml.org/">GnuCash Home Page</a>
|
|
<li><a href="http://www3.hmc.edu/~rclark/xacc/">X-Accountant Home Page</a>
|
|
<li><a href="http://www.hex.net/~cbbrowne/finances.html">CBBrowne's List
|
|
of GNU/Linux Accounting Software</a>
|
|
<li><a href="http://www.mail-archive.com/gnucash-devel@gnucash.org/">
|
|
GnuCash Mail archives</a>
|
|
<li><a href="http://gnucash.org/gnucash-devel/">Official GnuCash mail archives</a>
|
|
<li><a href="http://www.pathcom.com/~sstratos/">gstalker</a> gtk/gnome stock
|
|
grapher.
|
|
<li><a href="http://prope.insa-lyon.fr/~rhertzog/geniustrader/">Genius Trader</a>
|
|
stock graphing tool. Perl & Tk based.
|
|
<li><a href="http://www.daveware.com/linuxrapid.html">Xrapid</a>
|
|
stock technical analysis.
|
|
<li><a href="http://www.ios-online.de/Linux-Kontor/">Linux-Kontor,
|
|
an industrial accounting package project.</a>
|
|
<li><a href="http://members.iweb.net.au/~steveoc/ERP/index.html ">ERP</a>
|
|
Business Accounting project
|
|
<li><a href="http://obelisk.dhs.org">Obelisk</a> Business Accounting project
|
|
|
|
<li>The original <a href="http://www.dnaco.net/~bcooper/watermark/index.html">
|
|
WaterMark</a> Gnome/KDE personal finance project page.
|
|
<li><a href="http://www.telly.org/freemoney/">FreeMoney</a> Linux
|
|
small-business accounting s/w.
|
|
<li><a href="http://www.didx.com/xml-builder.html">XML Builder</a>
|
|
allows GUI screens to be described using XML markup.
|
|
See also mozilla.org's xpfe ...
|
|
<li><a href="http://www.ofx.net/">Open Financial Exchange</a>
|
|
a consortium backed by Intuit, CheckFree and Microsoft
|
|
do advance on-line banking.
|
|
<li><a href="http://www.sabotage.net/redhat/ssl.html">SSLeay RPM's</a>
|
|
<li><a href="http://www.sabotage.net/security/ecash/lucre/">-lucre</a>
|
|
a publically available version of e-cash.
|
|
<li><a href="http://www.openapplications.org/">Open Applications Group</a>
|
|
is developing specs for accounting systems.
|
|
<li><a href="http://www.ibm.com/java/sanfrancisco">IBM San Francisco</a>
|
|
Business and Financial Java classes.
|
|
<li><a href="http://www.integrion.com/">Integrion</a>, a 16-bank + IBM
|
|
consortium aimed at building up on-line banking infrastructure.
|
|
Mostly aimed at mainframes, middle-ware, high transaction volumes
|
|
& data integrity.
|
|
<li><a href="http://www.sun.com/980224/javapos/">Java Point of Sale</a>
|
|
interfaces.
|
|
<li><a href="ftp.gnu.org:/pub/gnu/plotutils/">Gnu Plotutils</a>
|
|
needed for building the graphing portions of the code.
|
|
<li><a href="http://www.im.lcs.mit.edu/~magnus/ml/">partly finished
|
|
GTK grid widget</a> may be better than Clint, gtktable.
|
|
<li><a href="http://glade.pn.org/">Glade</a> an XML-based
|
|
GTK+ User Interface Builder
|
|
<li><a href="www.php.net">PHP-3</a> for html-embedded perl-like language.
|
|
<li><a href="http://www.engelschall.com/sw/eperl">Embedded Perl</a>
|
|
<li><a href="http://www.transaction.net/money/">How Money Works</a>
|
|
<li><a href="http://www.chieti.com/lpc/">Linux Projects Catalogue</a>
|
|
<li><a href="http://www.penguincomputing.com/antarctic.html">
|
|
Antarctic Project Server</a>
|
|
<li><a href="http://www.projects.ml.org/">ALPS -- Another Linux Project
|
|
Server</a>
|
|
<li><a href="http://www.im.lcs.mit.edu/~magnus/ml/">Maxwell's Lemur
|
|
-- a GTK based table widget</a>
|
|
<li><a href="mailto:nw@hydaspes.if.org">Nathan Wagner (nw@hydaspes.if.org)
|
|
</a> is working on an accounting
|
|
<a href="http://granicus.if.org/~nw/accounting/">
|
|
SQL table layout</a>.
|
|
<li><a href="mailto:carew@hotmail.com">Evan Carew
|
|
(carew@hotmail.com)</a> is working on an accounting SQL table
|
|
layout. Evan has strong corporate accounting experience.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
Draft version 0.25 -- October 1998<br>
|
|
Linas Vepstas <a href="mailto:linas@linas.org">linas@linas.org</a><br>
|
|
</body>
|
|
</html>
|