IntenseFinance/gnucash
3
0
Fork 0
mirror of https://github.com/Gnucash/gnucash.git synced 2025-02-25 18:55:30 -06:00
Code Issues Packages Projects Releases Wiki Activity
Files
44d67f3953c3d11e39d75d3766b3e2b27cf86a5d
gnucash/Docs/projects.html
Linas Vepstas 25805a8062 some gtk stuff 
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@655 57a11ea4-9604-0410-9ed3-97b8803252fd
1998-03-18 04:13:19 +00:00

515 lines
22 KiB
HTML
Raw Blame History

<html>
<head>
<title>X-Accountant Project Goals</title>
</head>
<body>
<h1>X-Accountant Project Goals</h1>
X-Accountant is a Motif/C (and soon C++?) personal accounting
application. To read more about X-Accountant, see the
Xacc home page at
<a href="http://www.cs.hmc.edu/~rclark/xacc/">
http://www.cs.hmc.edu/~rclark/xacc</a>.
This page introduces the Xacc Project, aimed at enhanceing and
improving X-Accountant.
<p>
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 architect-ed, 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.
<p>
<h2>News -- 4 March 1998</h2>
The folks involved with
<a href="http://www.dnaco.net/~bcooper/watermark/index.html">
WaterMark</a>,
<a href="http://gnomoney.ml.org/gnomoney/index.hts">GnoMoney</a>,
and
<a href="http://www.cs.hmc.edu/~rclark/xacc">
X-Accountant</a>
have tentatively agreed to join forces to work on a unified
personal-finance project. Subscribe to the xacc mailing list
for more info.
<p>
<h2>Meta-Architecture Goals</h2>
Create 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, Fresco) should be possible. The "View" of the data
is the modern way of saying a "report". A report generator
can create balance sheets and profit&loss statements, it can create pie
charts of asset allocations, or graphs asset value over time.
<p>
Create a mechanism for obtaining data from multiple financial sources.
Currently, X-Accountant 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, or
access to SQL databases. It should be possible to have any of these at
as data sources, and with the appropriate security mechanisms, it should
also be possible to update these.
<p>
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>Concrete Architectural and Development Goals</h2>
The following is a list of the larger, more abstract, and more difficult
architectural goals.
<dl>
<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>
Current Status: the latest alpha-development releases (version
1.1.x) contain such an object. Its currently motif-based, but
should be easily portable to Qt, GTK, curses.
<p>
<dt><b>C++</b>
<dd>The current code is written in C, in an object-oriented fashion.
However, C++ has many benefits; a major overhaul and conversion
to C++ is needed. This is a large task, with little short-term
benefit to the project; however, it is vital for getting to the
next level of clean, well-structured code, and thus should be
considered a priority.
<p>
<dt><b>Extension Language Support</b>
<dd>Data is currently available by reading the xacc file format, and
by importing QIF files. This interface should be abstracted,
allowing data to come from any source. The abstraction should
involve dynamically loadable modules, so that new modules could
be developed and added without the need for recompilations or
re-linking.
<p>
Rather than designing a loadable-module API, a better design
goal would probably be to create interfaces to extension
languages (perl, tcl, guile). Such an interface, laying in
between the transaction data, and the GUI that manipulates
it, should allow for the easy creation of modules, and for
modifying the behaviour of the application. Using
<a href="http://starship.skyport.net/crew/beazley/swig.html">
SWIG</a> should simplify the actual implementation.
<p>
<dt><b>Multi-user Support</b>
<dd>Mutli-user support should be added with either an SQL backend
to the engine, and/or through CORBA interfaces to teh 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 queing of updates
<li>event subscription channel for updates
<li>user authentication
<li>user authorization
<li>non-repudiability
<li>encryption of network connections
</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>Engine, Financial Objects</b>
<dd>The current system makes a distinction between the data (account,
transaction) and they GUI that displays it. This distinction should
be further strengthened, and a set of financial objects, residing in
their own library, should be created.
<p>
<b>Current Status:</b> The basic engine has been detangled from
the GUI elements, as of version 1.1.4.
<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 Microsot, Intuit, & Checkfree, and will be supported by Integrion.
<p>
</dl>
<h2>Incremental Development Goals</h2>
The following is a list of goals and "bug fixes" that should be solved
immediately, independent of the major goals.
<dl>
<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. Current status: there exists the ability to merge
accounts from multiple files, and the ability to hide/show
Income/Expense Account types.
<p>
<dt><b>Internationalization</b>
<dd>All menus, markup and help-text should be internationalized,
so that X-Accountant 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.
Still looking for an infrastructure for choosing a message
catalogue. Looking for routines that can parse and print
monetary values in different formats, as well as date/time
parsing/printing routines. (xacc contains such parsing
routines, but they're not very powerful or i18n'ed.)
<p>
Henning Spruth has translated the README into German.
<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 ??
<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>Icons, Icons, Icons</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 currenyl exist.
<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.
It should also be possible to sweep through the date, and find all
dangling transactions.
<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>
<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>
<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>Add Graphs</b>
<dd>Add the whole rainbow of graphs, charts, etc.
<p>
<dt><b>Add 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>
<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>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 alllowing the gui to edit locked records.
<p>
<dt><b>Quicken(TM) Export</b>
<dd>Ability to export Quicken QIF files.
<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 incompatability.
<p>
<dt><b>Splits</b>
<dd>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, sugget
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.
<p>
N.B. Some initial groundwork for splits has been done, but the
hard part is still ahead.
<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.)
</dl>
</p>
<h2>Status</h2>
Well, just to show that we are getting things done.
<dl>
<dt><b>Version 1.1 Alpha</b>
<dd>The Alpha development version 1.1 is out. Features include:
<ul>
<li>Data engine cleanly separated from GUI
<li>Redesigned register infrastructure will make it much easier to
create new/customer register displays, and to port to other GUI's.
<li>Splits have been added to the engine; the GUI does not yet expose them.
<li>Source available via anonymous CVS
<li>Work on GTK ports have begun (thanks to Jeremy Collins & Rob
Browning)
</ul>
(January 1998)
<p>
<dt><b>New Improved Web Site</b>
<dd>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)
<p>
</dl>
<h2>Volunteers</h2>
Your name here as project contributor!
<ul>
<li>Linas Vepstas <linas@linas.org> is maintaining the current xacc
and is attempting to coordinate the project work.
<li>Jeremy Collins <linux@cyberramp.net>, originator of the GnoMoney
project, is working on a GTK port.
<li><a href="mailto:rlb@cs.utexas.edu">Rob Browning (rlb@cs.utexas.edu)</a>
ex-cbb'er, has begun work on a gtk-based graphing package.
<li>Robin Clark <rclark@cs.hmc.edu>, the *original* X-Accountant author,
is creating a register widget in QT/KDE
<li>Henning Spruth <henning@regent.e-technik.tu-muenchen.de>
hopes to work in internationalization & locale issues,
including a translation to German.
<li>Bradley M. Kuhn <bkuhn@ebb.org> hopes to coordinate assorted
activities.
<li>Peter Norton <spacey@inch.com> is working on a GTK port of Xbae
<li>Daniel R Risacher <risacher@worldnet.att.net> is working on a
GTK ledger/register/spread-sheet infrastructure.
<li>Michael Newlyn Blake <Michael.Blake@Frogtown.Com> hopes to putter
around with QIF export.
<li>Brian Cooper <bcooper@dnaco.net> Gtk port of interface.
</ul>
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.
<p>
See also <a href="http://www.cs.hmc.edu/~rclark/xacc/merger.html">Merger</a>
<h2>References</h2>
<ul>
<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 Linux Accounting Software</a>
<li><a href="http://www.ios-online.de/Linux-Kontor/">Linux-Kontor,
an industrial accounting package project.</a>
<li><a href="http://www.dnaco.net/~bcooper/watermark/index.html">
WaterMark</a> a Gnome/KDE personal finance package project.
To see current watermark source,
<pre>
cvs -d :pserver:anonymous@im2.lcs.mit.edu:/im/magnus/cvsroot login
cvs -d :pserver:anonymous@im2.lcs.mit.edu:/im/magnus/cvsroot get watermark
</pre>
<li><a href="http://www.telly.org/freemoney/">FreeMoney</a> Linux
small-business accounting s/w.
<li><a href="http://gnomoney.ml.org/gnomoney/index.hts">GnoMoney</a>
project will probably be merged with watermark & xacc & cbb ??
<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.openapplications.org/">Open Applications Group</a>
is developing specs for accounting systems.
<li><a href="http://www.ibm.com/java/sanfrancisco">IBM San Franscisco</a>
Java classes for accounting.
<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 clist, gtktable.
<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.projects.ml.org/">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 coporate accounting experience.
</ul>
<hr>
Draft version 0.18 March 1998<br>
Linas Vepstas <a href="mailto:linas@linas.org">linas@linas.org</a><br>
Robin Clark <a href="mailto:rclark@hmc.edu">rclark@hmc.edu</a><br>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink