IntenseFinance/gnucash
3
0
Fork 0
mirror of https://github.com/Gnucash/gnucash.git synced 2026-08-08 20:18:28 -05:00
Code Issues Packages Projects Releases Wiki Activity

updates to status

Browse Source 
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@4763 57a11ea4-9604-0410-9ed3-97b8803252fd
This commit is contained in:
Linas Vepstas
2001-06-21 23:25:45 +00:00
parent 4ffca9fc7b
commit 66b87e2b0c
1 changed files with 247 additions and 125 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/projects.html
+247 -125
View File
@@ -2,8 +2,6 @@
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>GnuCash Project Goals</title>
<meta name="description" content= "The Linux GnuCash project
aims at creating a world-class personal finance package.
@@ -22,7 +20,8 @@
<h1>GnuCash Project Goals</h1>
<p>The people behind <a href="http://www.gnucash.org">GnuCash</a>
<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
@@ -33,31 +32,33 @@
"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>
archives.
</p>
<p>There are currently several different versions of GnuCash.
<p>
There are currently several different versions of GnuCash.
We've adopted the kernel numbering scheme: even minor release
numbers (1.2.x, 1.4.x) are considered to mark stable releases,
while odd numbers (1.3.x, 1.5.x) mark development releases.
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.4.6 and
is based on the <a href= "http://www.gnome.org">Gnome</a> / <a
href= "http://www.gtk.org">GTK</a> libraries.
<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.5.x releases focus on adding new features and
improving existing functionality.
<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,
<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.4.6.
More adventurous users can try one of the 1.5.x releases, However,
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>
@@ -89,26 +90,28 @@
<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>
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>
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>
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
<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
@@ -120,7 +123,8 @@
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
<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
@@ -133,54 +137,81 @@
the GUI (or a script, or even a clever command-line-addict) can
use to manipulate the data.
<p>Currently, the Engine is fairly poor, and is tightly tied to
the data structures that the GUI manipulates. These data
structures include:</p>
<p>
Currently, the Engine provides basic accounting structures
These include: </p>
<ul>
<li><b>Transactions</b>, which consist of a set of journal
entries (JE's) whose values sum to zero.</li>
<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 record prices and values.</li>
'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 consist of a list of journal
entries.</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 very simple apply/commit model, and a simple
query mechanism for generating reports and views. The goal of
the commit and query model is to aid/simplify the creation of
&amp; merger with an SQL back-end.
<p>The Engine currently handles only a small set of data
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;</li>
<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 binary byte stream;</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 get stock quotes from the net.</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
<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.</p>
<p>In particular, it should be possible to back the Engine onto
an SQL database, and thereby enable multiple users and/or
interface to more complex accounting systems. The engine should
also be expandable to handle other sources of data, such as
OFX, Integrion GOLD, the Open Trading Protocol, the OMG CORBA
General Ledger submission, the
<a href="http://www.ibm.com/software/ad/sanfrancisco/">
IBM San Francisco business objects</a>,
or closer to home, Linux Kontor. In particular, it
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>
these sources, but also to manipulate it and send it back.
</p>
<h2>Modularity, Extensibility and Customization</h2>
@@ -204,14 +235,14 @@
<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>
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>
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>
@@ -219,38 +250,70 @@
<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 online micro-payment systems. For GnuCash
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
aloing this path. First, it must be possible to simply and
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 should become "The More Sophisticated Financial Web Browser".
Why? Because dyncamically-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. Sure Java plugins can
provide a fancier interface than html forms, but a java plugins
that is sophisticated enough is also slow to download. No two
Java plugins are alike: every site has thier own: no standardization.
Wouldn't you rather use one GUI that you already kn ow for all your
on-line financial interactions? Never mind that many people have
Java disabled in thier browser due to security concerns (oh, tell me
again, you do financial things, and you're NOT concerned about security?)
Finally, no Java plugin provides you with monthly or quarterly
reports of your financial status. Maybe your credit card company
does this over the web, but what if you have <b>two</b> credit cards?
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>
GnuCash can provide a centralized, trusted store for financial
data that no other application can provide. There's the convenience
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. There's the trust factor:
<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
@@ -265,74 +328,130 @@
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.
GnuCash should be able
to act not only as a secure purse/wallet on the internet, but it
should infact be that trusted financial advisor that no other
technology is in a position to fill.
</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>
Implicit in this desire for extensibility is the need to build
financial applications supporting two major classes of users:
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>Home Users</li>
<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>
They may use some of the same financial terminology, and
hopefully might share a fair bit of code, but have quite
different goals and requirements.
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>Personal Finance Needs</h3>
<h3>Basic Household Accounting and Budgeting</h3>
<p>Important properties of a personal finance system
include:</p>
<ul>
<li>Needs to be approachable and usable by occasional users
who are not knowledgeable about accounting.</li>
<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>
tools for personal finance, such as mortgage
calculations.</li>
<li>Budgeting support needs to be targeted at <em>naive</em>
users.</li>
users.</li>
<li>Interfaces to on-line banking, shopping, stock
systems.</li>
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>
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
full-time users, which puts the emphasis on <em>
efficiency</em> of user interface rather than on its
approachability to naive users.</li>
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>
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
for ASP type deployment.</li>
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
@@ -340,6 +459,8 @@
sophistication in such areas as:
<ul>
<li>Customer and Vendor Lists; Invoicing</li>
<li>Payroll (Batch processed and individual)</li>
<li>Inventory Control &amp; Asset Management</li>
@@ -354,11 +475,11 @@
</li>
<li>Support for calculations associated with accrual
accounting.</li>
accounting.</li>
<li>Ambitions for the future might include interfaces to
online shopping carts, credit card clearing interfaces, and
ERP systems.</li>
online shopping carts, credit card clearing interfaces, and
ERP systems.</li>
</ul>
<h3>Reconciling Those Needs</h3>
@@ -369,7 +490,7 @@
<ul>
<li>A home user does not generally require most of the
sophistication (sophistry?) of accrual accounting that is
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
@@ -386,7 +507,7 @@
<li>Mutual funds</li>
<li>Retirement savings plans, with such identifiers as
401(k), IRA, Roth IRA, RRSP</li>
401(k), IRA, Roth IRA, RRSP, or Insurance Annuities</li>
<li>Corporate stock purchase plans</li>
@@ -434,6 +555,7 @@
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>
@@ -455,8 +577,8 @@
<tr>
<td><a href="#i18n">Internationalization</a></td>
<td>Small</td>
<td>Dave</td>
<td>Done</td>
<td>-</td>
</tr>
<tr>
@@ -824,7 +946,7 @@
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.</li>
fixing. (This may be done already??)</li>
</ul>
</p>
</dd>