budgeting

[Josh Sled]

On Sat, Jun 30, 2001 at 10:28:48PM -0600, Larry Hunter wrote:

| I'm new to gnucash, and wanted to know who was currently working on
| budgeting.  

No one, at present.

I started with the intent of working on budgeting [back in Jan], but
decided to get Scheduled Transactions out of the way first, as I believe
budgeting will make use of it.

| Is there any code out there?  I tried browsing the CVS tree,
| and found some design docs, but no code.  

There are further design notes/discussions in the mlist archives [~Nov/Dec
are good places to look], and I have some notes both in my head and on
paper locally which I intend to get to the list when I get a free moment
[maybe between compiles today].

One of the problems with jumping into coding at this point is that some
[read: nearly all :)] of the design/focus is still to be done.  I have
some thoughts revolving around Budgeting Categories [not necessarily 1-to-1
with Expense categories], Budgeting Entries [something like Transactions],
how these can be viewed, and how they interelate.

But many of the puzzle pieces aren't even stamped out into the correct
shapes, let alone pieced together to form the puzzle [how's that for
analogy? :)]...

Maybe the best thing to get this started is your input on how you have
done budgeting [spreadsheet/paper/program-based], and how you _want_
to do budgeting.

| Although I don't have a lot of time for hacking, I am a reasonably
| experienced scheme programmer, and am strongly motivated to help get at
| least some basic budgeting functionality up and running soon.  Is there
| anything I can do to help the project along?  Who should I talk with? 

This list is the best place to talk to for now.  While I've been intending
to do budgeting stuff for a while, I have very little time for hacking
myself... so if you have time now, go for it.

I haven't been intending that the budgeting stuff would be primarily
or significantly in scheme, but I figure that bits of it will be.
But ultimately she who codes, decides.

One thing that I was thinking would be appropriate in scheme, and that
both scheduled transactions and budgeting would be able to make use of
is a historical transaction analyzer...

The Analyzer would process historical transaction data with the goal of
determining correlated transaction [basically those which recurr], and
with what a) frequency and b) parameters.  Parameters are generally the
splits, broken down into b.1.) descriptions, b.2) accounts and b.3) amounts.
The output would be something like:

Transaction:
  approximately every 1 month on the 15th {0.13:14th, 0.75:15th, 0.12:16th}
  Split 1: {0.7:"PG&E", 0.3:"Pacific Gas & Electric"}
           "Assets:...:Checking"
           -$120 +/- $27
  Split 2: {0.82:"Utilities", 0.11: "Utils", 0.07: "Power"}
           "Expenses:...:Gas&Eletric"
           $120 +/- $27

This is only a semi-defined problem as presented here, so let's frame it
a bit more by examples:

1. The user right-clicks on a transaction and says "Schedule/Recurr".
   If there are any transactions sufficiently similar [as determined by
   the Analyzer, perhaps via some iteratively-depened similarity-metric
   thresholding], then those become input to a first cut at the template
   transaction and recurrance frequency, which will hopefully save the
   user a large amount of time in setting up recurring transactions,
   especially for people who have already done the data entry.

2. The user has entered/imported a bunch of financial data, and wants to
   start using the imaginary-so-it's-necessarily-super-cool [:)] budgeting
   workbench... there's no reason why they should have to enter anything
   substantial; the program should generate a good first-approximation
   of their scheduled transactions; note that the window of "scheduled"
   in the budgeting case can even be yearly, as in a savings goal to
   have enough funds with which to buy christmas gifts available in
   approximately November... or a "yearly" vacation.


Another thing I was thinking would be appropriate for scheme
is a constraint-satisfaction problem solver, as I think budgeting
projections/decisions can be framed as a CSP, and then solved... but this
is kinda blue-sky thinking ATM, so I just put it out as such for now. :)

...jsled