> Expenditures are *discrete* events. I do not see the difference betweeen your
> "velocity of money" approach and Quicken/MSMoney's approaches. The only
> difference is that your base time period is much smaller (1 day rather than 1
> month). Over the long term, your approach works, but in the short term it
> falls down.
The reason I was thinking more about this approach than a report scenario
is because I don't tend to do a budget reconciliation at a particular time
of year. I would like more of a continuous approach, and thus took the
logical extreme in considering a velocity rather than looking at discrete
transactions. I admit that it's a unfamiliar way of looking at things,
and if it is not obvious to most then it should not be implemented.
I also was thinking about my approach because it's nice to have the
expense accounts show how much you're allowed to spend at a particular
moment in time, rather than the amount already spent from an aribitrary
date when you started keeping track.
Integrating budgeting with accounts then allows you to do things like
transfer money between budget accounts if you want to cut back on
something in order to do something else.
-Patrick Baker
>
> With my prototype budget report, you can ask it for a budget report for any
> arbitrary period, and it will give you a real answer on whether you are
> spending too much or too little.
>
> For example, it knows that you are paid on the 1st of the month, or on a Friday
> every 2 weeks. If you have a 17 day budget report that encompasses two pay
> periods, there should be 2*pay in your budget, not 17*pay/14.
>
> Other expenses occur fairly regularly, but not on a known date. I fill up my
> car for $18 approximately every 6 weeks (gotta love diesels). If I ask for
> a report for the last 9 weeks, there should be either 1 or 2 fill ups, not 1.5
> fill ups, so < $18 is under budget and > $36 is over budget.
>
> It's still possible to trick the system. For example, a 5.9 week report would
> consider $36 over budget. No big deal -- you know your tank is full, so you
> aren't worried. Conversely, a 6.1 week report where you didn't spend anything
> on fuel, but your tank is empty.
>
> Extraordinary/contingency expenses are handled very similarly, but are handled
> slightly differently. If you set up the above diesel expense as a
> contingency instead, a 9 week budget report would have a lower limit of $9 and
> an upper limit of $45. ($18/6 * 9 +/- $18) The idea is that you can be hit
> with the full amount of the contingency expense at any time, so you should
> always have $18 "saved".
>
> Obviously you don't balance your budget for weird periods. You should balance
> your budget over the least common multiple of all of the periods. If that
> means you need a ten year budget, so be it. You're obviously not going to
> follow the same budget for ten years, but the fact that the budget balances for
> the full ten year period means that it balances for the current year as well.
>
> This all works pretty sweet. One thing I'm looking forward to seeing is a
> DAILY graph of the budget balance that doesn't swing wildly as large expected
> expenses hit.
>
> Does this make sense to everyone?
>
> Bryan
>
> On Thu, 30 Mar 2000, Patrick Baker wrote:
> > I've been thinking about budgeting issues for a while, since I have never
> > found a financial application with the budgeting implemented in a clean
> > way. To me, a budget amounts to specifying the "velocity of money". By
> > that, I mean that you are specifying the flow per unit time which is going
> > into various expense accounts. For instance, as you work at your job, you
> > are paid so much per hour (or for the salaried among us, per year). This
> > is then *your money*, except that your company hasn't gotten around to
> > paying you yet. So in my mind the budget account Salary has a money
> > "velocity" associated with it. You tell the program that you're going to
> > receive 36,000 / year and at the end of January, and the program
> > automatically deposits ~$100 / day into that account. That way it makes
> > sense when the program transfers money from the Salary account into the
> > budget account. The money didn't come from nowhere, but came as a result
> > of the "integration" (for you math geeks) of the velocity of the money
> > over the correct period of time.
> >
> > It works the same way with expenses. As you use electricity, you owe the
> > electric company money at the rate you use the electricity. So your
> > Utilities:Electricity account gets debited at a certain rate. When you
> > get a bill, you (hopefully) bring that balance back to zero by depositing
> > money into it.
> >
> > Bringing it back to the discussion about the honeymoon account, you know
> > that you want $5000 on December 15. So you plug in that planned expense
> > into your account, and specify how you would like to save for it (evenly
> > from now until then, or maybe ramping up in the last couple of months
> > because there are other expenses which will end by then). The program
> > computes the budgeting function, and at each day, your balance becomes
> > more and more negative, until you put money into it (or maybe the program
> > could do this automatically). The object is to keep your expense/income
> > accounts at $0.
> >
> > This then brings us back to the question about reconciling the accounts.
> > If you were to transfer money inside GnuCash, then it would become
> > difficult to reconcile your accounts, as has been pointed out in previous
> > emails. The subaccount solution is in some sense suboptimal because you
> > might have multiple accounts (investment and savings) and use multiple of
> > them to save for the honeymoon. Because this is the case, what is
> > necessitated is an idea of budgeting transactions versus actual
> > transactions. When you get a paycheck, all of it gets deposited into your
> > checking account, but then you can make a "budgeting transfer" to the
> > honeymoon account, postdated to the date of your honeymoon. If you later
> > break off your engagement and decide to spend your money on a car, you can
> > make a budgeting transfer from the honeymoon account to the car account.
> > This feature makes budgeting priority changes easier to deal with. If you
> > had an unexpected car breakdown, you could decide to put off that
> > vacation by transferring money out of that account and into the car repair
> > account.
> >
> > You could view your accounts "with budgeting transactions"
> > or "without budgeting transactions". Of course this would necessitate
> > painful changes to the engine, but could result in a very clean budgeting
> > framework for future financial planning functions.
> >
> > Of course budgeting could be done in a report framework, but as was
> > pointed out, the psychological matter of seeing negative balances helps
> > many to do better planning.
> >
> > -Patrick Baker
> >
> > On Thu, 30 Mar 2000, Scott Haug wrote:
> >
> > > On Thu, Mar 30, 2000 at 12:28:15PM -0600, Rob Browning wrote:
> > > > Scott Haug <[EMAIL PROTECTED]> writes:
> > > >
> > > > > I'm not sure why you would treat it as a liability, but to be honest
> > > > > I have no accounting background so maybe that is the best way. I
> > > > > just treat my savings goals as bank accounts. They're merely
> > > > > logical accounts used to meet a certain monetary goal, and since the
> > > > > money in a savings goal doesn't actually leave the physical account
> > > > > it was transferred from, I still consider it an asset and "Cash On
> > > > > Hand."
> > > >
> > > > But if you really are transferring the money in gnucash from a bank
> > > > account to a savings account, how can you reconcile with your bank
> > > > statement each month? Those transfers will never show up in the bank
> > > > statement, and so the balance will always be wrong, or am I missing
> > > > something?
> > >
> > > Having a "wrong" balance is kind of the point. Its not a real account, its a
> > > virtual or logical account set up so you can "set aside" money for a large
> > > purchase or debt, such as a vacation or school tuition. The balance reflected
> > > in a goal account should indicate to yourself, "that money shouldn't be used
> > > for anything else", and having the goal account's balance factored into the
> > > bank account's balance helps to achieve that. I don't know about anyone else,
> > > but I have a pavlovian reaction when I see a negative balance in my personal
> > > financial app, even if I know I have a positive balance in my actual physical
> > > account.
> > >
> > > My original solution was to set up a separate goal account that stood apart
> > > from the bank accounts, and make transfers from the bank account to the goal
> > > account. If I remember correctly, this is more-or-less how quicken sets them
> > > up. The problem is, as both you and Lauren pointed out, is that these
> > > transfers aren't reflected in your monthly statement, making reconciliation
> > > somewhat difficult and confusing. Using quicken, I usually factored that in
> > > and would reconcile those transactions anyway, but I only had one goal account
> > > at a time, so it wasn't too difficult. Multiple goal accounts, however, might
> > > make this more than unreasonable.
> > >
> > > Lauren's solution is much more elegant, and it better takes advantage of the
> > > superior structure already in place in gnucash. She suggests setting up a goal
> > > account as a sub-account off a regular bank account, and debiting from the goal
> > > account to a liability account (which makes sense to me, thanks Lauren!) to
> > > represent setting aside money for the goal. The beautiful part is you don't
> > > have to worry about these transactions showing up in your checking account,
> > > since you're never actually touching the bank account. Therefore, monthly
> > > reconciliations would work just like normal, without having to factor in any
> > > goal account transactions. It gets better: the goal account's (typically)
> > > negative balance would be factored into the bank account's balance on the main
> > > window (since it's a sub-account), giving you the desired effect of a
> > > (perceived) smaller balance without any fuss. The only minor downside of this
> > > method is that for it to be most effective, these goal accounts must be tied to
> > > a single bank account, whereas a separate, standalone goal account could
> > > receive transfers from any bank account. But I believe its worth it for not
> > > having to mess with it come reconcilation time.
> > >
> > > > If I'm right, then to do "savings goals", we'd probably need another
> > > > abstraction. Maybe you'd have a "real balance", used for
> > > > reconciliation, that ignores savings goal transfers, and then the
> > > > "normal balance" that gnucash shows you by default that includes the
> > > > savings goal transfers. This would probably require a new account
> > > > type and some ugly, and possibly incorrect, monkeying around in the
> > > > engine. Not sure off the top of my head...
> > >
> > > I don't think this is necessary. As mentioned, making a goal account a sub
> > > account of a bank account (so many accounts!) is almost a perfect solution, and
> > > doesn't require any code changes to gnucash, since its framework has been so
> > > well designed! A new account type wouldn't hurt to help delineate a goal
> > > account from a bank account, but it would have the exact same semantics as a
> > > bank account and would be a different account type in name only.
> > >
> > > Anyway, I don't think these goal accounts would be used enough by most people
> > > to deserve drastic, confusing changes to the stable structure already present.
> > > What we have is sufficient. What /would/ be useful would be a druid that could
> > > step people through setting one up, creating the requisite sub-bank
> > > account/liability account combo. But it would basically just automate
> > > something that isn't all that difficult to do manually.
> > >
> > > > --
> > > > Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
> > >
> > > -Scott
> > >
> > > --
> > >
> > > --
> > > Gnucash Developer's List
> > > To unsubscribe send empty email to: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >
> >
> > --
> > Gnucash Developer's List
> > To unsubscribe send empty email to: [EMAIL PROTECTED]
> --
> -------------
> Bryan Larsen, Senior Software Engineer & fall guy
> Analog Design Automation: Analog Circuit Synthesis? Problem Solved.
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
>
>
>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
