@@ -650,134 +636,147 @@ we've been, and where we're going.
country. This would include the printing of currency values
in the local country conventions.
- Current status:
+
Current status:
- - All GUI messages currently use GNU gettext() for
- the message catalogs. Translations exist for
- English, British, French, Sweedish and German.
+ - All GUI messages currently use GNU gettext()
+ for the message catalogs. Translations exist for English,
+ British, French, Sweedish and German.
- - Help pages available only in English and French.
+
- Help pages available only in English and French.
- - Monetary and string handling done through glibc.
- The latest glibc (2.2.3) is nedded to get the correct
- functions.
+
- Monetary and string handling done through glibc. The
+ latest glibc (2.2.3) is nedded to get the correct
+ functions.
- Yannick Le Ny <y-le-ny@ifrance.com> traduction
- en francais
- - Most GUI input elements use the gtk text widget, and
- thus use the XIM input method in asian locales. This
- allows e.g. Kanji, Katakana support. However, the
- register does *not* use XIM, and thus doesn't currently
- support the asian languages. This needs fixing.
+ en francais
+
+ - Most GUI input elements use the gtk text widget, and
+ thus use the XIM input method in asian locales. This
+ allows e.g. Kanji, Katakana support. However, the
+ register does not use XIM, and thus doesn't
+ currently support the asian languages. This needs
+ fixing.
-
+
+
- - Reports
+ - Reports
-
- 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.
+ 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.
-
Other output format possibilities include SGML and Extensible
+ Other output format possibilities include 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.
+ href="http://www.jclark.com/jade/">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.
- 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 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.
- One difficult aspect of reporting is designing a
+
One difficult aspect of reporting is designing a
configurable interface, so that people can build custom
- reports. The New
+ reports. The New
Reporting Infrastructure is seeking to build this up
using Guile.
Generated reports should be exportable to other gnome
- systems using bonbo. Reports should also be exportable to
- the gnumeric spreadsheet (possibly by writing out gnumeric
- file format??)
+ systems using bonbo. Reports should also be exportable to
+ the gnumeric spreadsheet (possibly by writing out gnumeric
+ file format??)
Reports should make use of the 'action' field ...
Relationship to budgeting not clear ...
- Stock portfolio tools should include a Cost Averaging
+
+
Stock portfolio tools should include a Cost Averaging
report, Market Index report, Stock Option values,
Estimation of capital gains tax liabilities.
- Status:
+
Status:
- - 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.
-
- A general reporting infrastructure has been
- 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 ????).
+
- 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.
+
+ - A general reporting infrastructure has been 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 ????).
+
- There is currently no way (no longer any way??) to
- generate reports from the command line ...
-
- A list of 'required reports' is needed. Then these need
- to be implemented.
-
- Heavy discussion by matt martin, Robert Merkel ...
+ generate reports from the command line ...
+
+ - A list of 'required reports' is needed. Then these
+ need to be implemented.
+
+ - Heavy discussion by matt martin, Robert Merkel
+ ...
-
+
+
- - Graphs
+
+ - 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.
+
Graph portfolio value vs. cost
+ Graphs, charts, etc. too ...
- Status:
+
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.
+
+ Status:
- - Evaluate different graphing packages, including
- GUPPI
+
- Evaluate different graphing packages, including GUPPI
-
+
+
- - Simplified Stock Ledger
+ - Simplified Stock Ledger
-
Stocks and Mutual funds are handled by placing them each in
@@ -789,81 +788,67 @@ we've been, and where we're going.
understand and use. A simplified but still powerful ledger
window is desperately needed.
-
Question: How to most simply allow the user to
+
Question: How to most simply allow the user to
enter loads and fees?
- Answer: Through splits. Unfortunately, some
- users may not properly understand splits, at least not
- initially. Thus, a little popup is needed to allow the user
- to type in the sales load or fee and such, and then
- auto-create the needed splits.
-
- Note the current transfer window does NOT
- allow a share price to be specified !! Needs fixing ...
+ Answer: Through splits. Unfortunately, some users
+ may not properly understand splits, at least not initially.
+ Thus, a little popup is needed to allow the user to type in
+ the sales load or fee and such, and then auto-create the
+ needed splits.
+ Note the current transfer window does NOT allow
+ a share price to be specified !! Needs fixing ...
- Documentation
- -
- Need to add a 'meta keyword' tag to the documetnatin pages,
- this will help the search engine (e.g.
- htdig) better categorize
- the help.
- Mifluz might
- be more embeddable ...
- I am told that htdig-API is in good solid condition for this, but
- undocumented.
-
-
-
-
+ - Need to add a 'meta keyword' tag to the documetnatin
+ pages, this will help the search engine (e.g. htdig) better categorize the
+ help. Mifluz
+ might be more embeddable ... I am told that htdig-API is in
+ good solid condition for this, but undocumented.
+
+
+
- Themes, Icons, Glitz
-
-
A variety of finer touches need work:
-
-
-
- Hint-of-the-Day.
- A collection of a some 50-100 hints-of-the-day:
- short (2-4 sentance) hints/tips on how to use gnucash.
- Every time the user starts gnucash, an new hint shows up ...
-
+ Hint-of-the-Day. A collection of a some
+ 50-100 hints-of-the-day: short (2-4 sentance)
+ hints/tips on how to use gnucash. Every time the user
+ starts gnucash, an new hint shows up ...
-
-
- Themes.
- Some theme testing required. The effect of themes on the
- register window needs to be reviewed.
-
+ Themes. Some theme testing required. The
+ effect of themes on the register window needs to be
+ reviewed.
-
-
- Button Bar
- A user-configurable button-bar would be nice
- too. The button bar is the set of 'buttons' (open, edit...)
- at the top of a register window and the main window.
-
+ Button Bar A user-configurable button-bar
+ would be nice too. The button bar is the set of
+ 'buttons' (open, edit...) at the top of a register
+ window and the main window.
-
-
- Categories/Default Chart of Accounts
- 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
+
Categories/Default Chart of Accounts 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.
- To actually implement this, it might be best to
+
To actually implement this, it might be best to
simply create a file with these in them, and load that
file. A mechanism should be provided to allow the user
to weed out undesired accounts whilst not preventing
@@ -871,263 +856,249 @@ we've been, and where we're going.
-
-
- Household Assets
- Add an example showing how regular household assets
- (house, car, jewelry, etc.) should be treated. In
- particular, show how appreciation and depreciation
- should be treated.
+ Household Assets Add an example showing how
+ regular household assets (house, car, jewelry, etc.)
+ should be treated. In particular, show how appreciation
+ and depreciation should be treated.
-
-
- More account types
- Introduce more 'fundamental' account types: (ammortized) Loan,
- Mortgage, ESOP, House, Line of Credit.
-
+ More account types Introduce more
+ 'fundamental' account types: (ammortized) Loan,
+ Mortgage, ESOP, House, Line of Credit.
-
-
- Cut-n-paste
- Cut-n-paste of items in the regsiter window...
-
+ Cut-n-paste Cut-n-paste of items in the
+ regsiter window...
-
-
- Bank name in combo-box pull-down
- When user enters a new bank name, should be presented with
- a combo-box listing other bank-account names ...
- (note this may require implementation of engine callbacks
- so that relevent code can be informed when there are new
- bank names?)
-
+ Bank name in combo-box pull-down When user
+ enters a new bank name, should be presented with a
+ combo-box listing other bank-account names ... (note
+ this may require implementation of engine callbacks so
+ that relevent code can be informed when there are new
+ bank names?)
-
-
- Currency Selection Popup
- Currency field should get preplaced by menu of long-hand
- currency names, three-letter ISO abbreviations, and symbols.
- User should be able to add new currency types.
- Should also keep a static exchange-rate table.
-
+ Currency Selection Popup Currency field
+ should get preplaced by menu of long-hand currency
+ names, three-letter ISO abbreviations, and symbols.
+ User should be able to add new currency types. Should
+ also keep a static exchange-rate table.
-
-
- Popup Calculator
- All price/amount fields should pop up a calculator widget;
- output of calculator gets entered in field.
-
+ Popup Calculator All price/amount fields
+ should pop up a calculator widget; output of calculator
+ gets entered in field.
-
-
- Popup Calender
- All date fields should pop up a calender widget;
- selected date should get entered in field.
-
+ Popup Calender All date fields should pop up
+ a calender widget; selected date should get entered in
+ field.
-
-
- Register View
- Allow user to view only non-reconciled transactions ...
-
+ Register View Allow user to view only
+ non-reconciled transactions ...
-
-
- Autocompletion
- Quickfill should also auto-complete amount, memo fields.
-
+ Autocompletion Quickfill should also
+ auto-complete amount, memo fields.
-
-
- Autoincrement
- Check numbers should auto-increment.
-
+ Autoincrement Check numbers should
+ auto-increment.
-
-
- Configurable main-window Status Bar
- Bottom of main window currently shows total assest, and
- total income-expense (profits). Make this configurable,
- so that user can show arbitrary sums of arbitrary accounts.
-
+ Configurable main-window Status Bar Bottom of
+ main window currently shows total assest, and total
+ income-expense (profits). Make this configurable, so
+ that user can show arbitrary sums of arbitrary
+ accounts.
-
-
- Dockable Registers/ aka "Browser Mode".
- 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.
-
+ Dockable Registers/ aka "Browser Mode".
+ 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.
-
-
- Wizards/Context sensitive help.
- When users create new accounts, need to suggest stuff if
- the user typed something unexpected ... (e.g. non-alphanumeric
- input) ...
-
+ Wizards/Context sensitive help. When users
+ create new accounts, need to suggest stuff if the user
+ typed something unexpected ... (e.g.
+ non-alphanumeric input) ...
-
-
- Navigation
- Menu navigation using the keyboard should be
- possible.
- Although menu mnemonics exist, they seem to be
- broken. ???
+ Navigation Menu navigation using the keyboard
+ should be possible. Although menu mnemonics exist, they
+ seem to be broken. ???
- Similarly, tab-key navigation should be possible.
+
Similarly, tab-key navigation should be possible.
Currently, it is possible to use the tab key to
navigate from field to field in the register window, to
user arrow keys to navigate menus, and quick-fill to
automatically complete fields. However, it is not
- possible to tab over to the "Commit" button.
- It should be.
+ possible to tab over to the "Commit" button. It should
+ be.
-
-
- Folder Tabs
- 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.
+ Folder Tabs 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.
-
-
- Fly-Over Help
- When the user pauses the mouse over a button,
- "fly-over" pop-up help windows should appear.
+ Fly-Over Help When the user pauses the mouse
+ over a button, "fly-over" pop-up help windows should
+ appear.
-
-
- Grayed-out Form Help
- Create grayed out entries in the ledger, titled
- "Memo", "Description", etc, helping users understand
- what should be typed into each field. Status: Done,
- as of version 1.3.2(?)
+ Grayed-out Form Help Create grayed out
+ entries in the ledger, titled "Memo", "Description",
+ etc, helping users understand what should be typed into
+ each field. Status: Done, as of version
+ 1.3.2(?)
-
-
- emacs, vi,
- motif, KDE, gnome Key Bindings for Text Fields
- Make sure that text fields can handle the vi and
- emacs key bindings, so that e.g. emacs-style
- ctrl-a, ctrl-k does the right thing.
+ emacs, vi,
+ motif, KDE, gnome Key Bindings for Text Fields Make
+ sure that text fields can handle the vi and emacs key
+ bindings, so that e.g. emacs-style ctrl-a,
+ ctrl-k does the right thing.
-
-
+
+
- Books, Accounting Periods
-
-
- Ability to close the book at end of the fiscal year.
- This consists of several steps:
-
-
- - 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.
-
- Transfer the Income minus Expense for the book period
- 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 reporting infrastructure ...
-
- A user should be allowed to 'delete' an account *only*
- if it has no transactions in the currently open book.
- Of course, its 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 ...
-
-
- Status:
-
- - A mini-design doc exists in src/engine/future.txt
-
-
+ Ability to close the book at end of the fiscal year. This
+ consists of several steps:
+
+ - 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.
+
+ - Transfer the Income minus Expense for the book period
+ 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 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 ...
+
+
+
+
+
+
+ Status:
+
+
+ - A mini-design doc exists in
+ src/engine/future.txt
+
+
+
-
- - Check Printing
-
+
+
+ - Check Printing
+
+ -
+ Create a check-printing ability.
+
+
Status:
- - Create a check-printing ability.
-
Status:
- - Bill Gribble has built a prototype based on the
- gnome-print. Waiting for gnome-print to mature ...
+
- Bill Gribble has built a prototype based on the
+ gnome-print. Waiting for gnome-print to mature ...
-
+
+
- User Preferences
-
Create menu system and file format for manipulating user
- preferences.
- Preferences include things like default currency,
- register layout and colors, etc.
-
- What are some of the comptitive preference-handling
- technologies? Lets get some URL's here ...
- Following the unix tradition, there is no global
- prefernces registery.
- Note that session management and preferences are related things
- ... sort-of. Right now, we don't treat themn 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
- afterwords. This includes: which register windows
- were left open, what sizes they were, what thier
- placements on the screen were, etc. I beleive session
- management needs to be coordinated with KDE and with
- gnome, and all compliant window maangers will do the rest (?)
-
-
- Independently of session management, the register windows should
- remember how big they were last time they were poped up, and
- they should pop up the same size, again. The app should
- remember these sizes from invocation to invocation.
-
-
+ preferences. Preferences include things like default
+ currency, register layout and colors, etc.
+
+ What are some of the comptitive preference-handling
+ technologies? Lets get some URL's here ... Following the
+ unix tradition, there is no global prefernces registery.
+ Note that session management and preferences are related
+ things ... sort-of. Right now, we don't treat themn 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
+ afterwords. This includes: which register windows were left
+ open, what sizes they were, what thier placements on the
+ screen were, etc. I beleive session management needs to be
+ coordinated with KDE and with gnome, and all compliant
+ window maangers will do the rest (?)
+
+ Independently of session management, the register
+ windows should remember how big they were last time they
+ were poped up, and they should pop up the same size, again.
+ The app should remember these sizes from invocation to
+ invocation.
+
+ Status:
- Status:
- - Works good; lots of preferences in the gui.
- Implemented in home-grown scheme.
+
- Works good; lots of preferences in the gui.
+ Implemented in home-grown scheme.
+
- 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 ...
-
+
+
- Extension Language Support
@@ -1139,81 +1110,79 @@ we've been, and where we're going.
created so that additional extensions may be added in a
straightforward manner.
- The overall architecture is envisioned thus:
+ 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
+
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
+
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 highly desirable to be able to, in
- some manner, import new modules without requiring
+ stages, it is highly desirable to be able to, in
+ some manner, import new modules without requiring
that the application itself be recompiled and relinked.
- Status:
+
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.
-
-
+
+
-
+
+
- 401(k), RSP
-
-
401K, 403, IRA, Roth IRA, SEP, Keogh ... "Retirement Savigs
- Plans"
-
- 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??)
-
+ Plans"
+
+ 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??)
- Annotate with News Stories
-
- 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.
-
-
+ 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.
- - Loan and Mortgage Calculators
+ - Loan and Mortgage
+ Calculators
-
Provide a variety of simple GUI utilities to allow user to
calculate the future value of loans, mortgage payments,
interest payments, etc.
-
Status:
+
Status:
-
-
+
+
- Overdraft Alerts
@@ -1221,37 +1190,51 @@ we've been, and where we're going.
-
Overdraft alerts are popups 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 implenmented for price highs
- & lows. Note that these alerts do *not* require any sort of
- calendering or recurring transaction support.
-
- Design requirements: implement multiple (not just two) alerts
- for any account type. Alert should consist of (1) value point
- or price point, (2) movement direction (3) 'is active' boolean
- flag (i.e. Should be possible to 'turn off alert' without
- deleting it) (4) memo text.
-
- Status:
+ 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
+ implenmented for price highs & lows. Note that these
+ alerts do not require any sort of calendaring or
+ recurring transaction support.
+
+
Design requirements: implement multiple (not just two)
+ alerts for any account type. Alert should consist of
+
+
+ - value point or price point
+
+ - movement direction
+
+ - 'is active' boolean flag (i.e. Should be
+ possible to 'turn off alert' without deleting it)
+
+ - memo text
+
+
+
+
+
+ Status:
-
-
+
+
- -
- Recurring Transactions, Calander Alerts
+ - Recurring Transactions, Calander
+ Alerts
-
Add support for automatic, recurring transactions,
e.g. mortgage payments, fixed-interest bonds, regular
- salary checks, regular gas/phone/electric bills, etc.
-
- Loans & mortgages are one of the more complicated recurring
- transactions. Consider the following dialogue layout:
+ salary checks, regular gas/phone/electric bills,
+ etc.
+
+
Loans & mortgages are one of the more complicated
+ recurring transactions. Consider the following dialogue
+ layout:
loan amount $_____________ currency _________ (pull-down menu)
Remaining balance $___________
@@ -1267,69 +1250,73 @@ payee ____________
pay-from account __________________
next due date mm/dd/yy
- Note that in the above, not all fields are independent:
- some can be calculated from others.
- The other payment should bring up a mini-register,
- allowing user to add any number of splits.
-
-
- Recurring bills, salary income, etc. are simpler to handle,
- since they don't have intersest rates, balloons, etc. They
- do/will have multiple splits (e.g. payroll gross, fica, futa,
- income taxes, payroll net).
-
-
- Provide a calender-display of upcoming & past scheduled
- payments. Clicking on a calander day should raise up
- editable list of transactions. Calendering 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. Memoes should be possible.
- Popups should happen when dates get close. Technology:
- need to find/evaluate gnome-calender/dayplanner for
- integration.
-
-
- 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 (!?)
-
- Design Notes:
- Most alerts & data storage should be driven out of the engine.
- This will enable multi-user, distributed use.
- Note: 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 calander events might be server-ified.
- (On the other hand, a good calander should be server-ified,
- and thus viewable by secretaries, co-orkers, etc.)
-
- More complex financial instrucments may need a guile-based
- extension mechanism to compute values .... simple
- interest/mortgage calculators should be done in C in
- the engine ... (e.g. depreciation schedules ... under us tax
- law, a variety of different schedules are allowed ... )
-
May need interfaces to email for emailed alerts.
- Plot forcast graphs based on scheduled income & payments ...
- is this tied into budgeting ????
-
Status:
+ Note that in the above, not all fields are independent:
+ some can be calculated from others. The other
+ payment should bring up a mini-register, allowing user
+ to add any number of splits.
+
+
+
+
Recurring bills, salary income, etc. are simpler to
+ handle, since they don't have intersest rates, balloons,
+ etc. They do/will have multiple splits (e.g.
+ payroll gross, fica, futa, income taxes, payroll net).
+
+ Provide a calender-display of upcoming & past
+ scheduled payments. Clicking on a calander day should raise
+ up editable list of transactions. Calendering 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. Memoes should be
+ possible. Popups should happen when dates get close.
+ Technology: need to find/evaluate gnome-calender/dayplanner
+ for integration.
+
+ 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 (!?)
+
+ Design Notes: Most alerts & data storage
+ should be driven out of the engine. This will enable
+ multi-user, distributed use. Note: 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 calander
+ events might be server-ified. (On the other hand, a good
+ calander should be server-ified, and thus viewable by
+ secretaries, co-orkers, etc.)
+
+ More complex financial instrucments may need a
+ guile-based extension mechanism to compute values ....
+ simple interest/mortgage calculators should be done in C in
+ the engine ... (e.g. depreciation schedules ...
+ under us tax law, a variety of different schedules are
+ allowed ... )
+
+ May need interfaces to email for emailed alerts.
+
+ Plot forcast graphs based on scheduled income &
+ payments ... is this tied into budgeting ????
+
+ Status:
- Need to create design doc, need to implement engine
- pieces, need to hunt down gnome-calandering bonobo.
+ pieces, need to hunt down gnome-calendering bonobo.
-
-
+
+
- Budgeting
-
- Ability to create a budget (i.e. estimates of future
- expenditures). Reconcile actual expenditures against future
- expenditures. Create simple, step-by-step 'financial plan'
- budgeting GUI's:
+ Ability to create a budget (i.e. - estimates of
+ future expenditures). Reconcile actual expenditures against
+ future expenditures. Create simple, step-by-step 'financial
+ plan' budgeting GUI's:
- Home purchase planner
@@ -1347,79 +1334,119 @@ next due date mm/dd/yy
Create a summary budget/track-record budget report that a
professional financial planner/advisor could use.
- Note that the above 'step-by-step' budgeters will have
- a very very different GUI than what the budgeting system
+
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.
- Status:
+
Status:
+
- A design doc has been submitted by Bob Drzyzgula.
Take a look at ./src/budget.txt in the source
directory.
- - Bryan Larsen has begun work .. its scheme based ...
- Dave Peticolas has some gui roughed out ...
-
-
+ - Bryan Larsen has begun work .. it's scheme based ...
+ Dave Peticolas has some gui roughed out ...
+
+
+
- Quicken(TM) Import
-
- Ability to import Quicken QIF files. Both MSMoney and Quicken
- use QIF files to export data.
-
Status:
-
- - Quicken import is implemented and mostly works.
- 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.
- Note that since banks use QIF, the *correct* way to
- reconcile bank accounts on-line is through QIF.
- On one side, we have existing recorded transactions;
- on the other, the latest bank statement, in QIF format.
- Now, just put them together ...
-
-
+ Ability to import Quicken QIF files. Both MSMoney and
+ Quicken use QIF files to export data.
+ Status:
+
+
+ - Quicken import is implemented and mostly works. 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.
+
+
Note that since banks use QIF, the correct
+ way to reconcile bank accounts on-line is through
+ QIF.
+
+ On one side, we have existing recorded transactions;
+ on the other, the latest bank statement, in QIF
+ format.
+
+ Now, just put them together ...
+
+
+
+
- Quicken(TM) Export
-
Ability to export Quicken QIF files.
-
- Several design alternatives are available: 1) a special
- 'report' that writes out qif could be created. This would use
- the 'reports' infrastructure to generate qif's. 2) Its fairly
- easy to traverse the data in the engine to write out qif files.
- Just do it.
-
-
- Status: not started
-
+
+ Several design alternatives are apparent:
+
+
+
+
+
+
+ Status: not started
- - Stock Quotes, Price Quotes
+ - Stock Quotes, Price
+ Quotes
-
- Add ability to download stock quotes, other price quotes.
- Add ability to download historical prices as well. (e.g.
- get 5-year history of mutual fund performance vs. djia).
-
- Right now, stock prices are stored with everything else,
- in the main database, in the transaction table. This leads
- to several aesthetic quandries. It bulks up the database
- with 'less-than critical' information. Basically, transactions
- are either 'critical' vix record the movement of money, or
- are non-critical viz record things retreivable from the
- historical record, e.g. prices. Shouldn't storage for
- prices be moved to somewhere else? Hmmm ... what about
- storage for valatility, shares traded, etc? Does indeed sound
- like an alternate storage method would be useful. What about GUI
- implications?
+ Add ability to download stock quotes, other price quotes.
-
Status:
+
Add ability to download historical prices as well.
+ (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 quandries.
+
+
+ - It bulks up the database with 'less-than critical'
+ information.
+
+ - Basically, transactions are either 'critical' vix
+ record the movement of money, or are non-critical viz
+ record things retreivable from the historical record,
+ e.g. prices.
+
+ - Shouldn't storage for prices be moved to somewhere
+ else?
+
+ - Hmmm ... what about storage for valatility, shares
+ traded, etc?
+
+ - Does indeed sound like an alternate storage method
+ would be useful.
+
+ - What about GUI implications?
+
+
+ Status:
- Can obtain stock quotes from Yahoo (NYSE), Fidelity
@@ -1430,32 +1457,29 @@ next due date mm/dd/yy
src/quotes/gnc-price for details.
- Quote.pm is now a separate development project at
- source-forge.
-
-
- Need to integrate with GUI.
- Right now, this is a stand-alone perl script run
- from crontab. This will be done by writing
- scheme wrappers for the module (???)
-
-
-
+ source-forge.
+ - Need to integrate with GUI. Right now, this is a
+ stand-alone perl script run from crontab. This
+ will be done by writing scheme wrappers for the module
+ (???)
+
+
+
- Technical Stock Analysis
- -
- Provide technical sotck analysis graphs, e.g. volume, 90 moving
- avg, beta, etc. See gstalker for example of how to do it ...
-
-
-
+ - Provide technical sotck analysis graphs, e.g.
+ volume, 90 moving avg, beta, etc. See gstalker for example of
+ how to do it ...
- - Depreciation, Sinking Funds
- -
- Hmm ... some variation on the concept of loans? Need to support
- different deprciation schedules (see IRS books for that).
-
+ - Depreciation, Sinking
+ Funds
+
+ - Hmm ... some variation on the concept of loans? Need to
+ support different deprciation schedules (see IRS books for
+ that).
- OFX support
@@ -1465,18 +1489,17 @@ next due date mm/dd/yy
providing, to retail customers. See below for OFX
references.
- OFX is an open spec from Microsoft, Intuit, and
+ 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 OFX Home Page for
- details.
+ details.
- 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.
+ 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.
- The parser is fragile because minor DTD
@@ -1491,82 +1514,84 @@ next due date mm/dd/yy
commonly-used approach; there are a variety of XML tools
available that provide this function.
-
Run-time parsing may be slower, but on the OFX client
+
Run-time parsing may be slower, but on the OFX client
side, this should not be a bottleneck.
- Status:
+
Status:
- A compile-time parser was developed and
abandoned.
-
+
+
+
- Note that the organizations developing OFX are looking
+
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.
+ for UNIX.
- Other on-line support
-
->> 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 tranfers
->> 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.
-
+>> 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 tranfers
+>> 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.
-
+
- Multiple Currencies
-
- Need to support multiple currencies. Work is needed in the
- GUI. The engine currently supports multiple
- currencies by treating them as securities, and thus
- allowing currency trading. The currency-trading register
- needs a complete overhaul. (Its obtuse and unintuitive).
-
- A simplfied way of dealing with one-shot currency exahnges needs
- to be implemented. basically, just a simple calculator popup.
+ 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.
+
+ A simplfied way of dealing with one-shot currency
+ exchanges needs to be implemented, essentially just a
+ simple calculator popup.
-
- Forced Double-Entry
-
@@ -1574,46 +1599,50 @@ next due date mm/dd/yy
indicates a pair of accounts: one is debited, and one is
credited.
-
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 can create dangling transactions, where only
- one account is indicated.
+ 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 can
+ create dangling transactions, where only one account is
+ indicated.
- Although this is acceptable for home use (even
+
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.
+ 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.)
- It must be possible to enable forced-double entry, so
- that a transaction cannot be completed until two accounts
- have been specified.
+ It must be possible to enforce double entry, so that a
+ transaction cannot be completed until two accounts have
+ been specified.
- Restricted Double
- 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.
+
Restricted Double 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.
- Current status:
+
Current status:
- 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, there is no way
- to change them from the GUI.
+ 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.
- Dec 1998 -- Scrubber functions implemented to crawl
through data, and find all unbalanced or orphaned
transactions.
- May 2000 -- Default will be changed to double-entry
- always. It will not be possible to disable single-entry.
+ always. It will not be possible to disable this and move
+ to single-entry.
-
-
+
+
- - Tab-delimited ASCII file format
+ - Tab-delimited ASCII file
+ format
-
People like to be able to read file contents in
@@ -1623,15 +1652,15 @@ next due date mm/dd/yy
printf()s.
The tab-delimited format should be compatible with that
- of /rdb, aka RAND/Hobbs /rdb or
- /rdb, aka RAND/Hobbs /rdb or
+
- NoSQL. (NoSQL is available as part of the Debian GNU/Linux distribution,
+ NoSQL. (NoSQL is available as part of the Debian GNU/Linux distribution,
for instance.)
- The /rdb format is thus:
+ The /rdb format is thus:
field-name tab fieldname tab fieldname \n
------------------------------------------ \n
@@ -1672,18 +1701,17 @@ etc ...
organizers
- There are Quicken-workalikes that run on the
- PalmComputing platform; it would be good to inter-operate with
- this.
+ PalmComputing platform; it would be good to inter-operate
+ with this.
- - Emergency Records Organizer
+ - Emergency Records
+ Organizer
- -
- Put together a single-page report showing critical info
- about accounts, etc.
+
- Put together a single-page report showing critical info
+ about accounts, etc.
-
-
- - Enriched Engine, Financial Objects
+ - Enriched Engine, Financial
+ Objects
-
The current system makes a distinction between the data
@@ -1694,8 +1722,8 @@ etc ...
cache between the permanent data repository (file, sql db)
and the GUI.
-
The current engine is rather simple: it provides
- support for accounts, account hierarchies and transactions
+
The current engine is rather simple: it provides support
+ for accounts, account hierarchies and transactions
consisting of multiple entries.
Many of the features described elsewhere will require
@@ -1703,7 +1731,7 @@ etc ...
model, including such things as:
- - Linking to "Address Info" ( e.g. names,
+
- Linking to "Address Info" ( e.g. names,
addresses)
- Transaction identifiers
@@ -1715,8 +1743,8 @@ etc ...
- Budget policy
- Note: it makes no sense at this point to make the
- engine API much richer than what the GUI can currently
+
Note: it makes no sense at this point to make the engine
+ API much richer than what the GUI can currently
support.
@@ -1724,23 +1752,23 @@ etc ...
parent transaction has been marked as cleared, the record
should be locked, so that further modifications to the
amount can't be performed (or at least, a warning is
- generated. This prevents accidental garbaging up of old
- transactions.)
+ 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
+
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 downright
+ very tightly controlled, or even outright
forbidden.
- Current Status:
+ Current Status:
- The basic engine has been detangled from the GUI
@@ -1749,9 +1777,9 @@ etc ...
- 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."
+ - 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.
@@ -1760,7 +1788,7 @@ etc ...
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.
@@ -1773,7 +1801,6 @@ etc ...
- Linas <linas@linas.org> is maintaining the
engine code.
-
- SQL I/O
@@ -1782,19 +1809,21 @@ etc ...
A module is necessary to allow data to be fetched from an
SQL database, and for that database to be updated.
- There has been much discussion about this on
- mailing lists both for GnuCash and CBB. Major
- points have included:
+ There has been much discussion about this on
+ mailing lists both for GnuCash and CBB. Major points
+ have included:
-
Those SQL databases available on Linux tend to involve
- considerable administrative overhead in terms
+ considerable administrative overhead in terms
of getting them set up.
- This may be a minor cost to a business enterprise
- that hires DataBase Administrators.
- It is not acceptable to require this of
+
+
This may be a minor cost to a business enterprise
+ that routinely hires DataBase Administrators.
+
+ It is not acceptable to require this of
naive users that may find "simple" things like
% su -
@@ -1806,64 +1835,100 @@ Password:
to be challenging.
- - It might be useful to use an embedded
- database engine like unto Sleepycat DB, cdb, or
- something like
- ISAM (Note CQL++ supports ISAM access methds),
- or even an embedded SQL engine such as
- GigaBASE.
- The point of doing so would be to to provide a uniform,
- more-easily-extensible, more portable interface to the data.
+
-
+ It might be useful to use an embedded database engine
+ like unto Sleepycat
+ DB, cdb, or
+ something like
+ ISAM (Note CQL++ supports ISAM access methds), or
+ even an embedded SQL engine such as
+ GigaBASE.
+
+
The reasons to do so include:
+
+
-
GnuCash presently uses a document-oriented model, where
the entire 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 at least partly implemented
- with the Begin()/End() constructs in the engine.
-
- 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, the edit could
- be rejected en-masse, allowing the user to merge and
- correct their changes. This is a very important note:
- updating SQL does NOT require locks to be held for long
- periods of time!
-
-
-The SQL engine chosen should be fully transactional, passing the 'ACID'
-test (Atomicity, Consistency, Isolation, Durability).
-Note that MySQL
-doesn't pass the 'ACID' test.
-
+
GnuCash needs to be modified to access the database
+ in a transactional manner. This is at least partly
+ implemented with the Begin()/End() constructs
+ in the engine.
+ 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 not
+ require locks to be held for extended periods of
+ time!
+
+
+ -
+ The SQL engine chosen should be fully transactional,
+ passing the 'ACID' test (Atomicity, Consistency,
+ Isolation, Durability).
+
+
Note that MySQL does not
+ satisfy the 'ACID' criteria.
- - Multi-user Support
+ - Multi-user Support
-
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
- with a web interface, possibly using the register object as
- a browser plugin.
+ the engine.
-
The following industrial-strength features are
+
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
+ plugin.
+
+ The following industrial-strength features are
needed:
@@ -1879,7 +1944,6 @@ doesn't pass the 'ACID' test.
- encryption of network connections
-
- Accounts Payable,
@@ -1891,11 +1955,11 @@ doesn't pass the 'ACID' test.
- Payroll
-
- Payroll introduces a sizable amount of complexity
+ Payroll introduces a sizable 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,
+
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.
@@ -1903,12 +1967,9 @@ doesn't pass the 'ACID' test.
- Invoicing
- - Invoicing. To design an invoice, need to have a
- mini-word-processor/simple drawing plug-in.
- Is Abisource/Abiword a candidate? Probably needs bonobo...
-
-
-
+ - Invoicing. To design an invoice, need to have a
+ mini-word-processor/simple drawing plug-in. Is
+ Abisource/Abiword a candidate? Probably needs bonobo...
- Job Costing
@@ -1932,9 +1993,11 @@ doesn't pass the 'ACID' test.
GnuCash is a program to keep track of your finances. Its
+
GnuCash is a program to keep track of your finances. Its
features include:
GnuCash offers some features not found in simpler
- accounting programs.
+ GnuCash offers some features not found in simpler accounting
+ programs.
The versioning scheme for GnuCash parallels that of the
Linux kernel, where "even" sub-versions indicate versions that
are intended to be stable, only seeing maintenance to fix bugs,
and "odd" sub-versions indicate an "experimental" stream that
seeks to add enhancement.
- The present "experimental" stream is gnucash-1.3.x, which
- is somewhat unstable.
+ The present "experimental" stream is gnucash-1.3.x, which is
+ somewhat unstable.
- The latest stable release is 1.2.x; if you don't intend to
do development work, you should be using either this version,
or an older 1.0.x version. These versions are fairly stable,
with all currently known bugs fixed.
- Once the 1.3.x series stabilizes, the next stable series
will be 1.4.x, and experimentation will likely continue on
1.5.x.
- If you wish to "hack" on the experimental version, you
should first start by reading through the GnuCash Project Goals document in order to
+ "projects.html">GnuCash Project Goals document in order to
get some perspective on the overall design.