While I have some minor issues with the screenshots shown, this definitely is a step in the right direction. The workbench idea, or the concept of a separate "view" for budgetary purposes is essential. One of the things that makes GNUCash essential is the simplistic "T-account" view provided by the actual accounts. This has to remain and tampering with that in anything but the most trivial ways would be a mistake. Additional features with either the corporation or the individual in mind must make use of extra views.
As for the concept of "categories". This does not exist. The actual data has accounts. The budget should have accounts. They do not have to be the same and an account in the budget could be a combination of one or more of the real accounts. For the example regarding groceries. Utilization of a correct accounting system would generate an Expense account "Grocery Expense". On a fictitious budget, an expense account of "Food" may exist and become a combination of Grocery Expense and Dining Expense with both accounts' inflation going against the hypothetical expenditure for a given period of time. However, I would offer actual/plan comparisons as opposed to some sort of balance view in the workbench. This overly confuses the matter as to what is a good or bad number to see in all instances. Also, in the related category view (related accounts by my definition), only accounts of the same type should be available and that should have to be specified (since you make the income/expense delineation in a later view this is necessary here). There are other issues, but those may or may not flesh themselves out. Stephen Cuppett _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
