- | Enhanced Engine, Financial
+ | Enriched Engine, Financial
Objects |
Large |
@@ -772,83 +772,76 @@
- A general reporting infrastrucutre was implemented in
- Perl, in the form of html-embedded perl (ePerl). However,
- this reporting mechanism was abondoned in part because
- ongoing build and install problems related to eperl and
- swig. Also, since eperl didn't poarticipate in the
- interpreter even loop, the report generator had to runn
- as a separate process, reading data via pipes. This was
- uglier than some folks liked.
+ Perl, in the form of html-embedded perl (ePerl). However,
+ this reporting mechanism was abondoned in part because
+ ongoing build and install problems related to eperl and
+ swig. Also, since eperl didn't poarticipate in the
+ interpreter even loop, the report generator had to runn
+ as a separate process, reading data via pipes. This was
+ uglier than some folks liked.
- A general reporting infrastructure has been implemented in Scheme.
- Currently, there are simple reports for Profit/Loss,
- Balance Sheet, and portfolio valuation.
+ "xacc-reports.html#NEWREP">implemented in Scheme.
+ Currently, there are simple reports for Profit/Loss,
+ Balance Sheet, and portfolio valuation.
- Reports are currently displayed with the gtk-xmhtml
- widget but are being ported to the gtk-html widget. The
- gtkhtml widget should provide printing abilities through
- gnome-print (right ????).
+ widget but are being ported to the gtk-html widget. The
+ gtkhtml widget should provide printing abilities through
+ gnome-print (right ????).
- There is currently no way (no longer any way??) to
- generate reports from the command line ...
+ generate reports from the command line ...
- A list of 'required reports' is needed. Then these
- need to be implemented.
+ need to be implemented.
+
+
+ - Heavy discussion by matt martin, Robert Merkel ...
+
- - Heavy discussion by matt martin, Robert Merkel
- ...
-
- The following technologies were rejected/unused mostly
- because they were too complex, didn't hang together technologies:
- SGML and Extensible
- Markup Language - XML. In the long run, these are
- preferable to HTML, since DSSSL tools such as Jade (James DSSSL
- Engine) can be used to convert to RTF, Postscript, etc.
- Add to this the consideration that XML is the basis for the
- Document Object Model,
- which is being integrated into many web-based applications,
- and we can see that XML is an increasingly significant
- format as we look to the future.
+ because they were too complex, didn't hang together technologies:
+ SGML and Extensible
+ Markup Language - XML. In the long run, these are
+ preferable to HTML, since DSSSL tools such as Jade (James DSSSL
+ Engine) can be used to convert to RTF, Postscript, etc.
+ Add to this the consideration that XML is the basis for the
+ Document Object Model,
+ which is being integrated into many web-based applications,
+ and we can see that XML is an increasingly significant
+ format as we look to the future.
-
-
Graphs
- Graph portfolio value vs. cost
-
- Graphs, charts, etc. too ...
-
- Asset allocation pie chart.
-
- The following graph packages are candidates: GUPPI, plotutils,
- gnumeric/graph code. The gnumeric/graphcode is already
- bonobo-ified.
-
- If gnumeric and gnucash are to use a common graph
- solution, the following are gnumeric requirements: --
- interactive plot editing -- each segment attributes totally
- settable/controllable -- drag/move callbacks when segments
- are click-draged.
-
- Graphs should be printable to printer.
+ 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.
+
Status:
-
- - Evaluate different graphing packages, including GUPPI
+ - Different graphing packageswere evaluagted,
+ GUPPI.
+ 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-draged.
+
-
-
Simplified Ledger
@@ -1150,14 +1143,68 @@
- Permanently lock some transactions as non-editable.
- This should be straight-forward by using the
- reconciled field to indicate a locked
- value, and not allowing the GUI to edit locked
- records.
-
+ This should be straight-forward by using the
+ reconciled field to indicate a locked
+ value, and not allowing the GUI to edit locked
+ records.
+
- Transfer the Income minus Expense for the book period
- to an equity account, so that each new period starts with
- zero income/expense balances.
+ to an equity account, so that each new period starts with
+ zero income/expense balances.
+
+ - A mechanism to purge really old transactions from the
+ database.
+
+ - Extensions to querying and reporting infrastructure ...
+ The query changes might be painful ...
+
+ -
+ A user should be allowed to 'delete' an account
+ only if it has no transactions in the currently
+ open book.
+ Of course, it's not deleted from the old books.
+ From this last, we conclude that every chart of
+ accounts should have a begining and ending date (that
+ match the book period), and the file format needs to
+ support multiple charts ...
+
+ - Memorized Transactions ... Currently, transaction
+ autocompletion works by autocompleting with the last
+ 'similar' transaction. This ability will get trashed
+ when books for the old year get closed, because there
+ won't be 'similar' transactions.
+
+
+
+ Status:
+
+ - A mini-design doc exists in
+ src/engine/future.txt
+
+
+
+
+ Check Printing
+
+
+ Create a check-printing ability. Includ MICR (Magnetic Ink,
+ Computer Readable) check printing abilities.
+
+ Yahoo Check Printing provides a list of vendors & printers.
+
+ Status:
+
+
+ - Bill Gribble has built a prototype based on the
+ gnome-print. Waiting for gnome-print to mature ...
+ - Need a sample check/sample transaction to print out
+ sot that user can test printer.
+
- MICR Fonts are available & brought to mailing list.
+
+
+
+
+
Wizards
@@ -1192,69 +1239,6 @@
-
-
- A mechanism to purge really old transactions from the
- database.
-
- Extensions to reporting infrastructure ...
-
-
- A user should be allowed to 'delete' an account
- only if it has no transactions in the currently
- open book.
-
- Of course, it's not deleted from the old books.
-
- From this last, we conclude that every chart of
- accounts should have a begining and ending date (that
- match the book period), and the file format needs to
- support multiple charts ...
-
- Memorized Transactions ... Currently, transaction
- autocompletion works by autocompleting with the last
- 'similar' transaction. This ability will get trashed
- when books for the old year get closed, because there
- won't be 'similar' transactions.
-
-
-
-
-
-
- Status:
-
-
- - A mini-design doc exists in
- src/engine/future.txt
-
-
-
-
-
-
-
- Check Printing
-
-
- Create a check-printing ability. Includ MICR (Magnetic Ink,
- Computer Readable) check printing abilities.
-
- Yahoo Check Printing provides a list of vendors & printers.
-
- Status:
-
-
- - Bill Gribble has built a prototype based on the
- gnome-print. Waiting for gnome-print to mature ...
- - Need a sample check/sample transaction to print out
- sot that user can test printer.
-
- MICR Fonts are available & brought to mailing list.
-
-
-
-
-
User Preferences, Session Management
@@ -1299,8 +1283,7 @@
- Extension Language Support
-
+ Architecture Review
The application is wired together partly with C, partly
with Scheme. The architecture of the wiring and how scheme
@@ -1308,9 +1291,8 @@
created so that additional extensions may be added in a
straightforward manner.
- The overall architecture is envisioned thus:
-
- All code, including the transaction engine, the file I/O
+
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
@@ -1329,14 +1311,20 @@
Status:
- - Scheme/Guile is the central extension language.
-
- - Optional interfaces to the data engine can be
- generated using
- SWIG.
-
- - Rob Browning is the reigning expert.
+ -
+ Scheme/Guile is the central extension language. Guile
+ interfaces auto-generated using g-wrap.
+
+ -
+ Optional interfaces to the data engine (for, e.g.
+ perl) can be generated using
+
+ SWIG.
+
+ -
+ Dave to collacte & edit architecture documents.
+ RLB to provide diagrams.
+
@@ -1471,11 +1459,19 @@
Status:
- - Quicken import is implemented and mostly works.
- (Bill Gribble, Done, in version 1.4.0)
-
- - Work needs to be done for recurring transactions, etc.
-
+ -
+ Quicken import is implemented and mostly works.
+ (Bill Gribble, Done, in version 1.4.0)
+
+ -
+ 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.
+
+ -
+ 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
@@ -1586,8 +1582,9 @@
- Install
-
- Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux,
- etc.
+ Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux,
+ etc. Possibly use a 'configure'-like way of dealing with
+ install inconsitencies.
@@ -1612,9 +1609,16 @@
Implement the 'correct' way of handling this when user
is working in multiple currencies on a regular basis.
+
+ SERIFF
+ Simple Exchange Rate Information File Format. Completely
+ *.ini-centric in layout and design, but otherwise seemingly
+ quite complete.
+
- Status: Need to rethink wether the one-shot exchanges
+ Status:
+ Need to rethink wether the one-shot exchanges
should in fact be recorded full-fledged in the engine.
Also: EURO support is currently hacked in: the EURO is treated as
a 'special' currency. Virtually all the euro code can be fully
@@ -1668,17 +1672,13 @@
always. It will not be possible to disable this and move
to single-entry.
-
-
- 401(k), RSP
+ 401(k), Retirement Savings Plans
- 401K, 403, IRA, Roth IRA, SEP, Keogh ... "Retirement Savigs
- Plans"
-
- Retirement Savings Plans often do not put a high
+ 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??)
@@ -1780,17 +1780,12 @@ next due date mm/dd/yy
memo text
-
-
-
-
- Status:
+ Status:
-
-
+
Technical Stock Analysis
@@ -1979,6 +1974,29 @@ etc ...
+ Logging, Crash Recovery
+
+
+ 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.
+
+ Status:
+
+ - Crude transaction logging/auditing in place; should
+ be suitable for error/crash recovery but has not been
+ "tried by fire."
+
+ - Backup files automatically created and
+ time-stamped.
+
+
+
+
+
Enriched Engine, Financial Objects
@@ -2017,55 +2035,31 @@ etc ...
- Locks When splits are implemented, and the
- parent transaction has been marked as cleared, the record
+ 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).
-
- -
- Books Ability to close a book at the end of the
- fiscal year, thus indicating that nobody is permitted
- to "mess around" with that old data.
- In a business environment, the auditors may have
- "signed off" on the validity of the data; at that
- point, the ability to modify audited data should be
- very tightly controlled, or even outright
- forbidden.
-
Current Status:
- - The basic engine has been detangled from the GUI
- elements, as of version gnucash-1.1.4.
-
- - Binary file I/O mostly detangled into a separate
- module.
-
- - Crude transaction logging/auditing in place; should
- be suitable for error/crash recovery but has not been
- "tried by fire."
-
- - Backup files automatically created and
- time-stamped.
-
-
BeginEdit()/RollbackEdit()/CommitEdit()
routines mostly in place,
- These "Transaction processing constructs" should
+ these "Transaction processing constructs" should
simplify creation of an SQL back end, or some other
- more sophisticated database engine.
+ more sophisticated transactional server.
- Multiple currency support is present but still pretty
"raw."
- - Query engine is minimal/sparse in capabilities.
+ - Query engine has been broadly extended (Bill Gribble).
+ Documentation for Query Engine??
- - Linas <linas@linas.org> is maintaining the
- engine code.
@@ -2300,6 +2294,12 @@ Password:
Financial Applications for Linx
+
+ SERIFF
+ Simple Exchange Rate Information File Format. Completely
+ *.ini-centric in layout and design, but otherwise seemingly
+ quite complete.
+
gstalker
gtk/gnome stock grapher.
@@ -2388,14 +2388,13 @@ Password:
Integrion, a
16-bank + IBM consortium aimed at building up on-line banking
infrastructure. Mostly aimed at mainframes, middleware, high
- transaction volumes and data integrity.
-
+ transaction volumes and data integrity.
Java Point
of Sale interfaces.
- Gnu
+ Gnu
Plotutils needed for building the graphing portions of
the code.
@@ -2416,10 +2415,8 @@ Password:
Works
- Antarctic Project Server
-
- Maxwell's
- Lemur -- a GTK based table widget
+ Antarctic Project Server
+
GigaBASE embeddabale SQL database.
@@ -2432,28 +2429,36 @@ Password:
only.
- - X-Accountant
- Home Page - this was the original site for
- the GPL'ed accounting package that eventually evolved into
- GnuCash. Robin Clark wrote the first version while at school
- at Harvey Mudd College.
-
- - The original
- WaterMark Gnome/KDE personal finance project page.
- Watermark and GnoMoney were proposed about the same time, and
- there was talk of joining forces with X-Accountant.
-
- - FreeMoney
- Linux small-business accounting s/w. A proposal to build a
- business package back by SQL.
+ -
+ X-Accountant
+ Home Page - this was the original site for
+ the GPL'ed accounting package that eventually evolved into
+ GnuCash. Robin Clark wrote the first version while at school
+ at Harvey Mudd College.
+
+ -
+ The original
+ WaterMark Gnome/KDE personal finance project page.
+ Watermark and GnoMoney were proposed about the same time, and
+ there was talk of joining forces with X-Accountant.
+
+ -
+ Maxwell's
+ Lemur -- a GTK based table widget -- work discontinued
+ because gnumeric was much cooler.
+
+ -
+ FreeMoney
+ Linux small-business accounting s/w. A proposal to build a
+ business package backed by SQL.
+
- Draft version 0.38 -- June 2000
- Linas Vepstas
- linas@linas.org
- updates by Christopher Browne cbbrowne@ntlug.org
+ Draft version 0.40 -- August 2000
+ Linas Vepstas
+ linas@linas.org
+