Budgeting proposal

[Dave Fancella]

All quoted below for reference.  :)  Since I'm in agreement with most/all, and 
I dont' think I need further clarification on the fine points, I'd like to 
start talking actual code now.  Unless there are any objections...

So, basically what we're looking at, then, is a Budget object (sorry, saw the 
code is mostly in C and didn't think "class" like I usually do :) ).  The 
Budget object would look something like this:  (using struct for C)

struct Budget {
	Budget* parent;
	Account* linkedAccount;
	Allocated* allocList;
}

Assume any other pointers necessary for constructing the entire list.

Then a struct like this: (complete with non-existant data types and c++ style 
comments)

struct Allocated {
	float amount;
	date startDate;
	date Expires;
	float interval;  // interval/frequency/year
	float frequency;  // using floats for these, but int would work as well or 
better
	// include any pointers needed to construct the list
}

Then in the Account object, there would be a Budget* linkedBudget.  Generally, 
I prefer links to be two-way links, but I usually build linked lists to only 
go one way.  Lately I've been using STL for my list management, though, but 
it looks like there's no C++ in GNUCash anywhere.  If you guys have no 
objections, I'd really prefer to do it in C++, but I'll be happy to code in 
C, I'm just a bit rusty on C (like 13 years worth of rust).

I hesitate to get harder about definitions and stuff without being real 
familiar with gnucash's object model.

Two more things:

Another guy jumped in saying he had plenty of thought into this problem 
already, but wouldn't respond until the weekend.  Other than that, how much 
consensus is needed before this (or after modifications) can be accepted as 
the architecture that will be used?

Finally, Budgeting and Credit Limits are the most important things I need for 
GNUCash right now, and I'll be happy to work them up myself, within whatever 
time constraints I've got.  :)  Most importantly, I want them merged into the 
project's code because it's extremely impractical for me to maintain a 
separate version of my own, and it benefits everybody at large anyway.  So 
I'll conform to whatever language is needed, and whatever coding standards 
are needed, just keep in mind that going into this I don't know anything 
about existing project standards.  :)  (presumably, since it's called 
"GNU"cash, it uses GNU coding standards that I should probably go read about)

On a side note, in my own business my partner and I have decided to use 
GNUCash for our accounting for now, until we need something better or have to 
use a different platform.  IN the meantime, though, he's going to ssh with 
Cygwin and run GNUCash on my machine.  :)

Dave

On Thursday 17 April 2003 05:14 pm, Matthew Vanecek wrote:
> On Thu, 2003-04-17 at 14:04, Dave Fancella wrote:
> > On Thursday 17 April 2003 07:22 am, Matthew Vanecek wrote:
> > The more I think about it, the more I have to disagree with a budget
> > being a separate entity entirely.  If your budget isn't linked to an
> > account, or the account it gets linked to over time changes,
>
> I think I see where the miscommunication is occurring.  I don't mean
> that Accounts and BudgetCategories are *not* linked--quite the
> contrary.  It'd not be very useful to have an unlinked BudgetCategory,
> when you are generating reports, etc.  How would you measure your
> progress against the unlinked BudgetCategory?
>
> OTOH, if you creating a new Budget, it's possible you may not have
> created the associated Accounts yet.  Therefore, you'd need the ability
> to create BudgetCategories without linking.
>
> Admittedly, this ability can get you in trouble when dealing with
> reports, etc.  As with other things in Gnucash, and many other
> applications, it's up to the user to make sure all the links are set up
> correctly prior to running a report.
>
> However, it would be useful to have a report displaying unlinked
> BudgetCategories, and to also not them on budget reports.  The
> income/expense amount *on a report* should default to $0, with the entry
> marked as an unlinked BudgetCategory.  I feel that should alleviate your
> concerns in this area.
>
> > I'd prefer dates myself just because it would simplify a lot of the math.
> >  If it becomes necessary to change it, though, it shouldn't be that hard.
>
> Me, too.  Other methods could be implemented incrementally, as the
> system matures.
>
> > I've been thinking about credit limits, actually, and it seems like a
> > credit limit is similar, although not exactly, like projects.  You get a
> > certain amount of money for the life of the card (barring credit
> > increases, of course), but it's revolving.  Presumably in a project
> > budget there's no way to deposit money back into the project, or at least
> > it's not very common. With credit cards you will be depositing money into
> > the account whenever you pay your bill.  I don't know if they should be
> > linked, though, because although functionally similar, they are
> > conceptually different beasts entirely.
>
> Well, Budgets are primarily for tracking income/outcome.  Paying down a
> liability such as a credit card is surely an outcome. ;)  Tracking
> credit limits should be handled differently, if at all.  They are not
> strictly a budget consideration (although they can make for great
> juggling acts!!).
>
> > > Some people already do something similar to this, by having
> > > sub-accounts of their bank accounts, and splitting money into the
> > > sub-accounts.  When they pay the Electric bill, the transfer money from
> > > Assets:Bank:Electric to Expenses:Utilities:Electric.  It's a pretty
> > > nifty way to work around the lack of budgeting capabilities.  Instead
> > > of anticipation, you have current balance.
> >
> > Is this an "industry standard" way of doing it?  The real problem I'm
> > seeing with that, though, is that you'd have to transfer money from your
> > bank account to your Assets:Bank:Electric, and your bank register
> > wouldn't show the real amount.
>
> No, definitely not.  It's just a handy way someone on the list came up
> with.  And yes, you have to transfer money from the parent Bank to the
> subaccounts (although you could do it all in one transaction with many
> splits).
>
> > My auto budget is fairly straightforward.  There's insurance ( $0 ), gas
> > (split for 3 cars right now), and service ($50).  It's the last one that
> > gets you, though.  If you every have to do any real work on a car, you'll
> > be damned lucky if you can pay less than $50.  So the idea is that every
> > month, the $50 is spent.  Every year or so when we actually have a major
> > expense on fixing a car, the money would be there because it built up
> > every month.  Of course, I suppost just transferring the remaining
> > balance in the service budget to a separate service account for
> > safekeeping would do the same thing...  Um, never mind?  (As you said,
> > why didn't I think of it before?)
>
> What you're describing above is a basic tenet of budgeting.  Annual
> expenditures should be divided up as you do above with your service.
> Makes it easier to pay the homeowners insurance next year if you expense
> it every month, and track it accordingly on the budget.
>
> > So the accountant just says "how much did we spend?", gets the number and
> > looks at some scrap of paper his manager gave him and does the math in
> > his head?  :)  Ok, it's probably a bit more involved than that....  but I
> > see what you're saying.
>
> Well, it's computerized, and yes, a bit more involved and subject to
> higher authority, etc.  But, basically, yes.  Of course, there's
> accountability built in for budget overruns--iron maidens, bamboo shoots
> under finger nails, etc.
>
> > I've sorta got an idea here...  does GNUCash have any plugin API or
> > anything? I'm wondering, if it did, then I could make a budget plugin
> > rather than budgeting as an integral part of the application.  That would
> > leave room not just for other implementations, but it would also make
> > something that would allow for a lot of other things, such as plugging
> > into a CRM or something.
>
> It's got a modular API.  You can create a Budget module, and it could
> get loaded and used at runtime.
>
> > Anyway, to continue.  :)
> >
> > If Budgets are a separate entity, then a way is needed to store the
> > amount of the budget, the length of the budget, mmmm, and I think that's
> > it.  (the tree structure is assumed to be part of the architecture no
> > matter what :) ).
>
> All that is stored within the Budget Object.  Think object-oriented--it
> gets easier to conceptualize.
>
> It's really analogous to an AccountGroup--a Budget is a group of
> BudgetCategories.  The bottom line is calculated as a sum of the
> categories -- one for income, and one for outgo (you have two types of
> categories--"money in" and "money out", at its simplest).
>
> > Next we need a way to do math with the budget and accounts. 
> > Traditionally, in financial apps anyway, this is done by linking every
> > single transaction with a budgetted category, and in some applications
> > (can we say Quicken? :) ) it gives the illusion of being double-entry.
>
> I'd rather see the Accounts linked to a budget category.  That way, for
> the from/to dates of the budget, you could total up all the Splits in
> that Account that fall within the from/to dates.
>
> Gnucash truly is double-entry. ;)
>
> > Now, from a UI point of view, I think it would be confusing (and I
> > *really* don't want to have to explain this to my wife) if you have to
> > chose both an account (that might look like a category) and a budgeted
> > category for every transaction.
>
> You don't do this on a per-transaction basis.  You do it on a
> per-Account basis, and you do it once.  The point of the budget is not
> to track every single transaction/split.  Rather, you want to see
> account totals vs. budgetted amount, where the account totals are for
> the budget lifetime.  These totals are calculated dynamically in the
> budget compliance report.
>
> Since every transaction must have a source and at least one destination
> account, it all works out.
>
> >   Now, I do have a tendency to put the category in the Payee
> > field, but some people really do care about having the Payee field
> > reflect reality, where I don't, and I even have some blank ones.  So,
> > ideally, a way should be found that makes the difference between a budget
> > and an account seamless to the user.  As far as I'm concerned, I'll be
> > happy just putting a budgeted amount on each expense/income account, and
> > leaving the other accounts alone with budget.
>
> You're thinking of a budget as something you do on a per-transaction
> basis, which you really don't want to do.  That'd be *way* too much
> work!  A budget is something you create once.  On a regular basis, you
> compare you money flow to the budget to see how you stand.  It should be
> as simple as selecting the report from the reports menu.  Since every
> transaction has a source and a destination split, you never have to do
> anything special with the transaction or splits.  You just run a report
> once in a while.
>
> If your UI is set up like you want, with the columns, then you also get
> the real-time comparison in the Account tree.
>
> > Is there a specific situation(s) that would require the budget and
> > accounts to be kept separate entities?  Would it be reasonable for the
> > sake of a practical implementation and UI to marry the two?
>
> No, not really reasonable, IMO.  If you keep them separate, you open up
> the ability for multiple budget scenarios, etc., without losing any of
> the reporting capability.  You also have the opportunity to re-use the
> Account tree code to a certain extent, within the main window.
>
> Any work that you do on this would be greatly appreciated, I suspect.  I
> think the priorities right now are Lots, Periods, and then Budgeting.  I
> could be wrong, but that's my impression.  You're welcome to implement
> as you see fit--I believe my way is best of course! =P but really, I'm
> open to a better solution.  I've just thought about this for quite some
> time now, while looking over and working with Gnucash code, and data
> models, and accounting principles....
>
> Hope I've been clear, and not overly verbose.

-- 
"I slipped inside the oval office,
I slipped in oh so fast,
Grabbed the president by the necktie
And wiped my funky ass, hey"
                -Soulhat, "Bonecrusher"