On Thu, 30 Mar 2000, Patrick Baker wrote:
> > 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.
Mine's not all that familiar either.
>
> 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.
That's exactly what I want. From my example:
if the budget report says that a line item has a lower limit of $18 and
an upper limit of $36, and an actual of $14, that means I can blow $4 on
anything, and $18 on the line item.
>
> 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
In the budget realm, that's simply called adjusting your budget. I've never
used the Quicken virtual savings accounts, though.
Bryan
>
> >
> > 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]
> >
> >
> >
--
-------------
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]
