The people behind GnuCash 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 surrounding this project. It is a kind of an FAQ for developers and contributors, providing status, and suggesting directions and technologies for deploying new features. If you simply want to get a better idea of what GnuCash is and what it does, visit its home page. The home page contains screen shots, news items, and mailing list archives.
There are currently several different versions of GnuCash. We've adopted the kernel numbering scheme: even minor relase numbers (1.2.x, 1.4.x) are considered to mark stable releases, while odd numbers (1.3.x) mark development releases.
The latest Gnome version, and latest versions in general, are currently 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 begining users should probably stick to version gnucash-1.2.5: although this version is quite old and lacking in many features, it is known to work. More adventurous users can try one of the 1.3.x releases: these days, they are pretty stable, and work pretty well. However, we cannot gaurentee that they are flawless. We've tried to make sure that no matter how broken these get, they won't mangle your data, but we can't make promises.
This document is divided into several sections.
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 from several users. Amongst these terms, the concept of a global Model-View is dated, and somewhat inappropriate. Rather, we need to be concerned about how data is represented in the local address space of the GUI, how the GUI manipulates it, how data is brought in and merged from external sources, and how that data is again output, whether to a file or a local or remote database.
Thus, the View essentially represents a local data cache of the data that is immediately present and being displayed, reported, and manipulated. The Model is the abstraction of that data that the GUI (the controller) can act on.
Currently, the Engine is fairly poor, and is tightly tied to the data structures that the GUI manipulates. These data structures include:
The Engine currently handles only a small set of data sources:
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.
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 IBM San Francisco business objects, or closer to home, Linux Kontor. 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.
The above structure should leads us to view GnuCash not so much as a tightly integrated application, but rather as a loose confederation of component objects, libraries and interfaces. 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 Scheme extension language (as implemented in the FSF Guile interpreter), to glue the pieces together. (Note that the engine interface is also available with Perl interfaces, thanks to a SWIG wrapper.
Important properties of a personal finance system include:
A seemingly contradictory factor is that the kinds of sophistication that are required vary considerably. Consider:
It may be that these will require completely different systems, and that GnuCash cannot be "all things to all people." This remains to be seen.
The right hand column shows a sizing guesstimate. pm == person-months. These sizings are meant to show 'effort needed to complete', rather than 'total effort required'. Thus, half-finished items have smaller sizings.
Feature | Sizing | Responsible |
---|---|---|
Enhanced Engine, Financial Objects | Large | ? |
SQL I/O | Medium | Linas |
Multi-User Support | Medium | ? |
A/R, A/P Accounts Payable, Receivable | Medium | ? |
Payroll | Medium | ? |
Invoicing | Medium | ? |
Job Costing | Medium | ? |
Expense Accounts | Large | ? |
Current status:
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 configurable interface, so that people can build custom reports. The New Reporting Infrastructure is seeking to build this up using Guile.
Generated reports should be exportable to other gnome systems using bonobo. 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 report, Market Index report, Stock Option values, Estimation of capital gains tax liabilities.
Reports should be printable to printer.
Status:
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.
Status:
Multi-Line splits look confusing when viewed from Income/Expense Accounts. Stock splits & reverse splits are not displayed correctly. Currency trading Ledger is confusing.
Stocks and Mutual funds are handled by placing them each in their own account. Each account can be viewed individually. If all of the stock accounts are children of a master trading account, then the trading account can be viewed and modified in a General Ledger window. The current stock general ledger window is a bit obtuse, and difficult to understand and use. A simplified but still powerful ledger window is desperately needed.
How to most simply allow the user to enter loads and fees? Through multi-line transactions. Unfortunately, some users may not properly understand multi-line transactions, 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 journal entries.
Note the current transfer window does NOT allow a share price to be specified !! Needs fixing ...
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 ... Status: Dave volunteers...
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.
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.
Cut-n-paste Cut-n-paste of whole transactions in the regsiter window... Status:Dave... Done. (in 1.4.0)
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.
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.
Register View Allow user to view only non-reconciled transactions ...
Autocompletion Quickfill should also auto-complete amount, memo fields.
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.
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.
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. ???
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.
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.
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.
File Format. Rework miscellaneous file storage to use Sleepy Cat DB. Status: RLB, 2 weeks.
Reconcile Window. Auto-pay credit card when reconciling credit card accounts (Done, Dave). Auto-add bank fee when reconciling bank accounts. (Not done, Dave).
Print Register Window. Output register window to printer. Status: defer indefinitely.
Reconcile groups.
# of decimal places in prices (penny stock). Part of the big numeric overhaul.
gtkhtml. Move to gtkhtml from gtkxmhtml. Done in 1.5, Grib.
print. Print reports, etc. Done in 1.5, Grib. This came 'for free' with gtkhtml.
key-val pairs. Add generic key-slot mechanism into accounts, transactions, journal-entries. Done in 1.5.0, Grib.
guid in fileio. No longer relevent with new file format. Dave.
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:
Status:
New User Setup 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.
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:
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 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 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 that the application itself be recompiled and relinked.
Status:
(2) 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).
(3)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 (!?)
(4)Loans & mortgages are one of the more complicated recurring transactions. Typically, there might be a years worth of smaller payments, then a long string of larger payments, followed by a baloon.
(5)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.
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 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:
Several design alternatives are apparent:
This would use the 'reports' infrastructure to generate qif's.
Status: not started
Right now, stock prices are stored along with everything else, in the main database, in the transaction table. This leads to several aesthetic quandries.
Status:
A simplfied way of dealing with one-shot currency exchanges needs to be implemented, essentially just a simple calculator popup. This might be handy for the occasional business traveler or tourist with some minor currency trades.
Implement the 'correct' way of handling this when user is working in multiple currencies on a regular basis.
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 generalized (and should be).
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 (arguably desirable, since it allows the casual user the simplicity 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 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.
Current status:
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??)
Provide a way of storing news stories with accounts, and possibly annotating individual transactions in the same way.
Consider the following dialogue layout:
loan amount $_____________ currency _________ (pull-down menu) Remaining balance $___________ Payment amount $___________ balloon payment $_____________ other payment $________ (e.g. escrow, tax) Payment frequency (weekly/monthly/bimonthly/quarterly/yearly) loan start date mm/dd/yy length -----(weeks/months/years/payments) loan time left (number of days/weeks/months, rounded) number of payments left interest rate %__________________ payee ____________ pay-from account __________________ next due date mm/dd/yyNote 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.
Status:
Design requirements: implement multiple (not just two) alerts for any account type. Alert should consist of
Status:
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.
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.
Run-time parsing may be slower, but on the OFX client side, this should not be a bottleneck.
Status:
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.
>> 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 tab-delimited format should be compatible with that of /rdb, aka RAND/Hobbs /rdb or NoSQL. (NoSQL is available as part of the Debian GNU/Linux distribution, for instance.)
The /rdb format is thus:
field-name tab fieldname tab fieldname \n ------------------------------------------ \n value tab value tab value \n value tab value tab value \n etc ...
It is a very simple, very basic flat table format. The use of /rdb with GnuCash should try to match with SQL schemas as much as possible in order to minimize I/O complexity and incompatibility.
categorize items according to different tax schedules
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 that the engine have a far richer, more sophisticated data model, including such things as:
Note: it makes no sense at this point to make the engine API much richer than what the GUI can currently support.
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:
These "Transaction processing constructs" should simplify creation of an SQL back end, or some other more sophisticated database engine.
There has been much discussion about this on mailing lists both for GnuCash and CBB. Major points have included:
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 - Password: # cd /tmp # rpm -i gnucash-4.1.3.i386.rpm # exitto be challenging.
The reasons to do so include:
This permits managing larger sets of transactions more efficiently.
Interoperability is generally considered a good thing...
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!
Note that MySQL does not satisfy the 'ACID' criteria.
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:
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.