Description: 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.
Keywords: linux, OFX, accounting, finance, financial, ledger, double entry, GPL, gnu

# GnuCash Project Goals

The people behind GnuCash aim to create a world-class GPL'ed Open Source Personal Financial Application for GNU/Linux and other Unix's. This page reviews some of the technical issues and development status surrounding this project. It is a kind of an FAQ for developers and contributors, providing status, and suggesting directions and technologies for deploying new features. If you simply want to get a better idea of what GnuCash is and what it does, visit its home page. The home page contains screen shots, news items, and mailing list archives.

There are currently several different versions of GnuCash. We've adopted the kernel numbering scheme: even minor relase numbers (1.2.x, 1.4.x) are considered to mark stable releases, while odd numbers (1.3.x) mark development releases.

- The current stable, production release is gnucash-1.2.5 and is based on the Open Group's Motif GUI library. Note, however, that the Motif version is no longer being maintained, and all development efforts have switched over to the Gnome/GTK version.
- The 1.3.x releases focus on the the Gnome / GTK version. This version adds many new features that are absent in the Motif version. Development is progressing well, and the 1.3.x series are as usable as the 1.2.5 version.
- Note that some more experimental versions, such as one using the Qt library from Troll Tech for the for the KDE desktop, for the Palm Computing platforms, as well as a Java-based version have been discussed and/or started. Source code for these, such as there may be, is in the CVS tree.

The latest Gnome version, and latest versions in general, are currently available only via CVS. Occasionally, some of the more stable CVS versions are given a version number, and packaged as a precompiled deb or rpm install package. Naive or begining users should probably stick to version gnucash-1.2.5: although this version is quite old and lacking in many features, it is known to work. More adventurous users can try one of the 1.3.x releases: these days, they are pretty stable, and work pretty well. However, we cannot gaurentee that they are flawless. We've tried to make sure that no matter how broken these get, they won't mangle your data, but we can't make promises.

This document is divided into several sections.

1. Architectural Goals
2. Requirements
3. Sizings
4. Features

# Architectural Goals

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

## Separation of GUI and Data

First, we must maintain a clean separation between the data structures and the GUI that manipulates them, along the lines of the 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. Thus, the Motif or Gnome GUIs are merely two possible manipulators of the data; others, based on e.g. web/cgi-bin, Qt/KDE, emacs, Java applets or Java servlets ought to be possible.
- The View of the data is a subset or slice of the data described by the Model. The View may consist of only the transactions for the month of May, or only the account totals for certain accounts. The View is used in part to generate the reports and graphs, but it is also that which the Controller interacts with. Views are generated by queries to the data store.

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 from more mundane sources, such as file imports, or merger of data from several users. Amongst these terms, the concept of a global Model-View is dated, and somewhat inappropriate. Rather, we need to be concerned about how data is represented in the local address space of the GUI, how the GUI manipulates it, how data 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 essentially represents a local data cache of 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.

## The Financial Engine

In GnuCash, the Model is implemented via the Engine API, and the View is the data that is currently in the Engine. Thus, the Engine is a set of programming API's that the GUI (or a script, or even a clever command-line-addict) can use to manipulate the data.

Currently, the Engine is fairly poor, and is tightly tied to the data structures that the GUI manipulates. These data structures include:

- Transactions, which consist of a set of journal entries (JE's) whose values sum to zero.
- Journal Entries (internally refered to as 'splits') which record prices and values.
- Accounts, which consist of a list of journal entries.
- Chart of Accounts, which is a heirarchical tree of accounts.

The Engine has a very simple apply/commit model, and a simple query mechanism for generating reports and views. The goal of the commit and query model is to aid/simplify the creation of & merger with an SQL back-end.

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;
- It 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 really intended to be able to do much more.

In particular, it should be possible to back the Engine onto an SQL database, and thereby enable multiple users and/or interface to more complex accounting systems. The engine should also be expandable to handle other sources of data, such as 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.

## Modularity, Extensibility and Customization

The above structure should leads us to view GnuCash not so much as a tightly integrated application, but rather as a loose confederation of component objects, libraries and interfaces. In order to facilitate the gluing together of these parts, as well as simplify the questions of customizability, change and rapid development, GnuCash makes use of the Scheme extension language (as implemented in the FSF Guile interpreter), to glue the pieces together. (Note that the engine interface is also available with Perl interfaces, thanks to a SWIG wrapper.

# Requirements

Implicit in this desire for extensibility is the need to build financial applications supporting two major classes of users:

- Home Users
- Small Business Users

They may use some of the same financial terminology, and hopefully might share a fair bit of code, but have quite different goals and requirements.

### Personal Finance Needs

Important properties of a personal finance system include:

- Needs to be approachable and usable by occasional users who are not knowledgeable about accounting.
- Ease of use and simplicity is critical.
- A reasonable selection of reports, graphs, charts, and tools for personal finance, such as mortgage calculations.
- Budgeting support needs to be targeted at naive users.
- Interfaces to on-line banking, shopping, stock systems.
- Support for management of stock portfolios that may involve considerable sophistication, since individuals commonly have retirement plans that hold mutual funds, stocks, options, bonds, and the like.

### Small Business Needs

- With a business system, it is likely that there will be full-time users, which puts the emphasis on efficiency of user interface rather than on its approachability to naive users.
- Business systems require network support, and the ability to support multiple simultaneous users.
- Some business users may want access to the system from an MS Windows 95/98/NT box. For these folks, a web-based interface could be just handy. Web interfaces are also nice for ASP type deployment.
- Small businesses do not often have sophisticated investment portfolios; they instead need support for additional sophistication in such areas as:
  - Payroll
  - Inventory Control
  - Shipping and Receiving
  - Accounts Receivable
  - Accounts Payable
  - Asset Management
- Support for calculations associated with accrual accounting.
- Ambitions for the future might include interfaces to online shopping carts, credit card clearing interfaces, and ERP systems.

### Reconciling Those Needs

A seemingly contradictory factor is that the kinds of sophistication that are required vary considerably. Consider:

- A home user does not generally require most of the sophistication (sophistry?) of accrual accounting that is required by business enterprises. Thus, home users don't need much of the sophistication of an Accounts Receivable or Payable system, or the bizarre depreciation policies that crop up in Asset Management systems.
- On the other hand, home users are in increasing need of surprisingly sophisticated financial tools for managing stock portfolios, including:
  - Mutual funds
  - Retirement savings plans, with such identifiers as 401(k), IRA, Roth IRA, RRSP
  - Corporate stock purchase plans
  - Corporate option plans

Another set of contradictory requirements has to do with the back-end, and interfacing to other systems:

- Home users need a simple-to-install, simple-to-maintain system. This essentially rules out the use of SQL for the storage medium/back-end for home users. (That is, the current state of the art for SQL on Linux does not offer any simple, fool-proof management for data).
- By contrast, non-SQL systems for business use are almost unimaginable. SQL provides a high degree of data integrity and storage robustness, and also simplifies tremendously the import and export of data. Powerful SQL tools exist that can work magic in the hands of a good DB admin.

It may be that these will require completely different systems, and that GnuCash cannot be "all things to all people." This remains to be seen.

# Sizings

This section attempts to guesss how hard it would be to implement certain features.

## Personal Financial Application

Below are listed the technical work items needed to implement the features that home users might hope to have. They are listed in approximate order of priority.

The right hand column shows a sizing guesstimate. pm == person-months. These sizings are meant to show 'effort needed to complete', rather than 'total effort required'. Thus, half-finished items have smaller sizings.

- Small 0 to 4 pm
- Medium 3 to 12 pm
- Large More than 12 pm

Feature | Sizing
--- | ---
Internationalization | Small
Reports | Small
Graphs | Medium
Simplified Stock Ledger | Small
Themes, Icons, Glitz | Medium
Books, Accounting Periods | Small
Check Printing | Small
User Preferences | Medium
Extension Language Support | Medium
401K etc. | Small
Annotate with Investment News | Small
Loan and Mortgage Calculators | Small
Budgeting | Medium
Overdraft Alerts | Small
Alerts, Recurring Transactions | Medium
Quicken(TM) Import | Small
Quicken(TM) Export | Small
Stock Quotes, Price Quotes | Small
Technical Stock Analysis | Medium
Depreciation, Sinking Funds | Medium
OFX, Online Banking, Trading, Bill-pay | Large
Multiple Currencies | Medium
Double Entry Accounting | Small
Tab-delimited ASCII export | Small
Tax Preparation | Large
Sync with Palm Pilot organizers | Medium
Emergency Records Organizer | Small

## Small Business Features

Features that small/medium businesses expect.

Feature | Sizing
--- | ---
Enhanced Engine, Financial Objects | Large
SQL I/O | Medium
Multi-User Support | Medium
A/R, A/P Accounts Payable, Receivable | Medium
Payroll | Medium
Invoicing | Medium
Job Costing | Medium
Expense Accounts | Large

# Features and Functions

This section reviews the current status of various features. Some of these are 'in process', some are 'almost done', some are 'completely done'. This section thus provides status on both where we've been, and where we're going.

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

  Current status:

  - All GUI messages currently use GNU `gettext()` for the message catalogs. Translations exist for English, British, French, Sweedish and German.
  - Help pages available only in English and French.
  - Monetary and string handling done through glibc. The latest glibc (2.2.3) is nedded to get the correct functions.
  - Yannick Le Ny <y-le-ny@ifrance.com> traduction en francais
  - Most GUI input elements use the gtk text widget, and thus use the XIM input method in asian locales. This allows e.g. Kanji, Katakana support. However, the register does not use XIM, and thus doesn't currently support the asian languages. This needs fixing.
Reports
  A variety of reports, including Net Worth, Balance Sheets, and Profit and Loss statements. These should be printable: that is, exportable as HTML as well as print-ready postscript. These should be easy to customize. Ideally, even novice users should be able to create custom reports.

  The Report Generator should be a separate but "dockable" subsystem of the whole. That is, it should be possible to run the report generator in a stand-alone, read-only fashion without having to start up the main application. It should be possible to run reports nightly from a command-line and/or cron job.

  One difficult aspect of reporting is designing a configurable interface, so that people can build custom reports. The New Reporting Infrastructure is seeking to build this up using Guile.

  Generated reports should be exportable to other gnome systems using bonobo. Reports should also be exportable to the gnumeric spreadsheet (possibly by writing out gnumeric file format??)

  Reports should make use of the 'action' field ...

  Relationship to budgeting not clear ...

  Stock portfolio tools should include a Cost Averaging report, Market Index report, Stock Option values, Estimation of capital gains tax liabilities.

  Status:

  - A general reporting infrastrucutre was implemented in Perl, in the form of html-embedded perl (ePerl). However, this reporting mechanism was abondoned in part because ongoing build and install problems related to eperl and swig. Also, since eperl didn't poarticipate in the interpreter even loop, the report generator had to runn as a separate process, reading data via pipes. This was uglier than some folks liked.
  - A general reporting infrastructure has been implemented in Scheme. Currently, there are simple reports for Profit/Loss, Balance Sheet, and portfolio valuation.
  - Reports are currently displayed with the gtk-xmhtml widget but are being ported to the gtk-html widget. The gtkhtml widget should provide printing abilities through gnome-print (right ????).
  - There is currently no way (no longer any way??) to generate reports from the command line ...
  - A list of 'required reports' is needed. Then these need to be implemented.
  - Heavy discussion by matt martin, Robert Merkel ...
  - The following technologies were rejected/unused mostly because they were too complex, didn't hang together technologies: SGML and Extensible Markup Language - XML. In the long run, these are preferable to HTML, since DSSSL tools such as Jade (James DSSSL Engine) can be used to convert to RTF, Postscript, etc. Add to this the consideration that XML is the basis for the Document Object Model, which is being integrated into many web-based applications, and we can see that XML is an increasingly significant format as we look to the future.
Graphs

  Graph portfolio value vs. cost

  Graphs, charts, etc. too ...

  Asset allocation pie chart.

  The following graph packages are candidates: GUPPI, plotutils, gnumeric/graph code. The gnumeric/graphcode is already bonobo-ified.

  If gnumeric and gnucash are to use a common graph solution, the following are gnumeric requirements: -- interactive plot editing -- each segment attributes totally settable/controllable -- drag/move callbacks when segments are click-draged.

  Status:

  - Evaluate different graphing packages, including GUPPI
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.

  Question: How to most simply allow the user to enter loads and fees?

  Answer: Through splits. Unfortunately, some users may not properly understand splits, at least not initially. Thus, a little popup is needed to allow the user to type in the sales load or fee and such, and then auto-create the needed splits.

  Note the current transfer window does NOT allow a share price to be specified !! Needs fixing ...

Documentation
  Need to add a 'meta keyword' tag to the documetnatin pages, this will help the search engine (e.g. htdig) better categorize the help. Mifluz might be more embeddable ... I am told that htdig-API is in good solid condition for this, but undocumented.
Themes, Icons, Glitz
  A variety of finer touches need work:

  - Hint-of-the-Day. A collection of a some 50-100 hints-of-the-day: short (2-4 sentance) hints/tips on how to use gnucash. Every time the user starts gnucash, an new hint shows up ...

  - Themes. Some theme testing required. The effect of themes on the register window needs to be reviewed.

  - Button Bar A user-configurable button-bar would be nice too. The button bar is the set of 'buttons' (open, edit...) at the top of a register window and the main window.

  - Categories/Default Chart of Accounts Provide a default Chart of Accounts, which will mostly consist of a default set 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 created automatically.

    To actually implement this, it might be best to simply create a file with these in them, and load that file. A mechanism should be provided to allow the user to weed out undesired accounts whilst not preventing them from using them at a later date, if desired.

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

  - More account types Introduce more 'fundamental' account types: (ammortized) Loan, Mortgage, ESOP, House, Line of Credit.

  - Cut-n-paste Cut-n-paste of items in the regsiter window...

  - Bank name in combo-box pull-down When user enters a new bank name, should be presented with a combo-box listing other bank-account names ... (note this may require implementation of engine callbacks so that relevent code can be informed when there are new bank names?)

  - Currency Selection Popup Currency field should get preplaced by menu of long-hand currency names, three-letter ISO abbreviations, and symbols. User should be able to add new currency types. Should also keep a static exchange-rate table.

  - Popup Calculator All price/amount fields should pop up a calculator widget; output of calculator gets entered in field.

  - Popup Calender All date fields should pop up a calender widget; selected date should get entered in field.

  - Register View Allow user to view only non-reconciled transactions ...

  - Autocompletion Quickfill should also auto-complete amount, memo fields.

  - Autoincrement Check numbers should auto-increment.

  - Configurable main-window Status Bar Bottom of main window currently shows total assest, and total income-expense (profits). Make this configurable, so that user can show arbitrary sums of arbitrary accounts.

  - Dockable Registers/ aka "Browser Mode". Currently, when each new register opens, it opens in a new window. An alternate style would be to 'dock' the register window in a bigger frame, and just have 'backward/forward' buttons to navigate through different registers (the way that a browser navigates web pages.) This of course would be a user preference.

  - Wizards/Context sensitive help. When users create new accounts, need to suggest stuff if the user typed something unexpected ... (e.g. non-alphanumeric input) ...

  - Navigation Menu navigation using the keyboard should be possible. Although menu mnemonics 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.

  - 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. Status: Done, as of version 1.3.2(?)

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

Books, Accounting Periods
  Ability to close the book at end of the fiscal year. This consists of several steps:
  - Permanently lock some transactions as non-editable. This should be straight-forward by using the `reconciled` field to indicate a `locked` value, and not allowing the GUI to edit locked records.
  - Transfer the Income minus Expense for the book period to an equity account, so that each new period starts with zero income/expense balances.
  - A mechanism to purge really old transactions from the database.
  - Extensions to reporting infrastructure ...
  - A user should be allowed to 'delete' an account only if it has no transactions in the currently open book.

    Of course, it's not deleted from the old books.

    From this last, we conclude that every chart of accounts should have a begining and ending date (that match the book period), and the file format needs to support multiple charts ...

  Status:

  - A mini-design doc exists in src/engine/future.txt
Check Printing
  Create a check-printing ability.

  Status:

  - Bill Gribble has built a prototype based on the gnome-print. Waiting for gnome-print to mature ...
User Preferences
  Create menu system and file format for manipulating user preferences. Preferences include things like default currency, register layout and colors, etc.

  What are some of the comptitive preference-handling technologies? Lets get some URL's here ... Following the unix tradition, there is no global prefernces registery. Note that session management and preferences are related things ... sort-of. Right now, we don't treat themn as such ...

  Session management is not implemented; viz, we don't remember where things were left at when the user shut down the windowing system, and we don't restore the session afterwords. This includes: which register windows were left open, what sizes they were, what thier placements on the screen were, etc. I beleive session management needs to be coordinated with KDE and with gnome, and all compliant window maangers will do the rest (?)

  Independently of session management, the register windows should remember how big they were last time they were poped up, and they should pop up the same size, again. The app should remember these sizes from invocation to invocation.

  Status:

  - Works good; lots of preferences in the gui. Implemented in home-grown scheme.
  - These are saved in the '.gnucash/config.auto' file. The current file format is raw scheme code, rather delicate to tweak by hand ...
Extension Language Support
  The application is wired together partly with C, partly with Scheme. The architecture of the wiring and how scheme is fit in needs to be reviewed, with a general overview created so that additional extensions may be added in a straightforward manner.

  The overall architecture is envisioned thus:

  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 their associated callbacks, will be specified in an extension-language configuration file. At the final stages, it is highly desirable to be able to, in some manner, import new modules without requiring that the application itself be recompiled and relinked.

  Status:

  - Scheme/Guile is the central extension language.
  - Optional interfaces to the data engine can be generated using SWIG.
  - Rob Browning is the reigning expert.
401(k), RSP
  401K, 403, IRA, Roth IRA, SEP, Keogh ... "Retirement Savigs Plans"

  Retirement Savings Plans often do not put a high priority on tracking costs, as the tax implication is that amounts are taxable upon withdrawal, meaning that there is little necessity to track capital gains. (huh??)

Annotate with News Stories
  Download, save, annotate investment news and research.

  Provide a way of storing news stories with accounts, and possibly annotating individual transactions in the same way.

Loan and Mortgage Calculators
  Provide a variety of simple GUI utilities to allow user to calculate the future value of loans, mortgage payments, interest payments, etc.

  Status:

  - Not Started.
Overdraft Alerts
  Overdraft alerts are popups that pop up whenever the user enters a transaction that would move an account below some minimum balance, or above some max balance (for a bank account) or an expense/spending limit is reached (on an expense account). A similar but different alert can be implenmented for price highs & lows. Note that these alerts do not require any sort of calendaring or recurring transaction support.

  Design requirements: implement multiple (not just two) alerts for any account type. Alert should consist of

  - value point or price point
  - movement direction
  - 'is active' boolean flag (i.e. Should be possible to 'turn off alert' without deleting it)
  - memo text

  Status:

  - Not Started.
Recurring Transactions, Calander Alerts
  Add support for automatic, recurring transactions, e.g. mortgage payments, fixed-interest bonds, regular salary checks, regular gas/phone/electric bills, etc.

  Loans & mortgages are one of the more complicated recurring transactions. Consider the following dialogue layout:

      loan amount $_____________ currency _________ (pull-down menu)
      Remaining balance $___________
      Payment amount $___________
      balloon  payment $_____________
      other payment $________  (e.g. escrow, tax)
      Payment frequency (weekly/monthly/bimonthly/quarterly/yearly)
      loan start date mm/dd/yy   length -----(weeks/months/years/peyments)
      loan time left (number of days/weeks/months, rounded)
      number of payments left
      interest rate  %__________________
      payee ____________
      pay-from account __________________
      next due date mm/dd/yy

  Note that in the above, not all fields are independent: some can be calculated from others. The `other payment` should bring up a mini-register, allowing user to add any number of splits.

  Recurring bills, salary income, etc. are simpler to handle, since they don't have intersest rates, balloons, etc. They do/will have multiple splits (e.g. payroll gross, fica, futa, income taxes, payroll net).

  Provide a calender-display of upcoming & past scheduled payments. Clicking on a calander day should raise up editable list of transactions. Calendering should include generic red-lettering of important dates: taxes due, insurance renewal dates, domain registration renewal dates, ISP contract expiration date :-). These may or may not be associated with transactions. Memoes should be possible. Popups should happen when dates get close. Technology: need to find/evaluate gnome-calender/dayplanner for integration.

  Provide list of upcoming & recently paid bills/scheduled payments/scheduled deposits for the next 1,2,3,6,12 months. Historical view shows payments crossed out (!?)

  Design Notes: Most alerts & data storage should be driven out of the engine. This will enable multi-user, distributed use. Note: alerts should be piggy-backed on a general alert infrastructure within the engine, viz, registered callbacks when balances change, so that windows can be redrawn. Not clear on if/how calander events might be server-ified. (On the other hand, a good calander should be server-ified, and thus viewable by secretaries, co-orkers, etc.)

  More complex financial instrucments may need a guile-based extension mechanism to compute values .... simple interest/mortgage calculators should be done in C in the engine ... (e.g. depreciation schedules ... under us tax law, a variety of different schedules are allowed ... )

  May need interfaces to email for emailed alerts.

  Plot forcast graphs based on scheduled income & payments ... is this tied into budgeting ????

  Status:

  - Need to create design doc, need to implement engine pieces, need to hunt down gnome-calendering bonobo.
Budgeting
  Ability to create a budget (i.e. - estimates of future expenditures). Reconcile actual expenditures against future expenditures. Create simple, step-by-step 'financial plan' budgeting GUI's:
  - Home purchase planner
  - Retirement planner
  - College tuition planner
  - Debt reduction planner
  - Scrimp-n-Save planner
  - Special purchase planner (big ticket items)
  Create a summary budget/track-record budget report that a professional financial planner/advisor could use.

  Note that the above 'step-by-step' budgeters will have a very very different GUI than what the budgeting system required for a small-business might look like.

  Status:

  - A design doc has been submitted by Bob Drzyzgula. Take a look at `./src/budget.txt` in the source directory.
  - Bryan Larsen has begun work .. it's scheme based ... Dave Peticolas has some gui roughed out ...
Quicken(TM) Import
  Ability to import Quicken QIF files. Both MSMoney and Quicken use QIF files to export data.

  Status:

  - Quicken import is implemented and mostly works. Work needs to be done for recurring transactions, etc.
  - QIF processing, as used for on-line banking, is not implemented. That is, staged import isn't done.

    Note that since banks use QIF, the correct way to reconcile bank accounts on-line is through QIF.

    On one side, we have existing recorded transactions; on the other, the latest bank statement, in QIF format.

    Now, just put them together ...

Quicken(TM) Export
  Ability to export Quicken QIF files.

  Several design alternatives are apparent:

  - A special 'report' that writes out qif could be created.

    This would use the 'reports' infrastructure to generate qif's.

  - It is fairly easy to traverse the data in the engine to write out qif files. Just do it.

  Status: not started

Stock Quotes, Price Quotes
  Add ability to download stock quotes, other price quotes.

  Add ability to download historical prices as well. (e.g. get 5-year history of mutual fund performance vs. djia).

  Right now, stock prices are stored along with everything else, in the main database, in the transaction table.

  This leads to several aesthetic quandries.

  - It bulks up the database with 'less-than critical' information.
  - Basically, transactions are either 'critical' vix record the movement of money, or are non-critical viz record things retreivable from the historical record, e.g. prices.
  - Shouldn't storage for prices be moved to somewhere else?
  - Hmmm ... what about storage for valatility, shares traded, etc?
  - Does indeed sound like an alternate storage method would be useful.
  - What about GUI implications?

  Status:

  - 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.
  - Quote.pm is now a separate development project at source-forge.
  - Need to integrate with GUI. Right now, this is a stand-alone perl script run from `crontab.` This will be done by writing scheme wrappers for the module (???)
Technical Stock Analysis
  Provide technical sotck analysis graphs, e.g. volume, 90 moving avg, beta, etc. See gstalker for example of how to do it ...
Depreciation, Sinking Funds
  Hmm ... some variation on the concept of loans? Need to support different deprciation schedules (see IRS books for that).
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, and Checkfree, and which will be supported by Integrion. The OFX DTD's are included in the 1.1 distributions. See OFX Home Page for details.

  There are two ways to build an OFX parser. One way is to build a compile-time DTD parser that treats the DTD as if it were an IDL, and generates C language stubs for a parser. This approach was attempted and abandoned because it leads to fragile C code and a very large binary.

  - The parser is fragile because minor DTD non-compliances are hard to parse, handle and recover from.
  - The parser is huge because the DTD results in hundreds of (C++) objects being generated.
  The other method would be to perform run-time DTD parsing. This is attractive particularly because it is a more commonly-used approach; there are a variety of XML tools available that provide this function.

  Run-time parsing may be slower, but on the OFX client side, this should not be a bottleneck.

  Status:

  - A compile-time parser was developed and abandoned.

  Note that the organizations developing OFX are looking to use XML as their "formats of the future;" this may encourage the use of one of the many XML parsers available for UNIX.

Other on-line support

      >> the German T-Online
      >> homebanking system BTX.
      >>
      >> I Germany we have a very popular online homebanking system,
      >> based on the T-Online BTX (Datex-J) system. All of the
      >> commercial homebanking software packages like MS-Money or
      >> Quicken work with that online system. With that system,
      >> you can retrieve  account data from your bank, and also
      >> send your transfers.
      >>
      >> I am using since more than 2 years a GPL software written
      >> by a former colleague of mine, Niek Busscher, to work with
      >> the T-Online homebanking system. That software package with
      >> the name ZKA4BTX is very unknown, since Niek published it only
      >> by email.
      >>
      >> Some words to the features of ZKA4BTX :
      >>
      >>  - Completely written in Tcl
      >>  - Uses Xcept as a BTX browser
      >>  - Retrieve account data from multiple banks
      >>  - Send transfers, using TAN
      >>  - Export retrieved account data to CBB, Xfinans and QIF files
      >>  - Export retrieved account data to CBB, Xfinans and QIF files
      >>
      >> With a simple click to an icon on my desktop, ZKA4BTX logs into
      >> T-Online, gets all my account datas from several banks, and writes
      >> (adds) it to my CBB, Xfinans or GNUcash (QIF) files.
      >>
      >> Another very important thing is that I can do all my tranfers
      >> offline, editing a transfer sheet, and ZKA4BTX sends these
      >> transfers in one step to my bank.
      >
      >One thing we could do in the short-medium term is have gnucash
      >launch ZKA4BTX to get the data, export it to QIF, and then load
      >it in, all through one command.

Multiple Currencies
  Need to support multiple currencies.

  Work is needed in the GUI. The engine currently supports multiple currencies by treating them as securities, thus allowing currency trading. The currency-trading register needs a complete overhaul as it is obtuse and unintuitive.

  A simplfied way of dealing with one-shot currency exchanges needs to be implemented, essentially just a simple calculator popup.

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 enforced: the user can create dangling transactions, where only one account is indicated.

  Although this is acceptable for home use (arguably desirable, since it allows the casual user the simplicity they desire), it is not acceptable for business use. (The counterargument is that casual users that aren't accountants need all the help at getting things right that they can get.)

  It must be possible to enforce double entry, so that a transaction cannot be completed until two accounts have been specified.

  Restricted Double Note that sometimes, the words 'single-entry' have a an alternate meaning: they can mean 'a double entry account which can only be credited, or debited, but not both'. We need to implement this.

  Current status:

  - April 1998 -- The engine has a couple of flags in it that control double-entry behavior: it can be made lax or strict, however, they are compiled in, and there is no way to change them from the GUI.
  - Dec 1998 -- Scrubber functions implemented to crawl through data, and find all unbalanced or orphaned transactions.
  - May 2000 -- Default will be changed to double-entry always. It will not be possible to disable this and move to single-entry.
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`, aka RAND/Hobbs /rdb or NoSQL. (NoSQL is available as part of the Debian GNU/Linux distribution, for instance.)

  The `/rdb` format is thus:

      field-name  tab  fieldname  tab fieldname   \n
      ------------------------------------------  \n
      value       tab   value     tab value       \n
      value       tab   value     tab value       \n
      etc ...

  It is a very simple, very basic flat table format. The use of `/rdb` with GnuCash should try to match with SQL schemas as much as possible in order to minimize I/O complexity and incompatibility.

Tax Preparation
  Gotta prepare those taxes.
  - TurboTax

    categorize items according to different tax schedules

  - VAT
  - estimate income taxes
  - estimate itemized deductions, find potential deductions, categorize them
Sync with Palm Pilot organizers
  There are Quicken-workalikes that run on the PalmComputing platform; it would be good to inter-operate with this. See PalmLink and Palm & Linux.
Emergency Records Organizer
  Put together a single-page report showing critical info about accounts, etc.
Enriched Engine, Financial Objects
  The current system makes a distinction between the data (account, transaction) and they GUI that displays it. The data is embedded within and controlled by the "Engine", which is a set of routines to access accounts, transactions, etc. The engine serves as a kind of a dynamic cache between the permanent data repository (file, sql db) and the GUI.

  The current engine is rather simple: it provides support for accounts, account hierarchies and transactions consisting of multiple entries.

  Many of the features described elsewhere will require that the engine have a far richer, more sophisticated data model, including such things as:

  - Linking to "Address Info" ( e.g. names, addresses)
  - Transaction identifiers
  - Part numbers, SKU IDs
  - Interest rates
  - Budget policy

  Note: it makes no sense at this point to make the engine API much richer than what the GUI can currently support.

  - 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 to prevent accidental garbaging up of old transactions).
  - Books Ability to close a book at the end of the fiscal year, thus indicating that nobody is permitted to "mess around" with that old data.

    In a business environment, the auditors may have "signed off" on the validity of the data; at that point, the ability to modify audited data should be very tightly controlled, or even outright forbidden.

  Current Status:

  - The basic engine has been detangled from the GUI elements, as of version gnucash-1.1.4.
  - Binary file I/O mostly detangled into a separate module.
  - Crude transaction logging/auditing in place; should be suitable for error/crash recovery but has not been "tried by fire."
  - Backup files automatically created and time-stamped.
  - `BeginEdit()/RollbackEdit()/CommitEdit()` routines mostly in place,

    These "Transaction processing constructs" should simplify creation of an SQL back end, or some other more sophisticated database engine.

  - Multiple currency support is present but still pretty "raw."
  - Query engine is minimal/sparse in capabilities.
  - Linas <linas@linas.org> is maintaining the engine code.
SQL I/O
  A module is necessary to allow data to be fetched from an SQL database, and for that database to be updated.

  There has been much discussion about this on mailing lists both for GnuCash and CBB. Major points have included:

  - Those SQL databases available on Linux tend to involve considerable administrative overhead in terms of getting them set up.

    This may be a minor cost to a business enterprise that routinely hires DataBase Administrators.

    It is not acceptable to require this of naive users that may find "simple" things like

        % su -
        Password:
        # cd /tmp
        # rpm -i gnucash-4.1.3.i386.rpm
        # exit

    to be challenging.
  - It might be useful to use an embedded database engine like unto Sleepycat DB, cdb, or something like ISAM (Note CQL++ supports ISAM access methds), or even an embedded SQL engine such as GigaBASE.

    The reasons to do so include:

    - The use of a database allows only that data which is actually in use to be loaded into memory.

      This permits managing larger sets of transactions more efficiently.

    - It also allows data to be pushed out to the DBMS immediately after entry, rather than waiting for the user to "save the books."
    - By using a well-known DBMS, outside programs are provided a well-defined way of getting at, and perhaps even modifying, GnuCash data.

      Interoperability is generally considered a good thing...

  - GnuCash presently uses a document-oriented model, where the entire set of books are loaded in, and dumped out, all at one fell swoop.

    GnuCash needs to be modified to access the database in a transactional manner. This is at least partly implemented with the `Begin()/End()` constructs in the engine.

    Some transactional thoughts: entire SQL tables/databases do not need to be locked while the user is editing a transaction via the GUI.

    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, edits are be rejected en-masse, allowing the user to merge and correct their changes.

    Important note: updating SQL does not require locks to be held for extended periods of time!

  - The SQL engine chosen should be fully transactional, passing the 'ACID' test (Atomicity, Consistency, Isolation, Durability).

    Note that MySQL does not satisfy the 'ACID' criteria.

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.

  Another possibility is to create a web application server, and have users do much/most of I/O via a web interface, possibly using the register object as a browser plugin.

  The following industrial-strength features are needed:

  - transaction-oriented queuing of updates
  - event subscription channel for updates
  - user authentication
  - user authorization
  - non-repudiability
  - encryption of network connections
Accounts Payable, Receivable
  Add features to track sales receipts and other pending sources of income, as well as owed sums.
Payroll
  Payroll introduces a sizable amount of complexity in terms of the need to comply with constantly-changing government regulations in whatever country one is in.

  While the GnuCash "engine" might remain free, maintenance of payroll functionality would require "subscribing" to an update scheme; it might be troublesome to try to provide such a "subscription" free of charge.

Invoicing
  Invoicing. To design an invoice, need to have a mini-word-processor/simple drawing plug-in. Is Abisource/Abiword a candidate? Probably needs bonobo...
Job Costing
  Ability to prepare and track estimates.
Expense Accounts
  Expense Account Automation, including air, car, hotel, dining. Receipts, reservations, cancellations.

# References

- GnuCash Home Page
- Christopher Browne's List of GNU/Linux Accounting Software
- Official GnuCash mail archives
- GnuCash Mail archives
- -- alternate.
- gstalker gtk/gnome stock grapher.
- Genius Trader stock graphing tool. Based on Perl and Tk.
- Xrapid stock technical analysis.
- Accountant project at sourcforge aims to create a generic business library.
- Linux-Kontor - an industrial accounting package that uses Java and SQL databases.
- Pango internationalized text rendering for gtk.
- Gnu Enterprise a business financial project.
- ERP Business Accounting project
- Obelisk Business Accounting project
- XML Builder allows GUI screens to be described using XML markup. See also mozilla.org's xpfe ...
- Open Financial Exchange a consortium backed by Intuit, CheckFree and Microsoft do advance on-line banking.
- Open Trading Protocol. An XML-based message protocol for payment, invoice presentation, and payment receipts.
- Secure Electronic Marketplace for Europe. SEMPER is a European R&D project in the area of secure electronic commerce over open networks.
- HBCI 2.0: Homebanking Computer Interface
- Payment mechanisms designed for the Internet provides a treasure-trove of links for zillions of standards and proposals.
- SSLeay RPM's
- -lucre a publicaly available version of e-cash.
- Open Applications Group is developing specs for accounting systems.
- OMG General Ledger (GL) Facility The Compass submission for the OMG (CORBA) General Ledger.
- XFRML, XML-based Financial Reporting Markup Language. Quote from their site: XFRML is a framework that will allow the financial community a standards-based method to prepare, publish in a variety of formats, exchange and analyze financial reports and the information they contain.
- IBM San Francisco Business and Financial Java classes.
- Integrion, a 16-bank + IBM consortium aimed at building up on-line banking infrastructure. Mostly aimed at mainframes, middleware, high transaction volumes and data integrity.
- Java Point of Sale interfaces.
- Gnu Plotutils needed for building the graphing portions of the code.
- partly finished GTK grid widget may be better than Clint, gtktable.
- Glade an XML-based GTK+ User Interface Builder
- PHP-3 for html-embedded perl-like language.
- Embedded Perl
- How Money Works
- Antarctic Project Server
- Maxwell's Lemur -- a GTK based table widget
- GigaBASE embeddabale SQL database.

# Historical References

The following URL's are inactive, obsolete or otherwise wasting away, but are here for historical interest, in part to document the way things used to be. Of archeological, nostalgic use only.

- X-Accountant Home Page
- - this was the original site for the GPL'ed accounting package that eventually evolved into GnuCash. Robin Clark wrote the first version while at school at Harvey Mudd College.
- The original WaterMark Gnome/KDE personal finance project page. Watermark and GnoMoney were proposed about the same time, and there was talk of joining forces with X-Accountant.
- FreeMoney Linux small-business accounting s/w.
- A proposal to build a business package back by SQL.

Draft version 0.37 -- May 2000

Linas Vepstas linas@linas.org

updates by Christopher Browne cbbrowne@ntlug.org