mirror of
https://github.com/Gnucash/gnucash.git
synced 2024-11-23 01:16:43 -06:00
a7fc5550c0
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@4766 57a11ea4-9604-0410-9ed3-97b8803252fd
2846 lines
102 KiB
HTML
2846 lines
102 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
|
|
<html>
|
|
<head>
|
|
<title>GnuCash Project Goals</title>
|
|
<meta name="description" content= "The Linux GnuCash project
|
|
aims at creating a world-class personal finance package.
|
|
Goals include ease-of use, double entry, OFX support,
|
|
charts, and reports, and multi-user support.">
|
|
<meta name="keywords" content= "linux, OFX, accounting, finance,
|
|
financial, ledger, double entry, GPL, gnu">
|
|
</head>
|
|
|
|
<body bgcolor="#d6dacb" fgcolor="#000000">
|
|
|
|
<div align=center><a href="http://www.gnucash.org/" target="_top">
|
|
<img border=0 width=470 height=62 alt="GnuCash Personal Finance Manager"
|
|
src="GnuCash_Long.jpg"></a><br>
|
|
</div>
|
|
|
|
<h1>GnuCash Project Goals</h1>
|
|
|
|
<p>
|
|
The people behind <a href="http://www.gnucash.org">GnuCash</a>
|
|
aim to create a world-class GPL'ed Open Source Personal
|
|
Financial Application for GNU/Linux and other Unix's. This page
|
|
reviews some of the technical issues and development status
|
|
surrounding this project. It is a kind of an <b>FAQ</b> 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 <a href=
|
|
"http://www.gnucash.org">GnuCash</a> is and what it does, visit its
|
|
<a href="http://www.gnucash.org">home page</a>. The home page
|
|
contains screen shots, news items, and mailing list
|
|
archives.
|
|
</p>
|
|
|
|
<p>
|
|
There are currently several different versions of GnuCash.
|
|
We've adopted the kernel numbering scheme: even minor release
|
|
numbers (1.4.x, 1.6.x) are considered to mark stable releases,
|
|
while odd numbers (1.5.x, 1.7.x) mark development releases.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>The current stable, production release is gnucash-1.6.0 and
|
|
is based on the <a href= "http://www.gnome.org">Gnome</a> /
|
|
<a href= "http://www.gtk.org">GTK</a> libraries.
|
|
</li>
|
|
|
|
<li>The 1.7.x releases focus on adding new features and
|
|
improving existing functionality.
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
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
|
|
beginning users should probably stick to version gnucash-1.6.0.
|
|
More adventurous users can try one of the 1.7.x releases, However,
|
|
keep in mind that they are in a state of constant change and will
|
|
often be unstable.
|
|
</p>
|
|
|
|
<p>This document is divided into several sections.</p>
|
|
|
|
<ol>
|
|
<li><a href="#arch">Architectural Goals</a></li>
|
|
|
|
<li><a href="#reqs">Requirements</a></li>
|
|
|
|
<li><a href="#size">Sizings</a></li>
|
|
|
|
<li><a href="#feats">Features</a></li>
|
|
</ol>
|
|
<hr>
|
|
<!--===================================================-->
|
|
<a name="arch">
|
|
<h1>Architectural Goals</h1>
|
|
</a>
|
|
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.
|
|
|
|
<h2>Separation of GUI and Data</h2>
|
|
First, we must maintain a clean separation between the data
|
|
structures and the GUI that manipulates them, along the lines
|
|
of the <b>Model-View-Controller</b> paradigm.
|
|
|
|
<ul>
|
|
<li>Lists of accounts and the transactions in them can be
|
|
thought of as a representation of financial data, a
|
|
<b>Model</b>.
|
|
</li>
|
|
|
|
<li>The GUI that adds, modifies and deletes these should be
|
|
thought of as a manipulator of the data, a <b>Controller</b>.
|
|
Thus, the Motif or Gnome GUI's are merely two possible
|
|
manipulators of the data; others, based on <i>e.g.</i>
|
|
web/cgi-bin, Qt/KDE, emacs, Java applets or Java servlets
|
|
ought to be possible.</li>
|
|
|
|
<li>The <b>View</b> of the data is a subset or slice of the
|
|
data described by the Model. The View may consist of only the
|
|
transactions for the month of May, or only the account totals
|
|
for certain accounts. The View is used in part to generate
|
|
the reports and graphs, but it is also that which the
|
|
Controller interacts with. Views are generated by queries to
|
|
the data store.</li>
|
|
</ul>
|
|
|
|
<p>
|
|
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.</p>
|
|
|
|
<p>
|
|
Thus, the <b>View</b> essentially represents a local data
|
|
cache of the data that is immediately present and being
|
|
displayed, reported, and manipulated. The <b>Model</b> is the
|
|
abstraction of that data that the GUI (the controller) can act
|
|
on.</p>
|
|
|
|
<h2>The Financial Engine</h2>
|
|
In GnuCash, the Model is implemented via the <b>Engine</b> API,
|
|
and the View is the data that is currently in the <b>
|
|
Engine</b>. Thus, the Engine is a set of programming API's that
|
|
the GUI (or a script, or even a clever command-line-addict) can
|
|
use to manipulate the data.
|
|
|
|
<p>
|
|
Currently, the Engine provides basic accounting structures
|
|
These include: </p>
|
|
|
|
<ul>
|
|
<li><b>Transactions</b>, which consist of a set of 'splits'
|
|
or journal entries (JE's) whose values sum to zero.
|
|
The transaction includes several date fields, a description,
|
|
and a common-currency field, and a universal unique id
|
|
(uuid/guid). It also provides hooks to store arbitrary data
|
|
associated with the transaction (using a URL-based key-value tree).
|
|
</li>
|
|
|
|
<li><b>Journal Entries</b> (internally referred to as
|
|
'splits') which an amount and the account on which it is drawn.
|
|
Splits also store reconcile status, dates, a memo field,
|
|
and also a key-value based hook for arbitrary data.
|
|
</li>
|
|
|
|
<li><b>Accounts</b>, which include a nme, a type, a description
|
|
field, and the type of commodity they store. Principlally,
|
|
the account consists of a list of journal entries.</li>
|
|
|
|
<li><b>Chart of Accounts</b>, which is a hierarchical tree of
|
|
accounts.</li>
|
|
</ul>
|
|
|
|
The Engine has a basic two-phase commit model, and a
|
|
query mechanism for finding the data needed for reports and
|
|
views. The goal of the two-phase commit and query model is
|
|
allow the creation of multi-user server based backends, such
|
|
as an SQL backend, and RPC client-server backend, or an
|
|
XML-based HTTP/web backend. This design seems to work
|
|
for the above-named backends.
|
|
|
|
<p>The Engine currently handles only a basic set of data
|
|
sources:</p>
|
|
|
|
<ul>
|
|
<li>It can import and merge in QIF's (actually, this function
|
|
has been moved into the GUI, and is no longer part of the
|
|
engine);
|
|
</li>
|
|
|
|
<li>It can read and write its own XML byte stream;
|
|
This ability has been used to provide a multi-user
|
|
client-server demo (which is currently broken).
|
|
</li>
|
|
|
|
<li>It can use a Postgres SQL database as a datastore, thereby
|
|
enabling multi-user and auditing functions.
|
|
</li>
|
|
|
|
<li>It can talk, via RPC, to a gnucash server. (This code is
|
|
'alpha' and incomplete/broken).
|
|
</li>
|
|
|
|
<li>It can get stock quotes from the net (actually, this
|
|
function is provided by a separate module, the Finance::Quote
|
|
perl module.)
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
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 create a peer-to-peer
|
|
network model, where gnucash peers can synchronize data between
|
|
themselves. The engine should also be expandable to handle other
|
|
sources of data, such as OFX/IFX, the Open Trading Protocol, or
|
|
the OMG CORBA General Ledger submission. In particular, it
|
|
should be possible to use GnuCash not only to view data from
|
|
these sources, but also to manipulate it and send it back.
|
|
</p>
|
|
|
|
<h2>Modularity, Extensibility and Customization</h2>
|
|
|
|
<p>The above structure should lead us to view GnuCash not so
|
|
much as a tightly integrated application, but rather as a loose
|
|
confederation of component objects, libraries and interfaces.
|
|
This has a number of advantages for both the deeloper and the
|
|
user. For the developer, it allows parts to evolve semi-independently
|
|
of one-another, and to be used in other, non-gnucash projects.
|
|
For the user, a good extensibility allows the use of
|
|
<a href="#arrangements">arrangements</a>: a way of broadly
|
|
customizing the appearence and behaviour of gnucash, and then
|
|
allowing users to very easily share these customizations with
|
|
one another. Such arrangements might be collections of canned
|
|
reports, e.g. for business or home user. Or they might be
|
|
the menu contents: one menu arrangement is for gbeginners, another
|
|
for 'power users', a third for business owners. Th goal is that
|
|
broad areas should be not only customizable, but it should be
|
|
possible, even easy, to trade these customizations between users.
|
|
</p>
|
|
<p>
|
|
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
|
|
<a href= "http://www.swiss.ai.mit.edu/projects/scheme/index.html">
|
|
Scheme</a> extension language (as implemented in the FSF
|
|
<a href="http://www.gnu.org/software/guile/guile.html">Guile</a>
|
|
interpreter), to glue the pieces together. (Note that the
|
|
engine interface is also available with
|
|
<a href="http://www.perl.org">Perl</a> interfaces, thanks to a
|
|
<a href="http://starship.skyport.net/crew/beazley/swig.html">SWIG</a>
|
|
wrapper.
|
|
</p>
|
|
|
|
<h2>A Web Browser for Financial Data</h2>
|
|
|
|
<p>More and more finacial data is moving onto the web.
|
|
People shop on-line. They pay bills on-line. There are
|
|
even some promising e-wallet systems (such as
|
|
<a href="http://www.webfunds.org">WebFunds</a>). For GnuCash
|
|
to be relevent in this on-line world, it must be able to interact
|
|
with these systems. There are several steps that can be taken
|
|
along this path. First, it must be possible to simply and
|
|
transparently import financial data off the web. Click on a QIF
|
|
file, mime-type "application/x-qif"? Gnucash sucks it in without
|
|
burping. But, in a more distant future, can GnuCash originate
|
|
transactions? It should be able to!
|
|
</p>
|
|
<p>
|
|
GnuCash can be and should be "The Sophisticated Financial Web Browser".
|
|
All GnuCash reports and the help system are HTML-based. In fact,
|
|
GnuCash has a built-in web browser that can view ordinary web sites.
|
|
Interactive gnucash components such as the bar and pie charts, or
|
|
the graphs and reports, can all be served up by a remote web server,
|
|
as well as locally through the GnuCash application. This allows
|
|
GnuCash to blur the line between web browser and financial application,
|
|
and offer the best of both worlds.
|
|
</p>
|
|
<p>
|
|
Why is this a good thing? One can always have a pure web-based
|
|
accounting solution (such as SQL-Ledger) that uses ordinary web
|
|
browsers to view the financial data. But there are problems:
|
|
dynamically-generated html and cgi-bins aren't as pretty or easy
|
|
to use, or as fast, responsive or sophisticated, as what you can
|
|
do with a custom client. That is, GnuCash can be more interactive,
|
|
easier to user, slicker and more professional looking in style
|
|
and presentation than a plain-old dynamic website. Financial
|
|
ASP's simply cannot currently offer the kind of utility, flexibility,
|
|
responsiveness and integration that GnuCash can offer.
|
|
</p>
|
|
<p>
|
|
In theory, the 'Java revolution' was supposed to provide this
|
|
function, with downloadable Java applets providing the 'fancier-
|
|
than-plain-html' interface. But a Java applet that is this
|
|
sophisticated would also be large and slow to download:
|
|
it offers no inherent advantages over native code. Another
|
|
problem with Java is the inherent propreitary fragmentation:
|
|
no two Java applets are alike: every site has thier own; there
|
|
is no standardization.
|
|
</p>
|
|
<p>
|
|
In order to solve the 'no gui standardization between websites'
|
|
problem, there are a number of businesses that have arisen to
|
|
provide "financial aggregation". You sign up with these sites,
|
|
and let them get all of your credit-card, bank and investment info,
|
|
and they can provide a unified interface for your bank statements,
|
|
with graphs and reports (all for a monthly fee). The existance of
|
|
these services highlights a problem: the inability to aggregate
|
|
the same data on the users desktop, in a simple, coherent fashion.
|
|
Let us posit that GnuCash, with the right on-line interfaces,
|
|
would be a natural for this. For the paranoid,
|
|
this has the added advantage that no one business has access to
|
|
all of your financial records.
|
|
</p>
|
|
|
|
<p>
|
|
To put it another way, GnuCash can provide a centralized, trusted
|
|
store for financial data that no other application can provide.
|
|
The convenience
|
|
factor: if you have trading accounts at e*trade and charles schwab,
|
|
then GnuCash can be the central place where you can oversee
|
|
<b>all</b> of your investments. The trust factor:
|
|
maybe you can trust your web bank. Maybe you can trust your web
|
|
stock account. But can you trust a single web entity with *all*
|
|
of your financial data? Someone who won't treat you as 'just
|
|
another consumer' and sell your 'consumer profile' to anyone who
|
|
cares to stalk (ahem, target) your financial activity (ahem,
|
|
purchasing) patterns? Didn't think so. Of course, you
|
|
*could* use some proprietary financial software. Assuming, of course,
|
|
that you trust it not to have any built-in covert channels:
|
|
nothing that might send back the make and model of your CPU and
|
|
the last ten transactions 'home to mommy' for 'diagnostic purposes'.
|
|
Because open source software, such as GnuCash, can be audited
|
|
it can be trusted in ways that no proprietary software can be.
|
|
In an increasingly net-connected world, the ability to build
|
|
trust through audits will be increasingly important.
|
|
</p>
|
|
|
|
<h2>Looking Into the Future</h2>
|
|
Things like support for OFX, and small-business features are
|
|
hopefully in the near term future of gnucash. Lets take a look
|
|
at some more far-out possibilities.
|
|
</p>
|
|
<dl>
|
|
<dt><b>E-Wallet</b></dt>
|
|
<dd>An e-wallet, just like a real wallet, stores cash. You
|
|
can use that cash to pay freinds or businesses. Just
|
|
like a real wallet, an e-wallet should not charge you
|
|
monthly fees. It should provide you with some measure
|
|
of anonymity and privacy. An e-wallet should also do
|
|
something no ordinary wallet can do: show you a monthly
|
|
report of expenditures. GnuCash should get e-wallet
|
|
features. </dd>
|
|
|
|
<dt><b>Authentication, Authorization and Access Control</b></dt>
|
|
<dd>How does an on-line merchant know that you are who you say
|
|
you are? How can you use GnuCash to authorize a bill payment?
|
|
Sooner or later, smart-cards will provide the sort of
|
|
authentication and access control that is only groped for
|
|
with PGP/GPG, keyrings, x.509 certificates, and Microsoft
|
|
Passport/Hailstorm. Of all the electronic things in the
|
|
electronic world where access control and authentication
|
|
are important, real money is the most so.
|
|
</dd>
|
|
|
|
<dt><b>Bill Presentment, Bill Pay</b></dt>
|
|
<dd>These magic keywords just mean that a merchant wants to
|
|
send you a bill, and wants you to go to thier website to
|
|
pay that bill (they want your eyeballs). Of course, for
|
|
the user, it would be more convenient to have the bill
|
|
show up on the desktop, inside of gnucash, and get authenticated
|
|
and paid out from the desktop (by gnucash), as you would
|
|
do with all of your other bills.
|
|
</dl>
|
|
|
|
<hr>
|
|
<!--===================================================-->
|
|
|
|
<a name="reqs">
|
|
<h1>Requirements</h1>
|
|
</a>
|
|
Lets take a look at who the current and potential future users
|
|
of GnuCash are, and how they might use it. The classes:
|
|
|
|
<ul>
|
|
<li>Basic Household Accounting/Budgeting</li>
|
|
<li>Personal Stock Portfolio Management</li>
|
|
<li>Personal On-line Trading (Day-Trading)</li>
|
|
<li>On-line shopping and bill-pay</li>
|
|
<li>Small Business Users</li>
|
|
</ul>
|
|
These different applications may use some of the same
|
|
financial terminology, and hopefully might share a fair
|
|
bit of code, but have quite different goals and requirements.
|
|
|
|
<h3>Basic Household Accounting and Budgeting</h3>
|
|
|
|
<p>Important properties of a personal finance system
|
|
include:</p>
|
|
|
|
<ul>
|
|
<li>Approachable and usable by occasional users
|
|
who are not knowledgeable about accounting.</li>
|
|
|
|
<li>Ease of use and simplicity is critical.</li>
|
|
|
|
<li>A reasonable selection of reports, graphs, charts, and
|
|
tools for personal finance, such as mortgage
|
|
calculations.</li>
|
|
|
|
<li>Budgeting support needs to be targeted at <em>naive</em>
|
|
users.</li>
|
|
|
|
<li>Interfaces to on-line banking, shopping, stock
|
|
systems. Bank and credit-card statements should
|
|
arrive 'automatically' and always be up-to-date.</li>
|
|
</ul>
|
|
|
|
<h3>Personal Portfolio Management</h3>
|
|
|
|
<ul>
|
|
<li>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.</li>
|
|
<li>Reporting infrastructure needs to simplify handling of
|
|
tax issues (long-term vs. short-term capital gains/losses,
|
|
cost-basis FIFO accounting, simplfied cost-basis
|
|
spinoff/merger handling). Need on-line updates of
|
|
prices, simple portfolio overview, ability to link
|
|
to websites for additional research.
|
|
<li>Integration with on-line trading systems. This could
|
|
save time typing.
|
|
<li>Basic Audit features. There's a problem with blindly
|
|
allowing on-line data (prices, transactions) to enter
|
|
GnuCash. It may not be clear where it came from,
|
|
and even if the source is beleived to be 'reputable',
|
|
there still may be factual errors in the data. Thus,
|
|
there must be a way of audting newly-arrived (or even old)
|
|
on-line data, and mark it as 'reconciled', i.e.
|
|
manually reviewed and checked for accuracy. That is,
|
|
incoming on-line data must be auditable, and audit
|
|
trails should mark the history of on-line data import.
|
|
</ul>
|
|
|
|
<h3>Small Business Needs</h3>
|
|
|
|
<ul>
|
|
<li>With a business system, it is likely that there will be
|
|
users who use it eight hours a day, which puts the emphasis
|
|
on <em>efficiency</em> of user interface rather than on its
|
|
approachability to naive users.</li>
|
|
|
|
<li>Business systems require network support, and the ability
|
|
to support multiple simultaneous users.</li>
|
|
|
|
<li>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
|
|
a for ASP type deployment.</li>
|
|
|
|
<li>
|
|
Small businesses do not often have sophisticated investment
|
|
portfolios; they instead need support for additional
|
|
sophistication in such areas as:
|
|
|
|
<ul>
|
|
<li>Customer and Vendor Lists; Invoicing</li>
|
|
|
|
<li>Payroll (Batch processed and individual)</li>
|
|
|
|
<li>Inventory Control & Asset Management</li>
|
|
<li>Amortization Schedules, Depreciation</li>
|
|
|
|
<li>Shipping and Receiving</li>
|
|
|
|
<li>Accounts Receivable, Accounts Payable (A/R, A/P)</li>
|
|
<li>Credit Card Processing</li>
|
|
|
|
</ul>
|
|
</li>
|
|
|
|
<li>Support for calculations associated with accrual
|
|
accounting.</li>
|
|
|
|
<li>Ambitions for the future might include interfaces to
|
|
online shopping carts, credit card clearing interfaces, and
|
|
ERP systems.</li>
|
|
</ul>
|
|
|
|
<h3>Reconciling Those Needs</h3>
|
|
|
|
<p>A seemingly contradictory factor is that the kinds of
|
|
sophistication that are required vary considerably.
|
|
Consider:</p>
|
|
|
|
<ul>
|
|
<li>A home user does not generally require most of the
|
|
sophistication of accrual accounting that is
|
|
required by business enterprises. Thus, home users don't need
|
|
<em>much</em> of the sophistication of an Accounts Receivable
|
|
or Payable system, or the <em>bizarre</em> depreciation
|
|
policies that crop up in Asset Management systems.<br>
|
|
<br>
|
|
</li>
|
|
|
|
<li>
|
|
On the other hand, home users are in increasing need of
|
|
surprisingly sophisticated financial tools for managing
|
|
stock portfolios, including:
|
|
|
|
<ul>
|
|
<li>Mutual funds</li>
|
|
|
|
<li>Retirement savings plans, with such identifiers as
|
|
401(k), IRA, Roth IRA, RRSP, or Insurance Annuities</li>
|
|
|
|
<li>Corporate stock purchase plans</li>
|
|
|
|
<li>Corporate option plans</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
Another set of contradictory requirements has to do with the
|
|
back-end, and interfacing to other systems:
|
|
|
|
<ul>
|
|
<li>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).</li>
|
|
|
|
<li>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.</li>
|
|
</ul>
|
|
|
|
<p>It may be that these will require <em>completely</em>
|
|
different systems, and that GnuCash cannot be "all things to
|
|
all people." This remains to be seen.</p>
|
|
<hr>
|
|
<!--===================================================-->
|
|
|
|
<a name="size">
|
|
<h1>Sizings</h1>
|
|
</a>
|
|
This section attempts to guess how hard it would be to
|
|
implement certain features.
|
|
|
|
<h2>Personal Financial Application</h2>
|
|
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.
|
|
|
|
<p>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.</p>
|
|
|
|
<ul>
|
|
<li><b>Done</b> The work item is essentially completed</li>
|
|
<li><b>Small</b> 0 to 4 pm</li>
|
|
|
|
<li><b>Medium</b> 3 to 12 pm</li>
|
|
|
|
<li><b>Large</b> More than 12 pm</li>
|
|
</ul>
|
|
|
|
<table border="1" summary= "Personal Finance Functionality Requirements">
|
|
<tr>
|
|
<th>Feature</th>
|
|
<th>Sizing</th>
|
|
<th>Responsible</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#i18n">Internationalization</a></td>
|
|
|
|
<td>Done</td>
|
|
<td>-</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#reports">Reports</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>Stimming/Gribble</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#graphs">Graphs</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>Guppi/Gribble</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#query">Transaction Query</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Linas/LewisMoss</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#ledger">Simplified Ledger</a></td>
|
|
|
|
<td>Done</td>
|
|
<td>-</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#glitz">Themes, Icons, Glitz</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Various</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#misc">Miscellaneous Small Tasks</a></td>
|
|
|
|
<td>Done</td>
|
|
<td>Various</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#alerts">Alerts, Recurring & Scheduled Transactions</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#budget">Budgeting</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>Dave</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#classes">Classes/'Action' Field</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#book">Books, Accounting Periods</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Linas</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#check">Check Printing</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Grib</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#wizards">Wizards</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Dave, Bill-qif</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#arrangements">Arrangements</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#userpref">User Preferences/Session Mgmt.</a></td>
|
|
|
|
<td>Done</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#quickim">Quicken(TM) QIF Import</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Gribble</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#iifim">IIF Import</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#quickex">IIF Export</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Grib</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#currency">Multiple Currencies</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>Rethink Requirements-Linas</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#architecture">Architecture Review</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>RLB, Dave</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#testing">Automated Test Suite</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#quote">Stock Quotes, Price Quotes</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#install">Install</a></td>
|
|
|
|
<td>Small ?</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#double">Forced Double Entry</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#401K">401K etc.</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#searchdocs">Searchable Documentation</a></td>
|
|
|
|
<td>Done</td>
|
|
<td>grib</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#reconcile">Reconcile Auditing</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#note">Annotate with Investment News</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#loan">Loan and Mortgage Calculators</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Dave</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#overdraft">Overdraft Alerts</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#tech">Technical Stock Analysis</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#sink">Depreciation, Sinking Funds</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#ofx">OFX, Online Banking, Trading,
|
|
Bill-pay</a></td>
|
|
|
|
<td>Large</td>
|
|
<td>Dave</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#tab">Tab-delimited ASCII export</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#tax">Tax Preparation</a></td>
|
|
|
|
<td>Large</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#palm">Sync with Palm Pilot
|
|
organizers</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#emerg">Emergency Records Organizer</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2>Small Business Features</h2>
|
|
Features that small/medium businesses expect.
|
|
|
|
<table border="1" summary=
|
|
"Business Functionality Requirements">
|
|
<tr>
|
|
<th>Feature</th>
|
|
|
|
<th>Sizing</th>
|
|
<th>Responsible</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#engine">Enriched Engine, Financial
|
|
Objects</a></td>
|
|
|
|
<td>Large</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#sql">SQL I/O</a></td>
|
|
|
|
<td>Done</td>
|
|
<td>Linas</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#multiuser">Multi-User Support</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>Linas</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#addressbook">Address Book</a></td>
|
|
|
|
<td>Small</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#arap">A/R, A/P Accounts Payable,
|
|
Receivable</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#payroll">Payroll</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#invoice">Invoicing</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#estimate">Job Costing</a></td>
|
|
|
|
<td>Medium</td>
|
|
<td>?</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><a href="#expense">Expense Accounts</a></td>
|
|
|
|
<td>Large</td>
|
|
<td>?</td>
|
|
</tr>
|
|
</table>
|
|
<hr>
|
|
<!--===================================================-->
|
|
|
|
<a name="feats">
|
|
<h1>Features and Functions</h1>
|
|
</a>
|
|
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.
|
|
|
|
<dl>
|
|
|
|
<dt><a name="i18n"><b>Internationalization</b></a></dt>
|
|
|
|
<dd>
|
|
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.
|
|
|
|
<p><b>Current status:</b>
|
|
Essentially Done (?)
|
|
<ul>
|
|
<li>All GUI messages currently use GNU <tt>gettext()</tt>
|
|
for the message catalogs. Translations exist for English,
|
|
British, French, Swedish, German, Japanese.</li>
|
|
|
|
<li>Help pages available only in English and French.</li>
|
|
|
|
<li>Monetary and string handling done through glibc. The
|
|
latest glibc (2.2.3) is needed to get the correct
|
|
functions.</li>
|
|
|
|
<li>Yannick Le Ny <y-le-ny@ifrance.com> traduction
|
|
en francais</li>
|
|
|
|
<li>Most GUI input elements use the gtk text widget, and
|
|
thus use the XIM input method in Asian locales. This
|
|
allows <i>e.g.</i> Kanji, Katakana support. However, the
|
|
register does <em>not</em> use XIM, and thus doesn't
|
|
currently support the Asian languages. This needs
|
|
fixing. (This may be done already??)</li>
|
|
</ul>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="reports"><b>Reports</b></a></dt>
|
|
|
|
<dd>
|
|
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.
|
|
|
|
<p>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.
|
|
The GUI should remember what reports were run last time, and
|
|
these should be re-run/redisplayed whenever the report generator
|
|
is used.
|
|
</p>
|
|
|
|
<p>One difficult aspect of reporting is designing a
|
|
configurable interface, so that people can build custom
|
|
reports. The <a href="xacc-reports.html#NEWREP">New
|
|
Reporting Infrastructure</a> is seeking to build this up
|
|
using Guile. Note there are several flavours of customization:
|
|
<ul>
|
|
<li>Allow user to specify a custom logo (e.g. company
|
|
logo/address) on every page
|
|
(generically, having a header and footer for every page).
|
|
<li>Allowing user to modify report title/subtitle on the fly
|
|
(and possibly add notes at the top or bottom of the report,
|
|
e.g. to explain line items).
|
|
<li>Allow user to use the <a href="#query">transaction query</a>
|
|
interface to pick the set of transactions that will make up
|
|
the report.
|
|
<li>Memorize the report that was asked for, give that report
|
|
a name, and in the future, allow that same exact report
|
|
to be re-run. Allow user to edit this report properties
|
|
at a later date. Note that the basic idea is similar to
|
|
that of <a href="#query">memorized queries, discussed below.</a>
|
|
</ul>
|
|
Note that the customization info should be stored in a
|
|
<a href="#arrangements">Arrangements File (see below)</a>.
|
|
</p>
|
|
|
|
<p>Generated reports should be exportable to other gnome
|
|
systems (probably using bonobo).
|
|
Reports should also be exportable to
|
|
the Gnumeric spreadsheet (probably by writing out gnumeric
|
|
file format). Export of CSV (comma separated values) and
|
|
tab-delimited formats (for other spreadsheet import) would
|
|
be good. Tables & etc. should be exportable to AbiWord,
|
|
StarOffice, other word processors. (formats: docbook sgml?
|
|
would then make convert to richtext, TeX easy.)
|
|
Export should be as wysiwyg as possible.
|
|
</p>
|
|
|
|
<p>Must be possible to e-mail reports (for example,
|
|
invoices) to users. Suggest an evolution addressbok
|
|
/mailer bonobo plugin.
|
|
</p>
|
|
|
|
<p>
|
|
Relationship to budgeting not clear ...
|
|
</p>
|
|
|
|
<p>Stock portfolio tools should include a Cost Averaging
|
|
report, Market Index report, Stock Option values,
|
|
Estimation of capital gains tax liabilities.</p>
|
|
|
|
<p>Reports should be printable to printer (postscript/
|
|
Adobe Acrobat).
|
|
|
|
<p>
|
|
<b>Status:</b>
|
|
|
|
<ul>
|
|
<li>A general reporting infrastructure was implemented in
|
|
Perl, in the form of html-embedded perl (ePerl). However,
|
|
this reporting mechanism was abandoned in part because
|
|
ongoing build and install problems related to ePerl and
|
|
swig. Also, since ePerl didn't participate in the
|
|
interpreter even loop, the report generator had to run
|
|
as a separate process, reading data via pipes. This was
|
|
uglier than some folks liked.</li>
|
|
|
|
<li>A general reporting infrastructure has been <a href=
|
|
"xacc-reports.html#NEWREP">implemented in Scheme</a>.
|
|
Currently, there are a variety of reports for Profit/Loss,
|
|
Balance Sheet, and portfolio valuation; none are
|
|
particularly sophisticated.</li>
|
|
|
|
<li>Done: Reports are displayed with the gtk-html widget.
|
|
This widget provides postscript printing and Acrobat
|
|
output.
|
|
</li>
|
|
|
|
<li>There is currently no way (no longer any way??) to
|
|
generate reports from the command line ...</li>
|
|
|
|
<li>While many reports have been implemented, there is
|
|
no master list of what we should have. We should have ....
|
|
</li>
|
|
|
|
<li>The following technologies were rejected/unused mostly
|
|
because they were too complex, didn't hang together technologies:
|
|
<a href= "http://www.oasis-open.org/cover/">SGML</a> and <a href=
|
|
"http://www.oasis-open.org/cover/xml.html">Extensible
|
|
Markup Language - XML.</a> In the long run, these are
|
|
preferable to HTML, since <a href=
|
|
"http://www.jclark.com/dsssl/">DSSSL</a> tools such as <a
|
|
href="http://www.jclark.com/jade/">Jade (James DSSSL
|
|
Engine)</a> can be used to convert to RTF, Postscript, etc.
|
|
Add to this the consideration that XML is the basis for the
|
|
<a href="http://www.w3.org/DOM/">Document Object Model</a>,
|
|
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.
|
|
</li>
|
|
|
|
</ul>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="graphs"><b>Graphs</b></a></dt>
|
|
|
|
<dd>
|
|
<p>Provide support for graphs, charts, etc., such as:
|
|
Asset allocation pie chart, portfolio value vs. cost,
|
|
ROI. Graphs should be printable to printer.
|
|
Graph generation should be fully integrated with reporting,
|
|
both for data collection via queries, and for displayed
|
|
output.
|
|
</p>
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Different graphing packages were evaluated,
|
|
<a href="http://www.gnome.org/guppi/">GUPPI</a>.
|
|
Guppi was chosen. Considered & rejected were
|
|
plotutils, gnumeric graphing code (Miguel says
|
|
they'll replace gnumeric code with guppi.)
|
|
Miguel's/Gnumeric requirements were:
|
|
interactive plot editing -- each segment attributes
|
|
totally settable/controllable -- drag/move callbacks
|
|
when segments are click-dragged.
|
|
</li>
|
|
<li>Basic pie charts and bar charts are used in GnuCash
|
|
reports. There are problems: dates along the bottom
|
|
of a bar-chart are not well-spaced/autoscaled.
|
|
The over look is a bit klunky.
|
|
</ul>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="query"><b>Transaction Query</b></a></dt>
|
|
|
|
<dd>
|
|
Allow user to build (complex) queries to locate a
|
|
set of transactions that match some criteria: e.g.
|
|
a date range, or a matching payee, description, amount,
|
|
etc. Once a user has created a complex query, it
|
|
must be possible to memorize it (i.e. give it a name,
|
|
and store it for future reuse).
|
|
|
|
<p>
|
|
<b>Status:</b></p>
|
|
<ul>
|
|
<li>The query engine has been implemented (as of 1.4.0,
|
|
grib)
|
|
</li>
|
|
<li>The GUI for creating queries has been implemented
|
|
(as of 1.4.0, grib)
|
|
</li>
|
|
<li>The queries are handled by the Postgres SQL backend.
|
|
(as of 1.6.0, linas)
|
|
</li>
|
|
<li>Queries can be turned into XML and back, for file
|
|
storage or network transmission. This used to work
|
|
for XML version 1 but was broken in version 2.
|
|
</li>
|
|
<li>The ability to memorize queries has <b>not</b>
|
|
been implemented and awaits further action (needed
|
|
for reports, above).
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt><a name="ledger"><b>Simplified Ledger</b></a></dt>
|
|
|
|
<dd>
|
|
Ledger should look clean, work easily.
|
|
|
|
<p>
|
|
<b>Status:</b></p>
|
|
Essentially done.
|
|
<ul>
|
|
<li>Multi-line ledger confusion fixed by using correct
|
|
left-right journal display style.
|
|
Fixed in 1.6.0, Peticolas, Champaigne.
|
|
</li>
|
|
<li>
|
|
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.
|
|
Layout problems fixed in 1.6.0.
|
|
</li>
|
|
<li>
|
|
How to most simply allow the user to enter loads and fees?
|
|
Through multi-line transactions. Seems to work well in
|
|
1.6.0.
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt><a name="glitz"><b>Themes, Icons, Glitz</b></a></dt>
|
|
|
|
<dd>
|
|
A variety of finer touches need work:
|
|
|
|
<ul>
|
|
<li>
|
|
<p><b>Hint-of-the-Day</b>. A collection of a some
|
|
50-100 hints-of-the-day: short (2-4 sentence)
|
|
hints/tips on how to use gnucash. Every time the user
|
|
starts gnucash, an new hint shows up ...
|
|
<b>Status:</b> Hint infrastructure complete (RGMerkel,
|
|
version 1.4.0). Need to add
|
|
hints (only a dozen are currently available).
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Themes</b>. Some theme testing required. The
|
|
effect of themes on the register window needs to be
|
|
reviewed. Some themes look flaky in the main account
|
|
window, might be a gtk bug ???</p>
|
|
</li>
|
|
|
|
|
|
<li>
|
|
<p><b>Household Assets/House Inventory</b>
|
|
Add wizard to walk user through a set of questions
|
|
about household inventory & help user value them.
|
|
(do you own a house? appraised value? mortgage?
|
|
do you own jewelry? appraised value? etc.)
|
|
In particular, show how appreciation
|
|
and depreciation should be treated.
|
|
See the section <a href="#arrangments">Arrangements</a> for
|
|
a discussion of the customization issues.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>More account types</b> Introduce more
|
|
'fundamental' account types: (amortized) Loan,
|
|
Mortgage, ESOP, House, Line of Credit.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Register View</b> Allow user to view only
|
|
non-reconciled transactions ...</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Configurable main-window Status Bar</b> Bottom of
|
|
main window currently shows total asset, and total
|
|
income-expense (profits). Make this configurable, so
|
|
that user can show arbitrary sums of arbitrary
|
|
accounts.
|
|
This is mostly solved by having the MDI interface
|
|
have reports, and the use of multi-paning. But the
|
|
default display for gnucash should be changed to
|
|
show a very small (1-4 line) networth and P&L report,
|
|
and maybe a cash-flow report.
|
|
See the section <a href="#arrangements">Arrangements</a> for
|
|
a discussion of the customization issues.
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Dockable Registers/ aka "Browser Mode"</b>.
|
|
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. Possiblity for doing this exists with MDI.
|
|
Maybe we shouldn't bother doing this ?? </p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Context sensitive help</b>. When users
|
|
create new accounts, need to suggest stuff if the user
|
|
typed something unexpected ... (<em>e.g.</em>
|
|
non-alphanumeric input) ...</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Folder Tabs</b> 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. This is maybe a bs. request that shoudn't
|
|
be implemented.</p>
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
The following have been completed, but possibly not fully
|
|
documented:
|
|
<ul>
|
|
<li>
|
|
<p><b>Pop-up Calendar</b> All date fields should pop up
|
|
a calendar widget; selected date should get entered in
|
|
field. (peticolas, version 1.4 ??)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Pop-up Calculator</b> All price/amount fields
|
|
should pop up a calculator widget; output of calculator
|
|
gets entered in field. Instead of a popup calculator,
|
|
this was implemented by allowing all fields to take
|
|
algebraic expressions (plus, minus, times, divide).
|
|
(rlb ?? version 1.6.0)
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Button Bar</b> A user-configurable button-bar.
|
|
Solved in version 1.6.0 with tabs, not buttons, via
|
|
gnome MDI (gribble, version 1.6.0)
|
|
See also the section <a href="#arrangements">Arrangements</a>
|
|
for a discussion of the customization issues.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>Currency Exchange Table</b>
|
|
Keep a currency exchange-rate table. This is now
|
|
automatically handled via the 'price database'
|
|
(rlbrowning, version 1.6.0)
|
|
(the finance::quote perl module handles currency
|
|
exchange rate fetches)
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Currency Selection Pop-up</b> Currency field
|
|
should get replaced by menu of long-hand currency
|
|
names, three-letter ISO 4217 abbreviations, and symbols.
|
|
User should be able to hand-enter non-IS4217 currencies.
|
|
<b>Status:</b>
|
|
Done in 1.4.0
|
|
</p>
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Cut-n-paste</b> Cut-n-paste of whole transactions
|
|
in the register window... <b>Status:</b> Done. (by Dave
|
|
Peticolas, in 1.4.0)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Auto-completion</b> Quick-fill should also
|
|
auto-complete amount, memo fields.
|
|
<b>Status:</b>
|
|
Done in 1.4.0, Dave Peticolas
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Autoincrement</b> Check numbers should
|
|
auto-increment. Hit + key in check number field
|
|
(same keystroke as in quicken).
|
|
<b>Status:</b>
|
|
Done in 1.4.0, Dave Peticolas
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Navigation</b> Menu navigation using the keyboard
|
|
should be possible. Hit the Alt-F to get file menu,
|
|
hit Alt-FS to save.
|
|
|
|
Similarly, tab-key navigation in the register
|
|
should be possible.
|
|
<b>Status:</b>
|
|
Done (in 1.3.x ?, Dave & all, partly inherited via gtk
|
|
widget set.).
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Fly-Over Help</b> When the user pauses the mouse
|
|
over a button, "fly-over" pop-up help windows should
|
|
appear.
|
|
<b>Status:</b>
|
|
Done (in 1.3.x, inherited via gnome/gtk widget set).
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Grayed-out Form Help</b> Create grayed out
|
|
entries in the ledger, titled "Memo", "Description",
|
|
etc, helping users understand what should be typed into
|
|
each field. <b>Status:</b> Done (by Dave?), as of version
|
|
1.3.2(?)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><b>Key Bindings for Editing Text Fields</b>. The input fields
|
|
use the gtk text widget, which provides key bindings that
|
|
are similar to the Netscape/emacs key bindings.
|
|
This allows <em>e.g.</em> emacs-style ctrl-a,
|
|
ctrl-k to do the right thing.
|
|
<b>Status:</b>
|
|
Done (in 1.3.x, inherited via
|
|
gnome/gtk text widget).</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt><a name="misc"><b>Miscellaneous Small Projects</b></a></dt>
|
|
|
|
<dd>
|
|
A variety of small internal projects. All have been
|
|
completed as of 1.6.0
|
|
|
|
<ul>
|
|
<li>
|
|
<p><b>File Format</b>. Rework to use text file format. Will be
|
|
XML-based.
|
|
<b>Status:</b> RLB, LewisMoss. Version 1.6.0 Done.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>Reconcile Window</b>.
|
|
Auto-pay credit card when reconciling credit card
|
|
accounts (Done, Dave).
|
|
Auto-add bank fee when reconciling bank accounts.
|
|
(Not done?, Dave).
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>Print Register Window</b>. Output register window to
|
|
printer.
|
|
<b>Status:</b> Done: there is a register report which
|
|
is printable, there is botton on register. Done in 1.6.0
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b># of decimal places in prices (penny stock)</b>.
|
|
Part of the big numeric overhaul. Done, Gribble, others,
|
|
version 1.6.0
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>gtkhtml</b>. Move to gtkhtml from gtk-xmhtml.
|
|
Done in 1.5, Grib.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>print</b>. Print reports, etc. Done in 1.5, Grib.
|
|
This came 'for free' with gtkhtml.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>key-val pairs</b>. Add generic key-slot mechanism
|
|
into accounts, transactions, journal-entries. Done in
|
|
1.5.0, Grib.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p><b>guid in fileio</b>. No longer relevant with new file
|
|
format. Dave.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
|
|
<dt><a name="book"><b>Books, Accounting Periods</b></a></dt>
|
|
|
|
<dd>
|
|
Ability to close the book at end of the fiscal year. This
|
|
consists of several steps:
|
|
|
|
<ul>
|
|
<li>Permanently lock some transactions as non-editable.
|
|
This should be straight-forward by using the <tt>
|
|
reconciled</tt> field to indicate a <tt>locked</tt>
|
|
value, and not allowing the GUI to edit locked
|
|
records.
|
|
</li>
|
|
<li>Transfer the Income minus Expense for the book period
|
|
to an equity account, so that each new period starts with
|
|
zero income/expense balances.
|
|
</li>
|
|
<li>A mechanism to purge really old transactions from the
|
|
database.
|
|
</li>
|
|
<li>Extensions to querying and reporting infrastructure ...
|
|
The query changes might be painful ...
|
|
</li>
|
|
<li>
|
|
A user should be allowed to 'delete' an account <em>
|
|
only</em> 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 beginning and ending date (that
|
|
match the book period), and the file format needs to
|
|
support multiple charts ...
|
|
</li>
|
|
<li>Memorized Transactions ... Currently, transaction
|
|
auto-completion works by auto-completing 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.
|
|
</li>
|
|
</ul>
|
|
|
|
<p><b>Status:</b>
|
|
<ul>
|
|
<li>A mini-design Doc exists in <tt>src/engine/extensions.txt</tt>
|
|
A far more extensive, four-part proposal is ??? somewhere
|
|
in the mailing list archives (by Linas Vepstas, circa Feb-May
|
|
2001)
|
|
</li>
|
|
</ul>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="check"><b>Check Printing</b></a></dt>
|
|
|
|
<dd>
|
|
Create a check-printing ability. Include MICR (Magnetic Ink,
|
|
Computer Readable) check printing abilities.
|
|
<a href="http://dir.yahoo.com/business_and_economy/shopping_and_services/financial_services/banking/checks/">
|
|
Yahoo Check Printing</a> provides a list of vendors & printers.
|
|
<p>
|
|
Print vendor/client/payee address on the check (so that check
|
|
can be mailed with window envelopes.) This requires gnucash
|
|
to integrate with addressbook.
|
|
|
|
<p><b>Status:</b>
|
|
<ul>
|
|
<li>More check formats need to be supported.
|
|
<li>Done, except for address part, in version 1.4.0.
|
|
(gribble)
|
|
</li>
|
|
<li>Need a sample check/sample transaction to print out
|
|
so that user can test printer.
|
|
<li>MICR Fonts are available & brought to mailing list.
|
|
</ul>
|
|
</p>
|
|
|
|
</dd>
|
|
|
|
<dt><a name="wizards"><b>Wizards</b></a></dt>
|
|
|
|
<dd>
|
|
Create a set of wizards to walk through some of the more
|
|
complex tasks, such as new user setup, account creation,
|
|
QIF import, budget prep, obscure functional corners.
|
|
<p>
|
|
Wizards are great, but lets not thow away the denser GUI's.
|
|
For 8-hour-a-day users, the wizards can be irritating.
|
|
A single, dense screen can be more efficient and nicer.
|
|
So when adding wizards, don't dump GUI's !! (instead,
|
|
make them 'advanced' features).
|
|
|
|
<p>
|
|
<b>Status:</b>
|
|
The following not done:
|
|
<ul>
|
|
<li><b>Account Creation</b>
|
|
The account creation panel is somewhat busy. Maybe
|
|
could use a wizard?
|
|
</li>
|
|
<li><b>Budget Setup</b>
|
|
Setting up a budget.
|
|
</li>
|
|
<li><b>Obscure Corners</b>
|
|
Various obscure corners of the application may be
|
|
non-intuitive, and need wizard help. e.g. stock splits?
|
|
e.g. using foreign currency on a business trip?
|
|
</li>
|
|
</ul>
|
|
<b>Completed:</b>
|
|
<ul>
|
|
<li>
|
|
<b>New User Setup</b> 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. Profiles: home-owner vs. renter
|
|
non-for-profit (some non-profits are very very simple,
|
|
just a club). Done in version 1.6.0, C. Champagne,
|
|
J LewisMoss
|
|
</li>
|
|
<li><b>QIF Import</b>
|
|
QIF Import is just complicated enough that it needs
|
|
a wizard walk-through of the steps. Grib,
|
|
version 1.6.0, Done.
|
|
</li>
|
|
</ul>
|
|
<p></p>
|
|
|
|
|
|
<dt><a name="arrangements"><b>Arrangments</b></a></dt>
|
|
|
|
<dd>
|
|
An "application arrangement" is the defining look-n-feel of an application.
|
|
The idea is similar to, but not the same as 'skins'/'themes'. Its similar
|
|
to, but not the same as allowing a user to set 'preferences'. Its similar
|
|
to, but not the same as, allowing a user to generate customized financial
|
|
reports. In the context of GnuCash, a 'arrangement' should be a file
|
|
(that can be traded by users, uploaded and shared) that controls important
|
|
aspects of how the application is configured.
|
|
<p>
|
|
In particular, the GnuCash Arrangement should include the following:
|
|
<ul>
|
|
<li>A list of sample/initial accounts. These might be tailored for a
|
|
home user (groceries, gas, electric), an apartment dweller
|
|
(rent, laundry), or different kinds of business users.
|
|
Because these sample accounts appear in the Arrangement file,
|
|
it becomes easy to create & distribute customized arrangements.
|
|
<li>A list of pre-defined reports and graphs. The kind that you'd find
|
|
for a home user might be different than for a person managing a stock
|
|
portfolio, which is in turn different from what a business might need.
|
|
The Arrangement File should include install-specific customizations, such
|
|
as the report headers, footers, etc.
|
|
<li>Hint of the day. The types of 'hint of the day' would be different
|
|
for new users, than it would be for advanced users. Thus, different
|
|
arrangements would have different catalogues of 'hint of the day'.
|
|
<li>Menu Contents & Navigation. New users might be presented with a simple set
|
|
of menu contents. 'Power Users' might be presented with deep, nested
|
|
sets of menus, with oodles of features.
|
|
<li>Register Layout. The layout of the register might be customized for
|
|
different countries: e.g. in Germany, a different type of electronic
|
|
banking seems to require the display of account numbers in separate
|
|
columns in the register.
|
|
</ul>
|
|
A good arrangement infrastructure will not only allow gnucash to be configured
|
|
for different application domains, but also will allow users to fine-tune
|
|
thier own prefered arrangement. It can also simplify the code base:
|
|
instead of having two products, a home-user application, and a small-business
|
|
application, each with a different code base and #defines and what not, instead,
|
|
we have one code base, and different arrangments for each.
|
|
However, most importantly, the arrangments should be easy to share between users.
|
|
They should be such that users are encouraged to trade and use arrangments,
|
|
and to create new ones that suit thier needs.
|
|
</p>
|
|
<p>
|
|
The idea for arrangements was inspired by
|
|
Adam Curry's commentary on
|
|
<a href="http://adamcurry.editthispage.com/stories/storyReader$161">
|
|
radio formats and Napster</a>.
|
|
</p>
|
|
<p>
|
|
<b>Status:</b>
|
|
Not started. Individually, all these cusomizable things exist
|
|
here and there in gnucash, but they cannot be shared between
|
|
users: a gnucash user cannot mail her favorite 'arrangement'
|
|
to her freind.
|
|
</p>
|
|
|
|
|
|
<dt><a name="userpref"><b>User Preferences, Session Management</b></a></dt>
|
|
|
|
<dd>
|
|
A dialog system and file format for manipulating user
|
|
preferences. Preferences include things like default
|
|
currency, register layout and colors, etc.
|
|
|
|
<p>What are some of the competitive preference-handling
|
|
technologies? Lets get some URL's here ... Following the
|
|
Unix tradition, there is no global preferences registry.
|
|
Note that session management and preferences are related
|
|
things ... sort-of. Right now, we don't treat them as such
|
|
...</p>
|
|
|
|
<p><b>Status:</b></p>
|
|
Done, more or less, version 1.6.0.
|
|
|
|
<ul>
|
|
<li>Works real good; lots of preferences in the GUI.
|
|
Implemented in home-grown scheme. (version 1.4.0,
|
|
rlb)</li>
|
|
|
|
<li>These are saved in the '.gnucash/config.auto' file.
|
|
The current file format is raw scheme code, rather
|
|
delicate to tweak by hand ...</li>
|
|
|
|
<li>Session management mostly works, but doesn't use the
|
|
sawmill/gnome/X ICCCM system. GnuCash remembers MDI
|
|
based reports, restart reopens in same state. Sizes
|
|
and shapes and positions are remembered.
|
|
Done in version 1.6.0
|
|
</li>
|
|
|
|
<li>Independently of session management, the register
|
|
windows should remember how big they were last time they
|
|
were popped up, and they should pop up the same size, again.
|
|
The app should remember these sizes from invocation to
|
|
invocation. Done in version 1.6.0, but seems a bit buggy.
|
|
</li>
|
|
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="architecture"><b>Architecture Review</b></a></dt>
|
|
<dd>
|
|
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.
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Such "wiring together" will consist of a dispatch
|
|
infrastructure that will allow arbitrary menu entries to be
|
|
hooked to arbitrary modules. The configuration for menu
|
|
entries, and their associated callbacks, will be specified
|
|
in an extension-language configuration file. At the final
|
|
stages, it is <em>highly</em> desirable to be able to, in
|
|
some manner, import new modules <em>without</em> requiring
|
|
that the application itself be recompiled and relinked.</p>
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>
|
|
Scheme/Guile is the central extension language. Guile
|
|
interfaces auto-generated using g-wrap.
|
|
</li>
|
|
<li>
|
|
Optional interfaces to the data engine (for, e.g.
|
|
perl) can be generated using
|
|
<a href= "http://starship.skyport.net/crew/beazley/swig.html">
|
|
SWIG</a>.
|
|
</li>
|
|
<li>
|
|
Dave to collate & edit architecture documents.
|
|
RLB to provide diagrams.
|
|
</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="alerts"><b>Recurring Transactions, Calendar Alerts,
|
|
Scheduled Transactions</b></a></dt>
|
|
|
|
<dd>
|
|
(1)Add support for automatic, recurring transactions, <em>
|
|
e.g.</em> mortgage payments, fixed-interest bonds, regular
|
|
salary checks, regular gas/phone/electric bills, <em>
|
|
etc.</em>
|
|
|
|
<p>(2) Recurring bills, salary income, etc. are simpler to
|
|
handle, since they don't have interest rates, balloons,
|
|
etc. They do/will have multiple splits (<em>e.g.</em>
|
|
payroll gross, fica, futa, income taxes, payroll net).</p>
|
|
|
|
<p>(3)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 (!?)</p>
|
|
|
|
<p>(4)Loans & 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 balloon.
|
|
</p>
|
|
|
|
<p>(5)Provide a calendar-display of upcoming & past
|
|
scheduled payments. Clicking on a calendar day should raise
|
|
up editable list of transactions. Calendaring 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. Memo's should be
|
|
possible. Pop-ups should happen when dates get close.
|
|
Technology: best bet is the Ximian Evolution Calander
|
|
component.</p>
|
|
|
|
<p><b>Design Notes:</b> Most alerts & data storage
|
|
should be driven out of the engine. This will enable
|
|
multi-user, distributed use. <b>Note:</b> 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 calendar
|
|
events might be server-ified. (On the other hand, a good
|
|
calendar should be server-ified, and thus viewable by
|
|
secretaries, co-workers, etc.)</p>
|
|
|
|
<p>More complex financial instruments may need a
|
|
guile-based extension mechanism to compute values ....
|
|
simple interest/mortgage calculators should be done in C in
|
|
the engine ... (<em>e.g.</em> depreciation schedules ...
|
|
under us tax law, a variety of different schedules are
|
|
allowed ... )</p>
|
|
|
|
<p>May need interfaces to email for emailed alerts.</p>
|
|
|
|
<p>Plot forecast graphs based on scheduled income &
|
|
payments ... is this tied into budgeting ????</p>
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>Need to create design doc, need to implement engine
|
|
pieces, need to hunt down gnome-calendaring bonobo.</li>
|
|
<li>Preliminary work started.
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="budget"><b>Budgeting</b></a></dt>
|
|
|
|
<dd>
|
|
Ability to create a budget (<em>i.e.</em> - estimates of
|
|
future expenditures). Reconcile actual expenditures against
|
|
future expenditures. Create simple, step-by-step 'financial
|
|
plan' budgeting GUI's:
|
|
|
|
<ul>
|
|
<li>Home purchase planner</li>
|
|
|
|
<li>Retirement planner</li>
|
|
|
|
<li>College tuition planner</li>
|
|
|
|
<li>Debt reduction planner</li>
|
|
|
|
<li>Scrimp-n-Save planner</li>
|
|
|
|
<li>Special purchase planner (big ticket items)</li>
|
|
</ul>
|
|
Create a summary budget/track-record budget report that a
|
|
professional financial planner/advisor could use.
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Note that the utility of budgets is greatly enhanced by using
|
|
them with '<a href="#classes">classes</a>'.
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>A design doc has been submitted by Bob Drzyzgula.
|
|
Take a look at <tt>./src/budget.txt</tt> in the source
|
|
directory.</li>
|
|
|
|
<li>Bryan Larsen has begun work .. it's scheme based ...
|
|
Dave Peticolas has some GUI roughed out ...</li>
|
|
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="classes"><b>Classes</b></a></dt>
|
|
|
|
<dd>
|
|
Ability to mark certain journal entries as belonging to
|
|
a 'class', so that expenses (or income) can be categorized
|
|
in more than one way. For example, the expense of a trip
|
|
might include food, travel and lodging, and thus be spread over
|
|
three different expense accounts. None-the-less, we want all
|
|
of these entries to be marked as being in the same class.
|
|
(Alternate names: 'job costing' is the report that's generated,
|
|
'cost center', 'cost pool', 'pooling')
|
|
Note that classes can be particularly useful when used with
|
|
budgets: viz. I set aside $10K in the budget for some activity,
|
|
then deduct the actual costs. Note that it should be possible
|
|
to roll the remainder over to somehere else (!)
|
|
<p>
|
|
Confusion: isn't this what the 'action' field is supposed to do?
|
|
The 'action' field is under-utilized.
|
|
|
|
<p>
|
|
This requires the following:
|
|
<ul>
|
|
<li>Ability to report by class/action
|
|
<li>Ability to query by class/action.
|
|
</ul>
|
|
</p>
|
|
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="testing"><b>Automated Test Suite</b></a></dt>
|
|
|
|
<dd>
|
|
Build automated test suite, including:
|
|
<ul>
|
|
<li>File IO consistency check. Done, 1.6.0, LewisMoss
|
|
<li>Currency math correctness. Done ?? Grib.
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="quickim"><b>Quicken(TM) Import</b></a></dt>
|
|
|
|
<dd>
|
|
Ability to import Quicken QIF files. Both MSMoney and
|
|
Quicken use QIF files to export data. Need both wholsesale
|
|
data import, and incremental (staged) merge.
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>
|
|
Quicken import is implemented and mostly works.
|
|
(Bill Gribble, Done, in version 1.4.0)
|
|
</li>
|
|
<li>
|
|
Need a QIF Import wizard (there are several non-intuitive
|
|
steps that need to be performed during import.
|
|
A dialogue wizard seems like the best idea to carry
|
|
through this process. (grib, done in 1.6.0)
|
|
</li>
|
|
<li>
|
|
Work needs to be done for recurring transactions, etc.
|
|
</li>
|
|
<li>
|
|
QIF processing, as used for on-line banking, is <em>
|
|
in prototype form</em> (for 1.6.1 ??)
|
|
Note that since banks use QIF, the <em>correct</em>
|
|
way to updated 'cleared' reconcile state is through
|
|
QIF on-line import.
|
|
On one side, we have existing recorded transactions;
|
|
on the other, the latest bank statement, in QIF
|
|
format.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="iifim"><b>IIF Import</b></a></dt>
|
|
|
|
<dd>
|
|
Ability to import IIF (Intuiut Interchange Format, used by Quickbooks)
|
|
files, quickbooks, some upsacle accounting packages use this format.
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>
|
|
Sample files checked into sample directory.
|
|
No formal documentation known.
|
|
</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="quickex"><b>IIF Export</b></a></dt>
|
|
|
|
<dd>
|
|
Ability to export Intuit IIF files.
|
|
The IIF format is more rational than the QIF format,
|
|
and other 'real' accounting apps support IIF.
|
|
Several design alternatives are apparent:
|
|
|
|
<ul>
|
|
<li>
|
|
A special 'report' that writes out qif could be
|
|
created.
|
|
This would use the 'reports' infrastructure to
|
|
generate QIF's.
|
|
</li>
|
|
|
|
<li>It is fairly easy to traverse the data in the engine
|
|
to write out qif files. This is not hard. Just do it.
|
|
</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
|
|
<p><b>Status:</b> not started</p>
|
|
</dd>
|
|
|
|
<dt><a name="quote"><b>Stock Quotes, Price Quotes</b></a></dt>
|
|
|
|
<dd>
|
|
Add ability to obtain stock, mutual fund, and currency trading
|
|
data from news agencies, web pages.
|
|
Add ability to download historical prices as well.
|
|
(<em>e.g.</em> get 5-year history of mutual fund
|
|
performance vs. DJIA).
|
|
|
|
<p>Right now, stock prices are stored in a separate, simple pricedb.
|
|
</p>
|
|
|
|
<ul>
|
|
<li>Prices need to have several different status states.
|
|
One state is 'critical/audited', i.e. reviewed by a human,
|
|
and important for understanding a historical transaction.
|
|
Less mportant may simply be 'audited': i.e. reviewed by a
|
|
human, but not a critical price. Lowest level: 'live data'
|
|
something that was gotten off the net, may be wrong, may
|
|
be right, who knows, who cares.
|
|
</li>
|
|
|
|
<li>Add to this the idea that we should probably store other
|
|
'technical' stock data, such as share volume, high/low/close,
|
|
daily volatility, etc.
|
|
</li>
|
|
|
|
<li>Need access to historical quotes, for graphing charting
|
|
of historic portfolio perfformance.
|
|
</li>
|
|
</ul>
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="http://sourceforge.net/project/?group_id=4232">
|
|
Finance::Quote.pm</a> is now a separate development project at
|
|
SourceForge. Its a perl module.
|
|
It can obtain stock quotes from Yahoo
|
|
(NYSE), Yahoo-Europe, Fidelity Investments, T.Rowe Price,
|
|
TIAA-CREF, others. Also handles currency exchange rates.
|
|
</li>
|
|
|
|
<li>A scheme wrapper allows prices to be
|
|
fetched from GUI. Done, version 1.6.0, rlbrowning.</li>
|
|
|
|
<li>
|
|
Commandline-flag replaces script file <tt>gnc-prices</tt>
|
|
perl script). Suitable for use with cron jobs.
|
|
(version 1.6.0)
|
|
</li>
|
|
|
|
<li>A separate, historical-quote module can be found at the
|
|
<a href="http://sourceforge.net/project/?group_id=2403">QuoteHist</a>
|
|
sourceforge site. It might be a good idea to fold this
|
|
together with the Quote.pm module !?
|
|
</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="install"><b>Install</b></a></dt>
|
|
|
|
<dd>
|
|
Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux,
|
|
etc. Possibly use a 'configure'-like way of dealing with
|
|
install inconsistencies.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="currency"><b>Multiple Currencies</b></a></dt>
|
|
|
|
<dd>
|
|
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. Weird stuff is in weird columns.
|
|
</p>
|
|
<p>
|
|
A simplified way of dealing with one-shot currency
|
|
exchanges needs to be implemented, essentially just a
|
|
simple calculator pop-up. This might be handy for the
|
|
occasional business traveler or tourist with some minor
|
|
currency trades.
|
|
</p>
|
|
<p>
|
|
Implement the 'correct' way of handling this when user
|
|
is working in multiple currencies on a regular basis.
|
|
</p>
|
|
<p>
|
|
<a href="http://www.cloanto.com/specs/seriff.html">SERIFF</a>
|
|
Simple Exchange Rate Information File Format. Completely
|
|
*.ini-centric in layout and design, but otherwise seemingly
|
|
quite complete.
|
|
</p>
|
|
|
|
<p>
|
|
<b>Status:</b>
|
|
<ul>
|
|
<li>Need to rethink whether 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).
|
|
<li>New split architecture should store quantity and value, and
|
|
never the price. This will simplify currency movements
|
|
between accounts, without requiring/forcing the use of a
|
|
currency trading account. (this also solves problems with
|
|
rounding that occur when a price is explicitly specified.)
|
|
Grib & dave are working this for next release.
|
|
</ul>
|
|
</p>
|
|
|
|
</dd>
|
|
|
|
<dt><a name="double"><b>Forced Double-Entry</b></a></dt>
|
|
|
|
<dd>
|
|
The system supports double-entry: every transaction
|
|
indicates a pair of accounts: one is debited, and one is
|
|
credited.
|
|
|
|
<p>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 <em>can</em>
|
|
create dangling transactions, where only one account is
|
|
indicated.</p>
|
|
|
|
<p>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.)</p>
|
|
|
|
<p>It must be possible to enforce double entry, so that a
|
|
transaction cannot be completed until two accounts have
|
|
been specified.</p>
|
|
|
|
<p><b>Restricted Double</b> 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.</p>
|
|
|
|
<p><b>Current status:</b>
|
|
|
|
<ul>
|
|
<li>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.</li>
|
|
|
|
<li>Dec 1998 -- Scrubber functions implemented to crawl
|
|
through data, and find all unbalanced or orphaned
|
|
transactions.</li>
|
|
|
|
<li>May 2000 -- Default will be changed to double-entry
|
|
always. It will not be possible to disable this and move
|
|
to single-entry.</li>
|
|
</ul>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="401K"><b>401(k), Retirement Savings Plans</b></a></dt>
|
|
|
|
<dd>
|
|
401K, 403, IRA, Roth IRA, SEP, Keogh ...
|
|
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??)
|
|
<p>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="note"><b>Annotate with News Stories</b></a></dt>
|
|
|
|
<dd>
|
|
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.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="searchdocs"><b>Searchable Documentation</b></a></dt>
|
|
|
|
<dd>Need to add a 'meta keyword' tag to the documentation
|
|
pages, this will help the search engine (<em>e.g.</em>
|
|
<a href="http://www.htdig.org/">htdig</a>) better categorize the
|
|
help. <a href="http://www.senga.org/mifluz/html/">Mifluz</a>
|
|
might be more embeddable ... I am told that htdig-API is in
|
|
good solid condition for this, but undocumented.
|
|
<p>
|
|
|
|
<b>Status:</b>
|
|
Done, using a simple keyword search, homegrown. The only
|
|
problem is it doesn't support compound expressions.
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="reconcile"><b>Reconcile Auditing</b></a></dt>
|
|
|
|
<dd>When a collection of transactions get processed through the
|
|
reconcile dialogue, user needs to be able to add a note to this,
|
|
i.e. this set of JE's will be treated as a group. The note
|
|
(and date) can be later called up as a part of an audit
|
|
procedure. The act of reconciliation is treated as a
|
|
historical event that needs to be logged.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="loan"><b>Loan and Mortgage Calculators</b></a></dt>
|
|
|
|
<dd>
|
|
Provide a variety of simple GUI utilities to allow user to
|
|
calculate the future value of loans, mortgage payments,
|
|
interest payments, etc.
|
|
|
|
<p> Consider the following dialogue layout:</p>
|
|
<pre>
|
|
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/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/yy
|
|
</pre>
|
|
Note that in the above, not all fields are independent:
|
|
some can be calculated from others. The <tt>other
|
|
payment</tt> should bring up a mini-register, allowing user
|
|
to add any number of splits.<br>
|
|
<br>
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>There is an implementation of the calculation routines by
|
|
Terry Boldt in the development branch. There is an initial
|
|
GUI implementation of the calculator by Dave.
|
|
</li>
|
|
</ul>
|
|
<br>
|
|
<br>
|
|
</dd>
|
|
|
|
<dt><a name="overdraft"><b>Overdraft Alerts</b></a></dt>
|
|
|
|
<dd>
|
|
Overdraft alerts are pop-ups 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
|
|
implemented for price highs & lows. Note that these
|
|
alerts do <em>not</em> require any sort of calendaring or
|
|
recurring transaction support.
|
|
|
|
<p>Design requirements: implement multiple (not just two)
|
|
alerts for any account type. Alert should consist of</p>
|
|
|
|
<ul>
|
|
<li>value point or price point</li>
|
|
|
|
<li>movement direction</li>
|
|
|
|
<li>'is active' boolean flag (<em>i.e.</em> Should be
|
|
possible to 'turn off alert' without deleting it)</li>
|
|
|
|
<li>memo text</li>
|
|
</ul>
|
|
|
|
<p><b>Status:</b>
|
|
<ul>
|
|
<li>Not Started.</li>
|
|
</ul>
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="tech"><b>Technical Stock Analysis</b></a></dt>
|
|
|
|
<dd>Provide technical stock analysis graphs, <em>e.g.</em>
|
|
volume, 90 moving avg, beta, etc. See gstalker for example of
|
|
how to do it ...
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="sink"><b>Asset Depreciation, Sinking Funds,
|
|
Amortization Schedules</b></a></dt>
|
|
|
|
<dd>Need to
|
|
support different depreciation schedules (see IRS books for
|
|
that). Asset depreciation is complex; there are many
|
|
different depreciation schedules, and these vary from
|
|
country to country, and change when new tax laws are
|
|
implemented. It might be hard for free software to provide
|
|
a no-cost subscription to updated depreciation modules.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="ofx"><b>OFX support</b></a></dt>
|
|
|
|
<dd>
|
|
Provide the SGML DTD parsers to handle the OFX reports that
|
|
many banking institutions are providing, or will soon be
|
|
providing, to retail customers. See below for OFX
|
|
references.
|
|
|
|
<p>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 <a
|
|
href="http://www.ofx.net">OFX Home Page</a> for
|
|
details.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<ul>
|
|
<li>The parser is fragile because minor DTD
|
|
non-compliances are hard to parse, handle and recover
|
|
from.</li>
|
|
|
|
<li>The parser is huge because the DTD results in
|
|
hundreds of (C++) objects being generated.</li>
|
|
</ul>
|
|
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.
|
|
|
|
<p>Run-time parsing may be slower, but on the OFX client
|
|
side, this should not be a bottleneck.</p>
|
|
|
|
<p><b>Status:</b></p>
|
|
|
|
<ul>
|
|
<li>A compile-time parser was developed and
|
|
abandoned.</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
</dd>
|
|
|
|
<dt><b>Other on-line support</b></dt>
|
|
|
|
<dd>
|
|
<pre>
|
|
>> 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 transfers
|
|
>> 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.
|
|
</pre>
|
|
</dd>
|
|
|
|
<dt><a name="tab"><b>Tab-delimited ASCII file format</b></a></dt>
|
|
|
|
<dd>
|
|
People <em>like</em> 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 <tt>
|
|
printf()</tt>s.
|
|
|
|
<p>The tab-delimited format should be compatible with that
|
|
of <tt>/rdb</tt>, aka <a href=
|
|
"ftp://ftp.rand.org/pub/RDB-hobbs/">RAND/Hobbs /rdb</a> or
|
|
<a href=
|
|
"ftp://ftp.linux.it/pub/database/RDB/nosql-0.8.tar.gz">
|
|
NoSQL.</a> (NoSQL is available as part of the <a href=
|
|
"http://www.debian.org">Debian GNU/Linux</a> distribution,
|
|
for instance.)</p>
|
|
|
|
<p>The <tt>/rdb</tt> format is thus:</p>
|
|
<pre>
|
|
field-name tab fieldname tab fieldname \n
|
|
------------------------------------------ \n
|
|
value tab value tab value \n
|
|
value tab value tab value \n
|
|
etc ...
|
|
</pre>
|
|
|
|
<p>It is a very simple, very basic flat table format. The
|
|
use of <tt>/rdb</tt> with GnuCash should try to match with
|
|
SQL schemas as much as possible in order to minimize I/O
|
|
complexity and incompatibility.</p>
|
|
</dd>
|
|
|
|
<dt><a name="tax"><b>Tax Preparation</b></a></dt>
|
|
|
|
<dd>
|
|
Gotta prepare those taxes.
|
|
W-2, W-3, 941, 940 Processing.
|
|
|
|
<ul>
|
|
<li>
|
|
TurboTax --
|
|
categorize items according to different tax
|
|
schedules
|
|
</li>
|
|
|
|
<li>VAT -- Value Added Tax. Varies from country to country.
|
|
</li>
|
|
|
|
<li>Estimate income taxes.
|
|
Estimate itemized deductions, find potential
|
|
deductions, categorize them</li>
|
|
</ul>
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="palm"><b>Sync with Palm Pilot organizers</b></a></dt>
|
|
|
|
<dd>There are Quicken-workalikes that run on the
|
|
PalmComputing platform; it would be good to inter-operate
|
|
with this. See
|
|
<a href="ftp://ryeham.ee.ryerson.ca/pub/PalmOS/">PalmLink</a>
|
|
and <a href="http://www.orbits.com/Palm/">Palm & Linux</a>.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="emerg"><b>Emergency Records Organizer</b></a></dt>
|
|
|
|
<dd>Put together a single-page report showing critical info
|
|
about accounts, etc.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="logging"><b>Logging, Crash Recovery</b></a></dt>
|
|
|
|
<dd>
|
|
Logging serves two purposes: (1) return the system to the state
|
|
it was in on some earlier date. (2) recover from a crash.
|
|
Probably need two distinct mechanisms to support this. The
|
|
mechanisms are (A) backup copies. These can be compactly handled
|
|
via RCS (actually, deltax) for storage. (B) Logging. Write
|
|
out to disk each & every change made.
|
|
</p>
|
|
<p><b>Status:</b>
|
|
<ul>
|
|
<li>Crude transaction logging/auditing in place; should
|
|
be suitable for error/crash recovery but has not been
|
|
"tried by fire."</li>
|
|
|
|
<li>Backup files automatically created and
|
|
time-stamped.</li>
|
|
</ul>
|
|
</p>
|
|
|
|
|
|
</dd>
|
|
|
|
<dt><a name="engine"><b>Enriched Engine, Financial Objects</b></a></dt>
|
|
|
|
<dd>
|
|
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.
|
|
|
|
<p>The current engine is rather simple: it provides support
|
|
for accounts, account hierarchies and transactions
|
|
consisting of multiple entries.</p>
|
|
|
|
<p>Many of the features described elsewhere will require
|
|
that the engine have a far richer, more sophisticated data
|
|
model, including such things as:</p>
|
|
|
|
<ul>
|
|
<li>Linking to "Address Info" ( <em>e.g.</em> names,
|
|
addresses)</li>
|
|
|
|
<li>Transaction identifiers</li>
|
|
|
|
<li>Part numbers, SKU IDs</li>
|
|
|
|
<li>Interest rates</li>
|
|
|
|
<li>Budget policy</li>
|
|
</ul>
|
|
|
|
<p>Note: it makes no sense at this point to make the engine
|
|
API much richer than what the GUI can currently
|
|
support.</p>
|
|
|
|
<ul>
|
|
<li><b>Locks</b> When splits are implemented, and the
|
|
parent transaction has been marked as cleared/reconciled,
|
|
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).</li>
|
|
</ul>
|
|
|
|
<p><b>Current Status:</b></p>
|
|
|
|
<ul>
|
|
<li>
|
|
<tt>BeginEdit()/RollbackEdit()/CommitEdit()</tt>
|
|
routines mostly in place,
|
|
these "Transaction processing constructs" should
|
|
simplify creation of an SQL back end, or some other
|
|
more sophisticated transactional server.
|
|
</li>
|
|
|
|
<li>Multiple currency support is present but still pretty
|
|
"raw."</li>
|
|
|
|
<li>Query engine has been broadly extended (Bill Gribble).
|
|
Documentation for Query Engine??</li>
|
|
|
|
</ul>
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="sql"><b>SQL I/O</b></a></dt>
|
|
|
|
<dd>
|
|
A module is necessary to allow data to be fetched from an
|
|
SQL database, and for that database to be updated.
|
|
There has been <em>much</em> discussion about this on
|
|
mailing lists both for GnuCash and
|
|
<a href="http://www.menet.umn.edu/~curt/cbb/">CBB.</a>
|
|
Major points have included:
|
|
|
|
<br>
|
|
<br>
|
|
<ul>
|
|
<li>The use of a database allows only that data which
|
|
is actually <em>in use</em> to be loaded into
|
|
memory. This permits managing larger sets of
|
|
transactions more efficiently.
|
|
</li>
|
|
<br><br>
|
|
|
|
<li>It also allows data to be pushed out to the DBMS
|
|
<em>immediately after entry,</em> rather than waiting
|
|
for the user to "save the books."
|
|
</li>
|
|
<br><br>
|
|
|
|
<li>Using a client/server SQL database might make it easier
|
|
to turn GnuCash into a multi-user system.
|
|
</li>
|
|
<br><br>
|
|
|
|
<li>By using a well-known DBMS, outside programs are
|
|
provided a well-defined way of getting at, and
|
|
perhaps even modifying, GnuCash data.
|
|
(Actually, this is not true: GnuCash already provides
|
|
a uniform, well-documented, preferred data access API.
|
|
As long as this
|
|
API is used, there is some guarantee that data is stored
|
|
in a self-consistent fashion. Not using the GnuCash
|
|
programming interfaces risks corrupting the data.
|
|
Direct access to the data is dangerous and discouraged.
|
|
Furthermore, The API is guaranteed to be backwards
|
|
compatible with a variety of data storage formats.
|
|
Due to enhancements, the actual form of the data stored in
|
|
a flat file, or in the SQL database, may change without
|
|
warning.)
|
|
</li>
|
|
<br><br>
|
|
<li>
|
|
Those SQL databases available on Linux tend to involve
|
|
considerable <em>administrative</em> 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 <em>not</em> acceptable to require this of
|
|
naive users that may find "simple" things like
|
|
<pre>
|
|
% su -
|
|
Password:
|
|
# cd /tmp
|
|
# rpm -i gnucash-4.1.3.i386.rpm
|
|
# exit
|
|
</pre>
|
|
to be challenging.
|
|
</li>
|
|
<br><br>
|
|
|
|
<li>
|
|
It might be useful to use an embedded database engine
|
|
like unto <a href="http://www.sleepycat.com/">Sleepycat
|
|
DB</a>,
|
|
<a href="ftp://koobera.math/uic.edu/www.cdb.html">cdb</a>,
|
|
or something like
|
|
<a href="http://www.opengroup.org/public/prods/dmm4.htm">
|
|
ISAM</a> (Note CQL++ supports ISAM access methods), or
|
|
even an embedded SQL engine such as
|
|
<a href="http://www.ispras.ru/~knizhnik/gigabase.html">
|
|
GigaBASE</a>.
|
|
The reasons to do so include ... ???
|
|
</li>
|
|
|
|
<br><br>
|
|
<li>
|
|
GnuCash presently uses a document-oriented model, where
|
|
the <em>entire</em> 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 <tt>Begin()/End()</tt> constructs
|
|
in the engine.
|
|
|
|
<p>
|
|
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 <em>not</em>
|
|
require locks to be held for extended periods of
|
|
time!
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
The SQL engine chosen should be fully transactional,
|
|
passing the 'ACID' test (Atomicity, Consistency,
|
|
Isolation, Durability).
|
|
Note that
|
|
<a href="http://openacs.org/why-not-mysql.html">MySQL
|
|
does not satisfy the 'ACID' criteria</a>.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
<b>Status:</b>
|
|
Done, more or less, gnucash version 1.6.0, Linas Vepstas.
|
|
Theres still a laundry list of things that need to be
|
|
cleaned up, see the README file in src/engine/sql/README.
|
|
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="multiuser"><b>Multi-user Support</b></a></dt>
|
|
|
|
<dd>
|
|
Multi-user support should be added with either an SQL
|
|
backend to the engine, and/or through CORBA interfaces to
|
|
the engine.
|
|
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:
|
|
<br><br>
|
|
|
|
<ul>
|
|
<li>transaction-oriented queuing of updates</li>
|
|
|
|
<li>event subscription channel for updates</li>
|
|
|
|
<li>user authentication</li>
|
|
|
|
<li>user authorization</li>
|
|
|
|
<li>non-repudiability (needed only for peer-to-peer??)</li>
|
|
|
|
<li>encryption of network connections</li>
|
|
</ul>
|
|
<p>
|
|
<b>Status:</b> Partly done. (gnucash 1.6.0, Linas)
|
|
The postgres backend fully
|
|
supports multiple simltaneous users. This includes
|
|
events for automatic updates of all GUI displays.
|
|
However, the GUI support is rough, no GUI dialog
|
|
for user/password.
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="addressbook"><b>Address Book</b></a></dt>
|
|
|
|
<dd>
|
|
Provide support for client/vendor/customer address books,
|
|
including street addres, eamil, phone. Also: to-do lists,
|
|
a mini-contact manager (when is last time this person
|
|
was paid? what did they say on phone the last time we
|
|
sent them a check? Is there a dispute?)
|
|
<p>
|
|
Propose: use Ximian Evolution contact manager/to-do lists.
|
|
</p>
|
|
</dd>
|
|
|
|
<dt><a name="arap"><b>Accounts Payable, Receivable</b></a></dt>
|
|
|
|
<dd>Add features to track sales receipts and other pending
|
|
sources of income, as well as owed sums.
|
|
<ul>
|
|
<li>Need new account type 'ar' and 'ap'. When this account type is
|
|
selected, the register display, etc. is slightly different, as below:
|
|
<li>Add field to register called 'date due'. The date could be
|
|
entered as 'date of transaction +30days'. etc. The account
|
|
could have a default: entries always default to +30 or +45 days
|
|
or whatever.
|
|
<li>Create a report to match 'date due' to current date, and report
|
|
overdue balances ...
|
|
<li>Create Account aging report: show (average) age of
|
|
amount-due/amount-owed.
|
|
<li>Create a projected cash flow report: showing projected
|
|
future payments based on date due.
|
|
<li>Somehow, automatically match invoices to payments.
|
|
When an invoice has been paid off, then there should be a
|
|
view mode where the invoice and its payment is no longer shown
|
|
(i.e. so that only outstanding, unpaid entires are shown ...)
|
|
<li>create report showing everything but the a/p:
|
|
Here's an example. I buy a chair for a friend, and three
|
|
days later he pays me back. What I've been doing is ...
|
|
<pre>
|
|
> 1/12/01 Credit -$100
|
|
> A/R +$100
|
|
> 1/15/01 Cash +$100
|
|
> A/R -$100
|
|
</pre>
|
|
To make it less painful to read and understand, the
|
|
report should look like:
|
|
|
|
<pre>
|
|
> 1/12/01 Credit -$100
|
|
> 1/15/01 Cash +$100
|
|
</pre>
|
|
i.e. there would be a new kind of 'transaction report' that
|
|
would pair up transactions in this way, showing things
|
|
'as if' the A/R didn't exist, and 'as if' a transaction
|
|
was spread over a bunch of days.
|
|
|
|
</ul>
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="payroll"><b>Payroll</b></a></dt>
|
|
|
|
<dd>
|
|
Payroll introduces a <em>sizable</em> 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.
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="invoice"><b>Invoicing</b></a></dt>
|
|
|
|
<dd>Invoicing. Note that invoicing and order entry are
|
|
closely related.
|
|
Several components:
|
|
<ul>
|
|
<li>Record an invoice. Assign it a serial number. Be able
|
|
to reprint/report based on invoice serial number.
|
|
<li>Invoice associates customer name to set of transactions.
|
|
Need to deal with PIM issue. I.e. need to integrate
|
|
with high-function PIM or CRM interface.
|
|
<li>Allow historical browsing of invoices customer by customer.
|
|
<li>To visually design an invoice, need to have a
|
|
mini-word-processor/simple drawing plug-in. Is
|
|
Abisource/Abiword a candidate? Probably needs bonobo...
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt><a name="order"><b>Order Entry</b></a></dt>
|
|
|
|
<dd>
|
|
Mini-GUI allowing users to type in orders.
|
|
<ul>
|
|
<li>Should interface to parts/inventory database to confirm
|
|
item availability, (maybe recommend additional production)?
|
|
inventory should be updated after order placement.
|
|
<li>Automatically update accounts receivable.
|
|
<li>Allow order revision/update (esp. as partial orders are shipped).
|
|
<li>Orders can be invoiced when entered (simple invoicing), or
|
|
placed on account (double invoicing).
|
|
<li>Allow back-orders to be printed customer-by-customer, or by
|
|
product/item.
|
|
<li>Allow printing of packing slip.
|
|
</ul>
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="estimate"><b>Job Costing</b></a></dt>
|
|
|
|
<dd>Ability to prepare and track estimates.
|
|
<ul>
|
|
<li>Allow estimate/bid to be converted to a firm order & get invoiced.
|
|
</ul>
|
|
<p></p>
|
|
</dd>
|
|
|
|
<dt><a name="expense"><b>Expense Accounts</b></a></dt>
|
|
|
|
<dd>Expense Account Automation, including air, car, hotel,
|
|
dining. Receipts, reservations, cancellations.
|
|
<p></p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h1>References</h1>
|
|
All software and technical standard references have been moved to
|
|
<a href="http://www.gnucash.org/links.php3">
|
|
http://www.gnucash.org/links.php3</a>
|
|
|
|
<hr>
|
|
Draft version 0.51 -- June 2001
|
|
Linas Vepstas
|
|
<a href="mailto:linas@linas.org">linas@linas.org</a>
|
|
<br>
|
|
</body>
|
|
</html>
|
|
|