X-Accountant/GnoMoney Project Goals

X-Accountant/GnoMoney is a Motif/C (and soon GTK) personal finance accounting application. The project goals are to create a world-class GPL'ed Open Source personal financial application for 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.17, and xacc-1.1.x. The version 1.0.17 is written in Motif, and is considered to be stable/production quality. You can red more about X-Accountant at its home page http://www.cs.hmc.edu/~rclark/xacc.

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. Current efforts center around a port to GTK, and the addition of various features. GnoMoney presents a beautified presentation of this material.

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.

News

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 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.

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.

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.
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 alpha-development releases (version 1.1.x) contain such an object. Its currently motif-based, but should be easily portable to Qt, GTK, curses.

C++
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.

Extension Language Support
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.

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 behavior of the application. Using SWIG should simplify the actual implementation.

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:

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!

Engine, Financial Objects
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.

Current Status: The basic engine has been detangled from the GUI elements, as of version 1.1.4.

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.

Incremental Development Goals

The following is a list of goals and "bug fixes" that should be solved immediately, independent of the major goals.
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.

Internationalization
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. (messages.h) (Will 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. (xacc contains such parsing routines, but they're not very powerful or i18n'ed.)

Henning Spruth has translated the README into German.

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 ??

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.

Icons, Icons, Icons
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.

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.

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.

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

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.

Add Graphs
Add the whole rainbow of graphs, charts, etc.

Add 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 hard part of reporting is designing a configurable interface.

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.

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.

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.

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.

N.B. Some initial groundwork for splits has been done, but the hard part is still ahead.

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.)

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: (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)

Volunteers

Your name here as project contributor! 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.20 -- April 1998
Linas Vepstas linas@linas.org
Robin Clark rclark@hmc.edu