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
f0b6be6d8e
gnucash/doc/sgml/C/xacc-project.sgml
Dave Peticolas f0b6be6d8e Add Christopher Browne's DocBook-ified GnuCash manual to the repository. 
It is not yet fully integrated into the build system.


git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@2654 57a11ea4-9604-0410-9ed3-97b8803252fd
2000-08-10 05:19:16 +00:00

2963 lines
88 KiB
Plaintext
Raw Blame History

<ARTICLE ID="XACC-PROJECT">
<ARTHEADER>
<TITLE>GnuCash Project Goals</TITLE>
</ARTHEADER>
<SECT1>
<TITLE> GnuCash Project Goals</TITLE>
<PARA> </PARA>
<PARA>The people behind <ULINK URL="http://gnucash.org">GnuCash</ULINK>
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 <EMPHASIS>FAQ</EMPHASIS> 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 <ULINK URL="http://gnucash.org">GnuCash</ULINK> is and what it does, visit its
<ULINK URL="http://gnucash.org">home page</ULINK>. The home page
contains screen shots, news items, and mailing list
archives.
</PARA>
<PARA>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, 1.5.x) mark development releases.
<ITEMIZEDLIST>
<LISTITEM>
<PARA>The current stable, production release is gnucash-1.4.0
and is based on the <ULINK URL="http://www.gnome.org">Gnome</ULINK>
/ <ULINK URL="http://www.gtk.org">GTK</ULINK> libraries.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>The 1.5.x releases focus on adding new features and
improving existing functionality.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA>The latest version is 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.4.0. More adventurous users can try one of
the 1.5.x releases, However, keep in mind that they are in a
state of constant change and will often be unstable.
</PARA>
<PARA>This document is divided into several sections.
<ITEMIZEDLIST>
<LISTITEM>
<PARA><LINK LINKEND="XACC-ARCH">Architectural Goals</LINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><LINK LINKEND="XACC-REQS">Requirements</LINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><LINK LINKEND="XACC-SIZE">Sizings</LINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><LINK LINKEND="XACC-FEATS">Features</LINK>
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</SECT1>
<SECT1 ID="XACC-ARCH">
<TITLE> Architectural Goals</TITLE>
<PARA> 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.
</PARA>
<SECT2>
<TITLE>Separation of GUI and Data</TITLE>
<PARA> First, we must maintain a clean separation between the data
structures and the GUI that manipulates them, along the lines
of the <EMPHASIS>Model-View-Controller</EMPHASIS> paradigm.
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Lists of accounts and the transactions in them can be
thought of as a representation of financial data, a <EMPHASIS> Model</EMPHASIS>.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>The GUI that adds, modifies and deletes these should be
thought of as a manipulator of the data, a <EMPHASIS>Controller</EMPHASIS>.
Thus, the Motif or Gnome GUIs are merely two possible
manipulators of the data; others, based on <EMPHASIS>e.g.</EMPHASIS>
web/cgi-bin, Qt/KDE, emacs, Java applets or Java servlets
ought to be possible.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>The <EMPHASIS>View</EMPHASIS> 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.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA>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.
</PARA>
<PARA>Thus, the <EMPHASIS>View</EMPHASIS> essentially represents a local data
cache of the data that is immediately present and being
displayed, reported, and manipulated. The <EMPHASIS>Model</EMPHASIS> is the
abstraction of that data that the GUI (the controller) can act
on.
</PARA>
</SECT2>
<SECT2>
<TITLE>The Financial Engine</TITLE>
<PARA> In GnuCash, the Model is implemented via the <EMPHASIS>Engine</EMPHASIS> API,
and the View is the data that is currently in the <EMPHASIS> Engine</EMPHASIS>. 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.
</PARA>
<PARA>Currently, the Engine is fairly poor, and is tightly tied to
the data structures that the GUI manipulates. These data
structures include:
<ITEMIZEDLIST>
<LISTITEM>
<PARA><EMPHASIS>Transactions</EMPHASIS>, which consist of a set of journal
entries (JE's) whose values sum to zero.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><EMPHASIS>Journal Entries</EMPHASIS> (internally refered to as
'splits') which record prices and values.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><EMPHASIS>Accounts</EMPHASIS>, which consist of a list of journal
entries.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><EMPHASIS>Chart of Accounts</EMPHASIS>, which is a heirarchical tree of
accounts.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
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
&amp; merger with an SQL back-end.
</PARA>
<PARA>The Engine currently handles only a small set of data
sources:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>It can import and merge in QIF's;
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>It can read and write its own binary byte stream;
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>It can get stock quotes from the net.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA>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.
</PARA>
<PARA>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.
</PARA>
</SECT2>
<SECT2>
<TITLE>Modularity, Extensibility and Customization</TITLE>
<PARA> </PARA>
<PARA>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 <ULINK URL="http://www.swiss.ai.mit.edu/projects/scheme/index.html"> Scheme</ULINK> extension language (as implemented in the FSF <ULINK URL="http://www.gnu.org/software/guile/guile.html">Guile</ULINK>
interpreter), to glue the pieces together. (Note that the
engine interface is also available with <ULINK URL="http://www.perl.org">Perl</ULINK> interfaces, thanks to a <ULINK URL="http://starship.skyport.net/crew/beazley/swig.html">SWIG</ULINK>
wrapper.
</PARA>
</SECT2>
</SECT1>
<SECT1 ID="XACC-REQS">
<TITLE> Requirements</TITLE>
<PARA> Implicit in this desire for extensibility is the need to build
financial applications supporting two major classes of users:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Home Users
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Small Business Users
</PARA>
</LISTITEM>
</ITEMIZEDLIST></PARA>
<PARA> 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.
</PARA>
<SECT2>
<TITLE>Personal Finance Needs</TITLE>
<PARA>Important properties of a personal finance system
include:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Needs to be approachable and usable by occasional users
who are not knowledgeable about accounting.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Ease of use and simplicity is critical.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>A reasonable selection of reports, graphs, charts, and
tools for personal finance, such as mortgage
calculations.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Budgeting support needs to be targeted at <EMPHASIS>naive</EMPHASIS>
users.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Interfaces to on-line banking, shopping, stock
systems.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>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.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</SECT2>
<SECT2>
<TITLE>Small Business Needs</TITLE>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>With a business system, it is likely that there will be
full-time users, which puts the emphasis on <EMPHASIS> efficiency</EMPHASIS> of user interface rather than on its
approachability to naive users.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Business systems require network support, and the ability
to support multiple simultaneous users.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> Small businesses do not often have sophisticated investment
portfolios; they instead need support for additional
sophistication in such areas as:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Payroll
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Inventory Control
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Shipping and Receiving
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Accounts Receivable
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Accounts Payable
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Asset Management
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Support for calculations associated with accrual
accounting.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Ambitions for the future might include interfaces to
online shopping carts, credit card clearing interfaces, and
ERP systems.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</SECT2>
<SECT2>
<TITLE>Reconciling Those Needs</TITLE>
<PARA>A seemingly contradictory factor is that the kinds of
sophistication that are required vary considerably.
Consider:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>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
<EMPHASIS>much</EMPHASIS> of the sophistication of an Accounts Receivable
or Payable system, or the <EMPHASIS>bizarre</EMPHASIS> depreciation
policies that crop up in Asset Management systems.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> On the other hand, home users are in increasing need of
surprisingly sophisticated financial tools for managing
stock portfolios, including:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Mutual funds
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Retirement savings plans, with such identifiers as
401(k), IRA, Roth IRA, RRSP
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Corporate stock purchase plans
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Corporate option plans
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
Another set of contradictory requirements has to do with the
back-end, and interfacing to other systems:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>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).
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>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.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA>It may be that these will require <EMPHASIS>completely</EMPHASIS>
different systems, and that GnuCash cannot be "all things to
all people." This remains to be seen.
</PARA>
</SECT2>
</SECT1>
<SECT1 ID="XACC-SIZE">
<TITLE> Sizings</TITLE>
<PARA> This section attempts to guesss how hard it would be to
implement certain features.
</PARA>
<SECT2>
<TITLE>Personal Financial Application</TITLE>
<PARA> 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.
</PARA>
<PARA>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.
<ITEMIZEDLIST>
<LISTITEM>
<PARA><EMPHASIS>Small</EMPHASIS> 0 to 4 pm
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><EMPHASIS>Medium</EMPHASIS> 3 to 12 pm
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><EMPHASIS>Large</EMPHASIS> More than 12 pm
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
<TABLE>
<TITLE>Personal Finance Functionality Requirements</TITLE>
<TGROUP COLS="3">
<THEAD>
<ROW>
<ENTRY>Feature</ENTRY>
<ENTRY>Sizing</ENTRY>
<ENTRY>Responsible</ENTRY>
</ROW>
</THEAD>
<TBODY>
<ROW>
<ENTRY><LINK LINKEND="I18N">Internationalization</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>Dave</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="XACC-REPORTS">Reports</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="GRAPHS">Graphs</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>Guppi/Bill</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="LEDGER">Simplified Ledger</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>Dave,Linas</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="GLITZ">Themes, Icons, Glitz</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="MISC">Miscellaneous Small Tasks</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="ALERTS">Alerts, Recurring
Transactions</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>RLB</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="BUDGET">Budgeting</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>Dave</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="CHECK">Check Printing</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>Grib</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="USERPREF">User Preferences/Session
Mgmt.</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="QUICKIM">Quicken(TM) Import</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>Grib</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="QUICKEX">Quicken(TM) Export</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>Grib</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="BOOK">Books, Accounting Periods</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>Linas</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="CURRENCY">Multiple Currencies</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>Rethink Requirements-Linas</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="EXT">Extension Language Support</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>RLB</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="QUOTE">Stock Quotes, Price Quotes</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>RLB</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="INSTALL">Install</LINK></ENTRY>
<ENTRY>Small ?</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="DOUBLE">Forced Double Entry</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="I401K">401K etc.</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="DOCS">Documentation</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="NOTE">Annotate with Investment News</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="LOAN">Loan and Mortgage Calculators</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="OVERDRAFT">Overdraft Alerts</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="TECH">Technical Stock Analysis</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="SINK">Depreciation, Sinking Funds</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="OFX">OFX, Online Banking, Trading,
Bill-pay</LINK></ENTRY>
<ENTRY>Large</ENTRY>
<ENTRY>Dave</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="TAB">Tab-delimited ASCII export</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="TAX">Tax Preparation</LINK></ENTRY>
<ENTRY>Large</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="PALM">Sync with Palm Pilot
organizers</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="EMERG">Emergency Records Organizer</LINK></ENTRY>
<ENTRY>Small</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
</TBODY>
</TGROUP>
</TABLE>
</PARA>
</SECT2>
<SECT2>
<TITLE>Small Business Features</TITLE>
<PARA> Features that small/medium businesses expect.
<TABLE>
<TITLE>Business Functionality Requirements</TITLE>
<TGROUP COLS="3">
<THEAD>
<ROW>
<ENTRY>Feature</ENTRY>
<ENTRY>Sizing</ENTRY>
<ENTRY>Responsible</ENTRY>
</ROW>
</THEAD>
<TBODY>
<ROW>
<ENTRY> </ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="ENGINE">Enhanced Engine, Financial
Objects</LINK></ENTRY>
<ENTRY>Large</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="SQL">SQL I/O</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>Linas</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="MULTIUSER">Multi-User Support</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="ARAP">A/R, A/P Accounts Payable,
Receivable</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="PAYROLL">Payroll</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="INVOICE">Invoicing</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="ESTIMATE">Job Costing</LINK></ENTRY>
<ENTRY>Medium</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
<ROW>
<ENTRY><LINK LINKEND="XACC-EXPENSE">Expense Accounts</LINK></ENTRY>
<ENTRY>Large</ENTRY>
<ENTRY>?</ENTRY>
</ROW>
</TBODY>
</TGROUP>
</TABLE>
</PARA>
</SECT2>
</SECT1>
<SECT1 ID="XACC-FEATS">
<TITLE> Features and Functions</TITLE>
<PARA> 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.
<GLOSSLIST>
<GLOSSENTRY>
<GLOSSTERM><EMPHASIS>Internationalization</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA><ANCHOR ID="I18N"></PARA>
</GLOSSDEF>
<GLOSSDEF>
<PARA> 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.
</PARA>
<PARA><EMPHASIS>Current status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>All GUI messages currently use GNU <FUNCTION>gettext()</FUNCTION>
for the message catalogs. Translations exist for English,
British, French, Sweedish and German.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Help pages available only in English and French.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Monetary and string handling done through glibc. The
latest glibc (2.2.3) is nedded to get the correct
functions.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Yannick Le Ny &lt;y-le-ny@ifrance.com&gt; traduction
en francais
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Most GUI input elements use the gtk text widget, and
thus use the XIM input method in asian locales. This
allows <EMPHASIS>e.g.</EMPHASIS> Kanji, Katakana support. However, the
register does <EMPHASIS>not</EMPHASIS> use XIM, and thus doesn't
currently support the asian languages. This needs
fixing.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><EMPHASIS>Reports</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 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.
</PARA>
<PARA>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.
</PARA>
<PARA>One difficult aspect of reporting is designing a
configurable interface, so that people can build custom
reports. The <LINK LINKEND="NEWREP">New
Reporting Infrastructure</LINK> is seeking to build this up
using Guile.
</PARA>
<PARA>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??)
</PARA>
<PARA>Reports should make use of the 'action' field ...
Relationship to budgeting not clear ...
</PARA>
<PARA>Stock portfolio tools should include a Cost Averaging
report, Market Index report, Stock Option values,
Estimation of capital gains tax liabilities.
</PARA>
<PARA>Reports should be printable to printer.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM ID="NEWREP">
<PARA>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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>A general reporting infrastructure has been <LINK LINKEND="NEWREP">implemented in Scheme</LINK>.
Currently, there are simple reports for Profit/Loss,
Balance Sheet, and portfolio valuation.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>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 ????).
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>There is currently no way (no longer any way??) to
generate reports from the command line ...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>A list of 'required reports' is needed. Then these
need to be implemented.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Heavy discussion by matt martin, Robert Merkel
...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>The following technologies were rejected/unused
mostly because they were too complex, didn't hang
together technologies: <ULINK URL="http://www.oasis-open.org/cover/">SGML</ULINK> and <ULINK URL="http://www.oasis-open.org/cover/xml.html">Extensible
Markup Language - XML.</ULINK> In the long run, these are
preferable to HTML, since <ULINK URL="http://www.jclark.com/dsssl/">DSSSL</ULINK> tools such as <ULINK URL="http://www.jclark.com/jade/">Jade (James DSSSL
Engine)</ULINK> can be used to convert to RTF, Postscript,
etc. Add to this the consideration that XML is the basis
for the <ULINK URL="http://www.w3.org/DOM/">Document Object
Model</ULINK>, 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.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="GRAPHS"><EMPHASIS>Graphs</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> </PARA>
<PARA>Graph portfolio value vs. cost
</PARA>
<PARA>Graphs, charts, etc. too ...
</PARA>
<PARA>Asset allocation pie chart.
</PARA>
<PARA>The following graph packages are candidates: <ULINK URL="http://www.gnome.org/guppi/">GUPPI</ULINK>, plotutils,
gnumeric/graph code. The gnumeric/graphcode is already
bonobo-ified.
</PARA>
<PARA>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.
</PARA>
<PARA>Graphs should be printable to printer.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Evaluate different graphing packages, including <ULINK URL="http://www.gnome.org/guppi/">GUPPI</ULINK>
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="LEDGER"><EMPHASIS>Simplified Ledger</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Ledger needs various fixes/cleanups. Before any fixups can
be done, agreement needs to be gotten as to what the
register *should* look like.
</PARA>
<PARA>Multi-Line splits look confusing when viewed from
Income/Expense Accounts.
</PARA>
<PARA>Stock splits &amp; reverse splits are not displayed
correctly.
</PARA>
<PARA>Currency trading Ledger is confusing.
</PARA>
<PARA>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.
</PARA>
<PARA>How to most simply allow the user to enter loads and
fees? Through multi-line transactions. Unfortunately, some
users may not properly understand multi-line transactions,
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 journal entries.
</PARA>
<PARA>Note the current transfer window does <EMPHASIS>NOT</EMPHASIS> allow
a share price to be specified !! Needs fixing ...
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="DOCS"><EMPHASIS>Documentation</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Need to add a 'meta keyword' tag to the documetnatin
pages, this will help the search engine (<EMPHASIS>e.g.</EMPHASIS> <ULINK URL="http://www.htdig.org/">htdig</ULINK>) better categorize the
help. <ULINK URL="http://www.senga.org/mifluz/html/">Mifluz</ULINK>
might be more embeddable ... I am told that htdig-API is in
good solid condition for this, but undocumented.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="GLITZ"><EMPHASIS>Themes, Icons, Glitz</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> A variety of finer touches need work:
<ITEMIZEDLIST>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Hint-of-the-Day</EMPHASIS>. 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 ... <EMPHASIS>Status:</EMPHASIS>
Dave volunteers...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Themes</EMPHASIS>. Some theme testing required. The
effect of themes on the register window needs to be
reviewed.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Button Bar</EMPHASIS> 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Categories/Default Chart of Accounts</EMPHASIS> 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.
</PARA>
<PARA>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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Household Assets</EMPHASIS> 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>More account types</EMPHASIS> Introduce more
'fundamental' account types: (ammortized) Loan,
Mortgage, ESOP, House, Line of Credit.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Cut-n-paste</EMPHASIS> Cut-n-paste of whole transactions
in the regsiter window... <EMPHASIS>Status:</EMPHASIS>Dave... Done.
(in 1.4.0)
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Bank name in combo-box pull-down</EMPHASIS> 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?)
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Currency Selection Popup</EMPHASIS> 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Popup Calculator</EMPHASIS> All price/amount fields
should pop up a calculator widget; output of calculator
gets entered in field.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Popup Calender</EMPHASIS> All date fields should pop up
a calender widget; selected date should get entered in
field.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Register View</EMPHASIS> Allow user to view only
non-reconciled transactions ...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Autocompletion</EMPHASIS> Quickfill should also
auto-complete amount, memo fields.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Autoincrement</EMPHASIS> Check numbers should
auto-increment.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Configurable main-window Status Bar</EMPHASIS> 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Dockable Registers/ aka "Browser Mode"</EMPHASIS>.
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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Wizards/Context sensitive help</EMPHASIS>. When users
create new accounts, need to suggest stuff if the user
typed something unexpected ... (<EMPHASIS>e.g.</EMPHASIS>
non-alphanumeric input) ...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Navigation</EMPHASIS> Menu navigation using the keyboard
should be possible. Although menu mnemonics exist, they
seem to be broken. ???
</PARA>
<PARA>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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Folder Tabs</EMPHASIS> 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Fly-Over Help</EMPHASIS> When the user pauses the mouse
over a button, "fly-over" pop-up help windows should
appear.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Grayed-out Form Help</EMPHASIS> Create grayed out
entries in the ledger, titled "Memo", "Description",
etc, helping users understand what should be typed into
each field. <EMPHASIS>Status:</EMPHASIS> Done, as of version
1.3.2(?)
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS><ULINK URL="http://www.emacs.org">emacs,</ULINK> vi,
motif, KDE, gnome Key Bindings for Text Fields</EMPHASIS> Make
sure that text fields can handle the vi and emacs key
bindings, so that <EMPHASIS>e.g.</EMPHASIS> emacs-style ctrl-a,
ctrl-k does the right thing.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="MISC"><EMPHASIS>Miscellaneous Small
Projects</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> A variety of small projects (mostly in the one person-week
range):
<ITEMIZEDLIST>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>File Format</EMPHASIS>. Rework miscellaneous file
storage to use Sleepy Cat DB. <EMPHASIS>Status:</EMPHASIS> RLB, 2
weeks.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Reconcile Window</EMPHASIS>. <EMPHASIS>Status:</EMPHASIS> Dave.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Print Register Window</EMPHASIS>. Output register window
to printer. <EMPHASIS>Status:</EMPHASIS> none
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>gtkhtml</EMPHASIS>. Grib.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>print</EMPHASIS>. Grib.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>key-val pairs</EMPHASIS>. Grib.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>guid in fileio</EMPHASIS>. Dave.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Engine validity test suite</EMPHASIS>.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS>Reconcile groups</EMPHASIS>.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> </PARA>
<PARA><EMPHASIS># of decimal places in prices (penny
stock)</EMPHASIS>.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="BOOK"><EMPHASIS>Books, Accounting Periods</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Ability to close the book at end of the fiscal year. This
consists of several steps:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Permanently lock some transactions as non-editable.
This should be straight-forward by using the <ENVAR> reconciled</ENVAR> field to indicate a <ENVAR>locked</ENVAR>
value, and not allowing the GUI to edit locked
records.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Transfer the Income minus Expense for the book period
to an equity account, so that each new period starts with
zero income/expense balances.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>A mechanism to purge really old transactions from the
database.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Extensions to reporting infrastructure ...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> A user should be allowed to 'delete' an account <EMPHASIS> only</EMPHASIS> if it has no transactions in the currently
open book.
</PARA>
<PARA>Of course, it's not deleted from the old books.
</PARA>
<PARA>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 ...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Memorized Transactions ... Currently, transaction
autocompletion works by autocompleting with the last
'similar' transaction. This ability will get trashed when
books for the old year get closed, because there won't be
'similar' transactions.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>A mini-design doc exists in
src/engine/future.txt
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
<GLOSSDEF>
<PARA><ANCHOR ID="CHECK"></PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><EMPHASIS>Check Printing</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Create a check-printing ability.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Bill Gribble has built a prototype based on the
gnome-print. Waiting for gnome-print to mature ...
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="USERPREF"><EMPHASIS>User Preferences</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Create menu system and file format for manipulating user
preferences. Preferences include things like default
currency, register layout and colors, etc.
</PARA>
<PARA>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
...
</PARA>
<PARA>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 (?)
</PARA>
<PARA>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.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Works good; lots of preferences in the gui.
Implemented in home-grown scheme.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>These are saved in the '.gnucash/config.auto' file.
The current file format is raw scheme code, rather
delicate to tweak by hand ...
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="EXT"><EMPHASIS>Extension Language Support</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 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.
</PARA>
<PARA>The overall architecture is envisioned thus:
</PARA>
<PARA>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.
</PARA>
<PARA>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 <EMPHASIS>highly</EMPHASIS> desirable to be able to, in
some manner, import new modules <EMPHASIS>without</EMPHASIS> requiring
that the application itself be recompiled and relinked.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Scheme/Guile is the central extension language.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Optional interfaces to the data engine can be
generated using <ULINK URL="http://starship.skyport.net/crew/beazley/swig.html"> SWIG</ULINK>.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Rob Browning is the reigning expert.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="ALERTS"><EMPHASIS>Recurring Transactions, Calander
Alerts</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> (1)Add support for automatic, recurring transactions, <EMPHASIS> e.g.</EMPHASIS> mortgage payments, fixed-interest bonds, regular
salary checks, regular gas/phone/electric bills, <EMPHASIS> etc.</EMPHASIS>
</PARA>
<PARA>(2) Recurring bills, salary income, etc. are simpler to
handle, since they don't have intersest rates, balloons,
etc. They do/will have multiple splits (<EMPHASIS>e.g.</EMPHASIS>
payroll gross, fica, futa, income taxes, payroll net).
</PARA>
<PARA>(3)Provide list of upcoming &amp; recently paid
bills/scheduled payments/scheduled deposits for the next
1,2,3,6,12 months. Historical view shows payments crossed
out (!?)
</PARA>
<PARA>(4)Loans &amp; mortgages are one of the more complicated
recurring transactions. Typically, there might be a years
worth of smaller payments, then a long string of larger
payments, followed by a baloon.
</PARA>
<PARA>(5)Provide a calender-display of upcoming &amp; 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.
</PARA>
<PARA><EMPHASIS>Design Notes:</EMPHASIS> Most alerts &amp; data storage
should be driven out of the engine. This will enable
multi-user, distributed use. <EMPHASIS>Note:</EMPHASIS> 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.)
</PARA>
<PARA>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 ... (<EMPHASIS>e.g.</EMPHASIS> depreciation schedules ...
under us tax law, a variety of different schedules are
allowed ... )
</PARA>
<PARA>May need interfaces to email for emailed alerts.
</PARA>
<PARA>Plot forcast graphs based on scheduled income &amp;
payments ... is this tied into budgeting ????
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Need to create design doc, need to implement engine
pieces, need to hunt down gnome-calendering bonobo.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>RLB thinks its 2-3 weeks for items 1,2,3.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="BUDGET"><EMPHASIS>Budgeting</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Ability to create a budget (<EMPHASIS>i.e.</EMPHASIS> - estimates of
future expenditures). Reconcile actual expenditures against
future expenditures. Create simple, step-by-step 'financial
plan' budgeting GUI's:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Home purchase planner
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Retirement planner
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>College tuition planner
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Debt reduction planner
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Scrimp-n-Save planner
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Special purchase planner (big ticket items)
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
Create a summary budget/track-record budget report that a
professional financial planner/advisor could use.
</PARA>
<PARA>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.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>A design doc has been submitted by Bob Drzyzgula.
Take a look at <FILENAME>./src/budget.txt</FILENAME> in the source
directory.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Bryan Larsen has begun work .. it's scheme based ...
Dave Peticolas has some gui roughed out ...
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="QUICKIM"><EMPHASIS>Quicken(TM) Import</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Ability to import Quicken QIF files. Both MSMoney and
Quicken use QIF files to export data.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Quicken import is implemented and mostly works. (Bill
Gribble, Done, in version 1.4.0)
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Work needs to be done for recurring transactions,
etc.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>QIF processing, as used for on-line banking, is <EMPHASIS> not</EMPHASIS> implemented. That is, staged import isn't done.
Note that since banks use QIF, the <EMPHASIS>correct</EMPHASIS> 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 ... Grib estimates 2 weeks for
this.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="QUICKEX"><EMPHASIS>Quicken(TM) Export</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Ability to export Quicken QIF files.
</PARA>
<PARA>Several design alternatives are apparent:
<ITEMIZEDLIST>
<LISTITEM>
<PARA> A special 'report' that writes out qif could be
created.
</PARA>
<PARA>This would use the 'reports' infrastructure to
generate qif's.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>It is fairly easy to traverse the data in the engine
to write out qif files. Just do it.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS> not started
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="QUOTE"><EMPHASIS>Stock Quotes, Price
Quotes</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Add ability to obtain stock, mutual fund, and currency
trading data from news agencies, web pages. Add ability to
download historical prices as well. (<EMPHASIS>e.g.</EMPHASIS> get
5-year history of mutual fund performance vs. djia).
</PARA>
<PARA>Right now, stock prices are stored along with everything
else, in the main database, in the transaction table. This
leads to several aesthetic quandries.
<ITEMIZEDLIST>
<LISTITEM>
<PARA>It bulks up the database with 'less-than critical'
information. That's bad. We need an alternate storage
mechanism.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Currently, the transactions stored in the engine are
either 'critical' <EMPHASIS>viz.</EMPHASIS>, record the movement of
money, or are non-critical <EMPHASIS>viz.</EMPHASIS> record things
retreivable from the historical record, <EMPHASIS>e.g.</EMPHASIS>
prices. This alone is a good reason to ask that price
&amp; other non-critical financial data be stored in a
separate location. Add to this the idea that we should
probably store other 'technical' stock data, such as
share volume, high/low/close, daily volatility, etc.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Quotes.pm can obtain stock quotes from Yahoo (NYSE),
Fidelity Investments, T.Rowe Price, and do automated
update of GnuCash data files (with the <APPLICATION>gnc-price</APPLICATION>
perl script). Need to add more data sources. See <FILENAME> src/quotes/Quote.pm</FILENAME> and <FILENAME> src/quotes/gnc-prices</FILENAME> for details.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://sourceforge.net/project/?group_id=4232"> Quote.pm</ULINK> is now a separate development project at
SourceForge.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Need to integrate with GUI. Right now, this is a
stand-alone perl script run from <APPLICATION>crontab.</APPLICATION> RLB
has written scheme wrappers for the module. Its ready
now, but not checked into cvs. Will be in 1.5.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>A separate, historical-quote module can be found at
the <ULINK URL="http://sourceforge.net/project/?group_id=2403"> QuoteHist</ULINK> sourceforge site. It might be a good idea
to fold this together with the Quote.pm module !?
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="INSTALL"><EMPHASIS>Install</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Install on Redhat, Caldera, Corel, SuSE, FreeBSD,
TurboLinux, etc.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="CURRENCY"><EMPHASIS>Multiple Currencies</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 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.
</PARA>
<PARA>A simplfied way of dealing with one-shot currency
exchanges needs to be implemented, essentially just a
simple calculator popup.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS> Need to rethink wether the one-shot
exchanges should in fact be recorded full-fledged in the
engine. Also: EURO support is currently hacked in: the EURO
is treated as a 'special' currency. Virtually all the euro
code can be fully generalized (and should be).
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="DOUBLE"><EMPHASIS>Forced Double-Entry</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> The system supports double-entry: every transaction
indicates a pair of accounts: one is debited, and one is
credited.
</PARA>
<PARA>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 <EMPHASIS>can</EMPHASIS>
create dangling transactions, where only one account is
indicated.
</PARA>
<PARA>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.)
</PARA>
<PARA>It must be possible to enforce double entry, so that a
transaction cannot be completed until two accounts have
been specified.
</PARA>
<PARA><EMPHASIS>Restricted Double</EMPHASIS> 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.
</PARA>
<PARA><EMPHASIS>Current status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Dec 1998 -- Scrubber functions implemented to crawl
through data, and find all unbalanced or orphaned
transactions.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>May 2000 -- Default will be changed to double-entry
always. It will not be possible to disable this and move
to single-entry.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="I401K"><EMPHASIS>401(k), RSP</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 401K, 403, IRA, Roth IRA, SEP, Keogh ... "Retirement Savigs
Plans"
</PARA>
<PARA>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??)
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="NOTE"><EMPHASIS>Annotate with News Stories</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Download, save, annotate investment news and research.
</PARA>
<PARA>Provide a way of storing news stories with accounts, and
possibly annotating individual transactions in the same
way.
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="LOAN"><EMPHASIS>Loan and Mortgage
Calculators</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Provide a variety of simple GUI utilities to allow user to
calculate the future value of loans, mortgage payments,
interest payments, etc.
</PARA>
<PARA>Consider the following dialogue layout:
<LITERAL REMAP="TT"><MSGTEXT>
<LITERALLAYOUT>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/ length -----(weeks/months/years/payments)
loan time left (number of days/weeks/months, rounded)
number of payments left
interest rate %__________________
payee ____________
pay-from account __________________
next due date mm/dd/</LITERALLAYOUT>
</MSGTEXT></LITERAL>
Note that in the above, not all fields are independent:
some can be calculated from others. The <EMPHASIS>other
payment</EMPHASIS> should bring up a mini-register, allowing user
to add any number of splits.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Not Started.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="OVERDRAFT"><EMPHASIS>Overdraft Alerts</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 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 &amp; lows. Note that these
alerts do <EMPHASIS>not</EMPHASIS> require any sort of calendaring or
recurring transaction support.
</PARA>
<PARA>Design requirements: implement multiple (not just two)
alerts for any account type. Alert should consist of
<ITEMIZEDLIST>
<LISTITEM>
<PARA>value point or price point
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>movement direction
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>'is active' boolean flag (<EMPHASIS>i.e.</EMPHASIS> Should be
possible to 'turn off alert' without deleting it)
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>memo text
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Not Started.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="TECH"><EMPHASIS>Technical Stock Analysis</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Provide technical stock analysis graphs, <EMPHASIS>e.g.</EMPHASIS>
volume, 90 moving avg, beta, etc. See gstalker for example of
how to do it ...</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="SINK"><EMPHASIS>Depreciation, Sinking
Funds</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Hmm ... some variation on the concept of loans? Need to
support different deprciation schedules (see IRS books for
that).</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="OFX"><EMPHASIS>OFX support</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 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.
</PARA>
<PARA>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 <ULINK URL="http://www.ofx.net">OFX Home Page</ULINK> for
details.
</PARA>
<PARA>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.
<ITEMIZEDLIST>
<LISTITEM>
<PARA>The parser is fragile because minor DTD
non-compliances are hard to parse, handle and recover
from.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>The parser is huge because the DTD results in
hundreds of (C++) objects being generated.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
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.
</PARA>
<PARA>Run-time parsing may be slower, but on the OFX client
side, this should not be a bottleneck.
</PARA>
<PARA><EMPHASIS>Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>A compile-time parser was developed and
abandoned.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA>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.
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><EMPHASIS>Other on-line support</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> the German T-Online
homebanking system BTX.
</PARA>
<PARA> In 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.
</PARA>
<PARA> 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.
</PARA>
<PARA> Some words to the features of ZKA4BTX :
<ITEMIZEDLIST>
<LISTITEM>
<PARA> Completely written in Tcl</PARA>
</LISTITEM>
<LISTITEM>
<PARA> Uses Xcept as a BTX browser</PARA>
</LISTITEM>
<LISTITEM>
<PARA> Retrieve account data from multiple banks</PARA>
</LISTITEM>
<LISTITEM>
<PARA> Send transfers, using TAN</PARA>
</LISTITEM>
<LISTITEM>
<PARA> Export retrieved account data to CBB, Xfinans and QIF files </PARA>
</LISTITEM>
<LISTITEM>
<PARA> Export retrieved account data to CBB, Xfinans and QIF files</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA> 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.
</PARA>
<PARA> 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.
</PARA>
<PARA>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.
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="TAB"><EMPHASIS>Tab-delimited ASCII file
format</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> People <EMPHASIS>like</EMPHASIS> 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 <FUNCTION> printf()</FUNCTION>s.
</PARA>
<PARA>The tab-delimited format should be compatible with that
of <APPLICATION>/rdb</APPLICATION>, aka <ULINK URL="ftp://ftp.rand.org/pub/RDB-hobbs/">RAND/Hobbs /rdb</ULINK> or
<ULINK URL="ftp://ftp.linux.it/pub/database/RDB/nosql-0.8.tar.gz"> NoSQL.</ULINK> (NoSQL is available as part of the <ULINK URL="http://www.debian.org">Debian GNU/Linux</ULINK> distribution,
for instance.)
</PARA>
<PARA>The <APPLICATION>/rdb</APPLICATION> format is thus:
<LITERAL REMAP="TT"><MSGTEXT>
<LITERALLAYOUT>field-name tab fieldname tab fieldname \n
------------------------------------------ \n
value tab value tab value \n
value tab value tab value \n
etc ...</LITERALLAYOUT>
</MSGTEXT></LITERAL>
</PARA>
<PARA>It is a very simple, very basic flat table format. The
use of <APPLICATION>/rdb</APPLICATION> with GnuCash should try to match with
SQL schemas as much as possible in order to minimize I/O
complexity and incompatibility.
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="TAX"><EMPHASIS>Tax Preparation</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Gotta prepare those taxes.
<ITEMIZEDLIST>
<LISTITEM>
<PARA> TurboTax
</PARA>
<PARA>categorize items according to different tax
schedules
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>VAT
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>estimate income taxes
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>estimate itemized deductions, find potential
deductions, categorize them
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="PALM"><EMPHASIS>Sync with Palm Pilot
organizers</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>There are Quicken-workalikes that run on the
PalmComputing platform; it would be good to inter-operate
with this. See <ULINK URL="ftp://ryeham.ee.ryerson.ca/pub/PalmOS/">PalmLink</ULINK> and <ULINK URL="http://www.orbits.com/Palm/">Palm &amp; Linux</ULINK>.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="EMERG"><EMPHASIS>Emergency Records
Organizer</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Put together a single-page report showing critical info
about accounts, etc.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="ENGINE"><EMPHASIS>Enriched Engine, Financial
Objects</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> 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.
</PARA>
<PARA>The current engine is rather simple: it provides support
for accounts, account hierarchies and transactions
consisting of multiple entries.
</PARA>
<PARA>Many of the features described elsewhere will require
that the engine have a far richer, more sophisticated data
model, including such things as:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>Linking to "Address Info" ( <EMPHASIS>e.g.</EMPHASIS> names,
addresses)
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Transaction identifiers
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Part numbers, SKU IDs
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Interest rates
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Budget policy
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA>Note: it makes no sense at this point to make the engine
API much richer than what the GUI can currently
support.
<ITEMIZEDLIST>
<LISTITEM>
<PARA><EMPHASIS>Locks</EMPHASIS> 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).
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> <EMPHASIS>Books</EMPHASIS> 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.
</PARA>
<PARA>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
<EMPHASIS>very</EMPHASIS> tightly controlled, or even outright
forbidden.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
<PARA><EMPHASIS>Current Status:</EMPHASIS>
<ITEMIZEDLIST>
<LISTITEM>
<PARA>The basic engine has been detangled from the GUI
elements, as of version gnucash-1.1.4.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Binary file I/O mostly detangled into a separate
module.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Crude transaction logging/auditing in place; should
be suitable for error/crash recovery but has not been
"tried by fire."
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Backup files automatically created and
time-stamped.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> <FUNCTION>BeginEdit()/RollbackEdit()/CommitEdit()</FUNCTION>
routines mostly in place,
</PARA>
<PARA>These "Transaction processing constructs" should
simplify creation of an SQL back end, or some other
more sophisticated database engine.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Multiple currency support is present but still pretty
"raw."
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Query engine is minimal/sparse in capabilities.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Linas &lt;linas@linas.org&gt; is maintaining the
engine code.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="SQL"><EMPHASIS>SQL I/O</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> A module is necessary to allow data to be fetched from an
SQL database, and for that database to be updated.
</PARA>
<PARA>There has been <EMPHASIS>much</EMPHASIS> discussion about this on
mailing lists both for GnuCash and <ULINK URL="http://www.menet.umn.edu/~curt/cbb/">CBB.</ULINK> Major points
have included:
<ITEMIZEDLIST>
<LISTITEM>
<PARA> Those SQL databases available on Linux tend to involve
considerable <EMPHASIS>administrative</EMPHASIS> overhead in terms
of getting them set up.
</PARA>
<PARA>This may be a minor cost to a business enterprise
that routinely hires DataBase Administrators.
</PARA>
<PARA>It is <EMPHASIS>not</EMPHASIS> acceptable to require this of
naive users that may find "simple" things like
<LITERAL REMAP="TT"><MSGTEXT>
<LITERALLAYOUT>% su -
Password:
# cd /tmp
# rpm -i gnucash-4.1.3.i386.rpm
# exit</LITERALLAYOUT>
</MSGTEXT></LITERAL>
to be challenging.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> It might be useful to use an embedded database engine
like unto <ULINK URL="http://www.sleepycat.com/">Sleepycat
DB</ULINK>, <ULINK URL="ftp://koobera.math/uic.edu/www.cdb.html">cdb,</ULINK> or
something like <ULINK URL="http://www.opengroup.org/public/prods/dmm4.htm"> ISAM</ULINK> (Note CQL++ supports ISAM access methds), or
even an embedded SQL engine such as <ULINK URL="http://www.ispras.ru/~knizhnik/gigabase.html"> GigaBASE</ULINK>.
</PARA>
<PARA>The reasons to do so include:
<ITEMIZEDLIST>
<LISTITEM>
<PARA> The use of a database allows only that data which
is actually <EMPHASIS>in use</EMPHASIS> to be loaded into
memory.
</PARA>
<PARA>This permits managing larger sets of
transactions more efficiently.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>It also allows data to be pushed out to the DBMS
<EMPHASIS>immediately after entry,</EMPHASIS> rather than waiting
for the user to "save the books."
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> By using a well-known DBMS, outside programs are
provided a well-defined way of getting at, and
perhaps even modifying, GnuCash data.
</PARA>
<PARA>Interoperability is generally considered a good
thing...
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> GnuCash presently uses a document-oriented model, where
the <EMPHASIS>entire</EMPHASIS> set of books are loaded in, and
dumped out, all at one fell swoop.
</PARA>
<PARA>GnuCash needs to be modified to access the database
in a transactional manner. This is at least partly
implemented with the <FUNCTION>Begin()/End()</FUNCTION> constructs
in the engine.
</PARA>
<PARA>Some transactional thoughts: entire SQL
tables/databases do not need to be locked while the
user is editing a transaction via the GUI.
</PARA>
<PARA>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.
</PARA>
<PARA>Important note: updating SQL does <EMPHASIS>not</EMPHASIS>
require locks to be held for extended periods of
time!
</PARA>
</LISTITEM>
<LISTITEM>
<PARA> The SQL engine chosen should be fully transactional,
passing the 'ACID' test (Atomicity, Consistency,
Isolation, Durability).
</PARA>
<PARA>Note that <ULINK URL="http://openacs.org/why-not-mysql.html">MySQL does not
satisfy the 'ACID' criteria</ULINK>.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="MULTIUSER"><EMPHASIS>Multi-user Support</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Multi-user support should be added with either an SQL
backend to the engine, and/or through CORBA interfaces to
the engine.
</PARA>
<PARA>Project Kontor and also FreeMoney is working on SQL
schemas; Kontor is also working on Java RMI/CORBA
interfaces.
</PARA>
<PARA>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.
</PARA>
<PARA>The following industrial-strength features are
needed:
<ITEMIZEDLIST>
<LISTITEM>
<PARA>transaction-oriented queuing of updates
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>event subscription channel for updates
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>user authentication
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>user authorization
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>non-repudiability
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>encryption of network connections
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="ARAP"><EMPHASIS>Accounts Payable,
Receivable</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Add features to track sales receipts and other pending
sources of income, as well as owed sums.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="PAYROLL"><EMPHASIS>Payroll</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA> Payroll introduces a <EMPHASIS>sizable</EMPHASIS> amount of complexity
in terms of the need to comply with constantly-changing
government regulations in whatever country one is in.
</PARA>
<PARA>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.
</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="INVOICE"><EMPHASIS>Invoicing</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Invoicing. To design an invoice, need to have a
mini-word-processor/simple drawing plug-in. Is
Abisource/Abiword a candidate? Probably needs bonobo...</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="ESTIMATE"><EMPHASIS>Job Costing</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Ability to prepare and track estimates.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
<GLOSSENTRY>
<GLOSSTERM><ANCHOR ID="XACC-EXPENSE"><EMPHASIS>Expense Accounts</EMPHASIS></GLOSSTERM>
<GLOSSDEF>
<PARA>Expense Account Automation, including air, car, hotel,
dining. Receipts, reservations, cancellations.</PARA>
</GLOSSDEF>
</GLOSSENTRY>
</GLOSSLIST>
</PARA>
</SECT1>
<SECT1 ID="XACC-REFERENCES">
<TITLE> References</TITLE>
<PARA> <ITEMIZEDLIST>
<LISTITEM>
<PARA><ULINK URL="http://gnucash.org/">GnuCash Home Page</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.hex.net/~cbbrowne/finances.html"> Christopher Browne's List of GNU/Linux Accounting
Software</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://gnucash.org/gnucash-devel/">Official
GnuCash mail archives</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.mail-archive.com/gnucash-devel@gnucash.org/"> GnuCash Mail archives</ULINK> -- alternate.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.pathcom.com/~sstratos/">gstalker</ULINK>
gtk/gnome stock grapher.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://prope.insa-lyon.fr/~rhertzog/geniustrader/">Genius
Trader</ULINK> stock graphing tool. Based on Perl and Tk.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.daveware.com/linuxrapid.html"> Xrapid</ULINK> stock technical analysis.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://getquote.giammy.com/">GetQuote</ULINK> is a
command-line toll for getting stock quotes. Implemented in
C.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://sourceforge.net/project/?group_id=3522"> Accountant</ULINK> project at sourcforge aims to create a generic
business library.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.ios-online.de/Linux-Kontor/"> Linux-Kontor</ULINK> - an industrial accounting package that uses
Java and SQL databases.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.pango.org/">Pango</ULINK>
internationalized text rendering for gtk.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.gnu.org/projects/gnue/gnue.html">Gnu
Enterprise</ULINK> a business financial project.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://members.iweb.net.au/~steveoc/ERP/index.html ">ERP</ULINK>
Business Accounting project
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://obelisk.dhs.org">Obelisk</ULINK> Business
Accounting project
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.didx.com/xml-builder.html">XML
Builder</ULINK> allows GUI screens to be described using XML
markup. See also mozilla.org's xpfe ...
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.ofx.net/">Open Financial Exchange</ULINK>
a consortium backed by Intuit, CheckFree and Microsoft do
advance on-line banking.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://http://www.otp.org/">Open Trading
Protocol</ULINK>. An XML-based message protocol for payment,
invoice presentation, and payment receipts.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.semper.org/">Secure Electronic
Marketplace for Europe</ULINK>. SEMPER is a European R&amp;D
project in the area of secure electronic commerce over open
networks.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>HBCI 2.0: Homebanking Computer Interface
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://ganges.cs.tcd.ie/mepeirce/Project/oninternet.html"> Payment mechanisms designed for the Internet</ULINK> provides a
treasure-trove of links for zillions of standards and
proposals.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.sabotage.net/redhat/ssl.html">SSLeay
RPM's</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.sabotage.net/security/ecash/lucre/"> -lucre</ULINK> a publicaly available version of e-cash.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.openapplications.org/">Open
Applications Group</ULINK> is developing specs for accounting
systems.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.compassgl.org/newhometest/990305fr1.html">OMG
General Ledger (GL) Facility</ULINK> The Compass submission for
the OMG (CORBA) General Ledger.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.xfrml.org/">XFRML, XML-based
Financial Reporting Markup Language</ULINK>. Quote from their
site: <EMPHASIS>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.</EMPHASIS>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.ibm.com/java/sanfrancisco">IBM San
Francisco</ULINK> Business and Financial Java classes.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.integrion.com/">Integrion</ULINK>, a
16-bank + IBM consortium aimed at building up on-line banking
infrastructure. Mostly aimed at mainframes, middleware, high
transaction volumes and data integrity.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.sun.com/980224/javapos/">Java Point
of Sale</ULINK> interfaces.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="ftp.gnu.org:/pub/gnu/plotutils/">Gnu
Plotutils</ULINK> needed for building the graphing portions of
the code.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.im.lcs.mit.edu/~magnus/ml/">partly
finished GTK grid widget</ULINK> may be better than Clint,
gtktable.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://glade.pn.org/">Glade</ULINK> an XML-based
GTK+ User Interface Builder
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="www.php.net">PHP-3</ULINK> for html-embedded
perl-like language.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.engelschall.com/sw/eperl">Embedded
Perl</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.transaction.net/money/">How Money
Works</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.penguincomputing.com/antarctic.html"> Antarctic Project Server</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.im.lcs.mit.edu/~magnus/ml/">Maxwell's
Lemur -- a GTK based table widget</ULINK>
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.ispras.ru/~knizhnik/gigabase.html"> GigaBASE</ULINK> embeddabale SQL database.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
</PARA>
</SECT1>
<SECT1 ID="XACC-ARCHAEOLOGY">
<TITLE> Historical References</TITLE>
<PARA> 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.
<ITEMIZEDLIST>
<LISTITEM>
<PARA><ULINK URL="http://www3.hmc.edu/~rclark/xacc/">X-Accountant
Home Page</ULINK> - 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>The original <ULINK URL="http://www.dnaco.net/~bcooper/watermark/index.html"> WaterMark</ULINK> 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.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA><ULINK URL="http://www.telly.org/freemoney/">FreeMoney</ULINK>
Linux small-business accounting s/w. A proposal to build a
business package back by SQL.
</PARA>
</LISTITEM>
</ITEMIZEDLIST>
Draft version 0.38 -- June 2000 Linas Vepstas <ULINK URL="mailto:linas@linas.org">linas@linas.org</ULINK>
updates by Christopher Browne <ULINK URL="mailto:cbbrowne@ntlug.org">cbbrowne@ntlug.org</ULINK>
</PARA>
</SECT1>
</ARTICLE>
Reference in New Issue View Git Blame Copy Permalink