-This document is divided into several sections. The first deals with -archititectural and philosophical design issues. The second deals with -interesting technologies. The third deals with desirable features and -functions. +This document is divided into several sections. +
+
+
+
+
- -
+A personal finance system needs to be easy to use, have a simple +'intuitive', yet powerful, menu system, and provide graphs, charts, +net-worth reports, mortgage calculators, budget planners, and +and interfaces to on-line banking, shoping and stock systems. +
+A business system needs to run over the network, allowing multiple +simultaneous users. It needs support for payroll, inventory control, +shipping & receiving, billing, accounts payable & receivable. +Pie-in-the-sky might include interfaces to on-line shopping carts, +credit-card clearing interfaces, interfaces into ERP systems.
+
+
+
+
+
- Other output format possibilities include SGML and XML. In the
- long run, these are preferable to HTML, since DSSSL and
- Jade (James DSSSL Engine
- can be used to convert to RTF, Postscript, etc. XML is the wave
- of the future.
-
- The Report Generator should be a "dockable" subsystem of the
- whole. Thus, it should be possible to run the report generator
- in a stand-alone, read-only fashion without having to start up the main
- application.
-
- Graphs, charts, etc. too ...
-
- One hard part of reporting is designing a configurable interface,
- so that people can build custom reports.
-
- Status:
-
-
-
- Status:
-
-
-
- Status:
-
-
-
- Status:
-
-
-
- Current Status: the latest beta-development releases (version
- 1.1.x) contain such an object.
-
-
-
- Current Status:
-
-
-
- The overall architecture is envisioned to be as so:
- 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.
-
- 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 thier associated
- callbacks, will be specified in an ext-lang configuration file.
- At the final stages, it is hoped that new modules can be imported
- without requiring that the application itself be recompiled & relinked.
-
- Status:
-
-
-
- The following industrial-strength features are still needed:
-
-
-
-
-
-
- Status:
-
-
-
- Status:
-
- Most of the work has been done by
- Jeremy Collins, with considerable help from Rob Browning.
- Daniel R Risacher <magnus@alum.mit.edu> keeps threatening to
- do something ...
-
-
+
-
+ Other output format possibilities include SGML and XML. In the
+ long run, these are preferable to HTML, since DSSSL and
+ Jade (James DSSSL Engine
+ can be used to convert to RTF, Postscript, etc. XML is the wave
+ of the future.
+
+ The Report Generator should be a "dockable" subsystem of the
+ whole. Thus, it should be possible to run the report generator
+ in a stand-alone, read-only fashion without having to start up the main
+ application.
+
+ Graphs, charts, etc. too ...
+ Asset allocation pie chart.
+ Graph portfolio value vs. cost
+
+ One hard part of reporting is designing a configurable interface,
+ so that people can build custom reports.
+
+ Stock portfolio tools should include a cost-averaging report.
+ Market Index report. Stock Option values. Estimate capital gains taxes.
+
+ Status:
+
+
+
+ Question: how to most simply allow the user to enter loads and fees?
+ Answer: through splits. However, some users may not understand splits,
+ at least not initially. Thus, a little popup that allows the user to
+ type in the sales load or fee, & etc, and then auto-creates the needed
+ splits.
+
+ Note the current transfer window does NOT allow a share price to
+ be specified !! Needs fixin ...
+
+
+
+
+
+
+
+
+
+
+
+
-
- Current status:
+
+
+
+ The overall architecture is envisioned to be as so:
+ 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.
+
+ 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 thier associated
+ callbacks, will be specified in an ext-lang configuration file.
+ At the final stages, it is hoped that new modules can be imported
+ without requiring that the application itself be recompiled & relinked.
+
+ Status:
-
+
+
+
+
+
+
+
+
+
+ Status:
+
+
+
+
+ Design/implementation for this is tricky. It should probably leverage
+ crontab, but this can lead to difficulties & bugs.
+ May need interfaces to email for emailed alerts. Interfaces into
+ calendering systems?
Current status:
-
+ Note that the above 'step-by-step' budgeters will have a very
+ very different GUI than what e.g. a small-business budget might
+ look like.
+
+
+ Status:
+
-
-
+ Status:
+
-
+ 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. Its fragile because minor DTD non-compliances
+ are hard to parse, handle and recover from. Its huge because the
+ DTD results in hundreds of (C++) objects being generated.
+ The other way is to perform run-time DTD parsing. This is nice
+ because this is the more popular approach: there are a variety of
+ XML tools available that provide this function. Its slower, but
+ on the OFX client side, this is not a bottleneck.
+
+ Status:
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Status: Some basic reorganization of register was done to
- support mixed multi-line split display. However, the actual
- display of such things remaions unimplemented.
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+ The current engine is rather simple: it provides support for
+ accounts, account heirarchies and transactions consisting of
+ multiple entries. Many of the features described elsewhere
+ need the engine to have a far richer, more sophisticated data
+ model: parties (names, addresses), transaction id's & part numbers,
+ budgets, interest rates, A/R, A/P, etc.
+
+ Note: it makes no sense to make the engine API richer than what
+ the GUI can currently support.
+
+ Current Status:
+
+
+
+
+
+
+
+ The following industrial-strength features are needed:
+
+
+
+
+
+
+
+
+
+
+Feature Requirements
+
+
+
+Personal Financial Application
+Below are listed the technical work items needed to implement
+the features that home might need or expect. They are listed
+in approximate order of priority.
+
+
+
+
+Small Business Features
+Features that small/medium businesses expect.
+
+
+
+
+
+
+
+
+
+
Features and Functions
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- More ...
-
-
-
-
-
-
-
+
+
+
-
+
+
+
+ Create a summary budget/track-record budget report that a
+ professional financial planner/advisor could use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-