| A/R, A/P Accounts Payable,
Receivable |
@@ -1165,6 +1179,7 @@
Through multi-line transactions. Seems to work well in
1.6.0.
+
Themes, Icons, Glitz
@@ -1520,6 +1535,31 @@
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.
+
+ 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).
+
+
+ Status:
+ The following not done:
+
+ - Account Creation
+ The account creation panel is somewhat busy. Maybe
+ could use a wizard?
+
+ - Budget Setup
+ Setting up a budget.
+
+ - Obscure Corners
+ 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?
+
+
+ Completed:
-
New User Setup Provide
@@ -1531,21 +1571,13 @@
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).
-
- - Account Creation
+ just a club). Done in version 1.6.0, C. Champagne,
+ J LewisMoss
- QIF Import
QIF Import is just complicated enough that it needs
- a wizard walk-through of the steps. Grib has a prototype.
-
- - Budget Setup
- Setting up a budget.
-
- - Obscure Corners
- 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?
+ a wizard walk-through of the steps. Grib,
+ version 1.6.0, Done.
@@ -1556,7 +1588,7 @@
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 alllowing a user to set 'preferences'. 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
@@ -1601,6 +1633,13 @@
radio formats and Napster.
+
+ Status:
+ 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.
+
User Preferences, Session Management
@@ -1617,30 +1656,32 @@
things ... sort-of. Right now, we don't treat them as such
...
- Session management is not implemented; viz, we don't
- remember where things were left at when the user shut down
- the windowing system, and we don't restore the session
- afterwards. This includes: which register windows were left
- open, what sizes they were, what their placements on the
- screen were, etc. I believe session management needs to be
- coordinated with KDE and with gnome, and all compliant
- window managers will do the rest (?)
-
- 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.
-
Status:
+ Done, more or less, version 1.6.0.
- - Works good; lots of preferences in the GUI.
- Implemented in home-grown scheme.
+ - Works real good; lots of preferences in the GUI.
+ Implemented in home-grown scheme. (version 1.4.0,
+ rlb)
- These are saved in the '.gnucash/config.auto' file.
- The current file format is raw scheme code, rather
- delicate to tweak by hand ...
+ The current file format is raw scheme code, rather
+ delicate to tweak by hand ...
+
+ - 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
+
+
+ - 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.
+
+
@@ -1726,8 +1767,8 @@
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: need to find/evaluate gnome-calendar/day-planner
- for integration.
+ Technology: best bet is the Ximian Evolution Calander
+ component.
Design Notes: Most alerts & data storage
should be driven out of the engine. This will enable
@@ -1756,7 +1797,7 @@
- Need to create design doc, need to implement engine
pieces, need to hunt down gnome-calendaring bonobo.
- - RLB thinks its 2-3 weeks for items 1,2,3.
+
- Preliminary work started.
@@ -1811,7 +1852,7 @@
Classes
- Ability to mark certain jopurnal entries as belonging to
+ 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
@@ -1823,16 +1864,15 @@
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 (!)
+
+ Confusion: isn't this what the 'action' field is supposed to do?
+ The 'action' field is under-utilized.
This requires the following:
- - place in the engine where split can be marked
- (grib is implementing in a slot, with use with qif import).
-
- gui where splits can be marked up as beloinging to a certain
- class.
-
- Ability to report by class
-
- Ability to query by class.
+
- Ability to report by class/action
+
- Ability to query by class/action.
@@ -1845,8 +1885,8 @@
Build automated test suite, including:
- - File IO consistency check. RLB.
-
- Currency math correctness. Grib.
+
- File IO consistency check. Done, 1.6.0, LewisMoss
+
- Currency math correctness. Done ?? Grib.
@@ -1856,7 +1896,8 @@
Ability to import Quicken QIF files. Both MSMoney and
- Quicken use QIF files to export data.
+ Quicken use QIF files to export data. Need both wholsesale
+ data import, and incremental (staged) merge.
Status:
@@ -1869,23 +1910,20 @@
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, in process for 1.5)
+ through this process. (grib, done in 1.6.0)
Work needs to be done for recurring transactions, etc.
QIF processing, as used for on-line banking, is
- not implemented. That is, staged import isn't
- done.
+ in prototype form (for 1.6.1 ??)
Note that since banks use QIF, the correct
- way to reconcile bank accounts on-line is through
- QIF.
+ 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.
- Now, just put them together ...
- Grib estimates 2 weeks for this.
@@ -1893,10 +1931,30 @@
- Quicken(TM) Export
+ IIF Import
- Ability to export Quicken QIF files.
+ Ability to import IIF (Intuiut Interchange Format, used by Quickbooks)
+ files, quickbooks, some upsacle accounting packages use this format.
+
+ Status:
+
+
+ -
+ Sample files checked into sample directory.
+ No formal documentation known.
+
+
+
+
+
+
+ IIF Export
+
+
+ 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:
@@ -1908,7 +1966,8 @@
- It is fairly easy to traverse the data in the engine
- to write out qif files. Just do it.
+ to write out qif files. This is not hard. Just do it.
+
@@ -1925,48 +1984,48 @@
(e.g. get 5-year history of mutual fund
performance vs. DJIA).
- Right now, stock prices are stored along with everything
- else, in the main database, in the transaction table.
- This leads to several aesthetic quandaries.
+ Right now, stock prices are stored in a separate, simple pricedb.
+
- - It bulks up the database with 'less-than critical'
- information. That's bad. We need an alternate storage
- mechanism.
+ - 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.
+
+
+ - Add to this the idea that we should probably store other
+ 'technical' stock data, such as share volume, high/low/close,
+ daily volatility, etc.
+
- - Currently, the transactions stored in the engine
- are either 'critical' viz.,
- record the movement of money, or are non-critical viz.
- record things retrievable from the historical record,
- e.g. prices.
- This alone is a good reason to ask that price & other
- non-critical financial data be stored in a separate location.
- Add to this the idea that we should probably store other
- 'technical' stock data, such as share volume, high/low/close,
- daily volatility, etc.
+
- Need access to historical quotes, for graphing charting
+ of historic portfolio perfformance.
Status:
Reconcile Auditing
@@ -2594,7 +2658,13 @@ Password:
does not satisfy the 'ACID' criteria.
-
+
+ Status:
+ 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.
+
+
Multi-user Support
@@ -2603,9 +2673,6 @@ Password:
Multi-user support should be added with either an SQL
backend to the engine, and/or through CORBA interfaces to
the engine.
- Project Kontor and also FreeMoney is working on SQL
- schemas; Kontor is also working on Java RMI/CORBA
- interfaces.
Another possibility is to create a web application
server, and have users do much/most of I/O via a web
interface, possibly using the register object as a browser
@@ -2623,13 +2690,33 @@ Password:
user authorization
- non-repudiability
+ non-repudiability (needed only for peer-to-peer??)
encryption of network connections
-
+
+ Status: 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.
+
+ Address Book
+
+
+ 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?)
+
+ Propose: use Ximian Evolution contact manager/to-do lists.
+
+
+
Accounts Payable, Receivable
Add features to track sales receipts and other pending