quicken migration
Hello. Just wondering what the consensus is for migrating savings goal accounts. One idea I have is like this: Create liability accounts for each 'savings goal', possibly as sub accounts under a common liability of 'savings goal.' Then, create a sub account of the bank account as an asset and use it for marking funds to savings. This would keep the actual account clean and it will match bank statements line by line (something I found frustrating in quicken) and you could see the amount you have unallocated in the account by looking at the total listed on the main gnucash account list screen. How does that sound? Have there been better ideas suggested? A feature that would be handy to make this kind of transition much easier would be a search and replace for account names in a register. Lauren Matheson Queen's University -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
My account structure looks something like this: + Cash On Hand + Bank Accounts - Checking - Savings - Certificate of Deposit + Savings Goals - Honeymoon - European Vacation + ... + ... 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." I basically treat a savings goal as a logical holding account so that I don't try to spend those funds. What is your reasonng for making them liabilities? Maybe I'm not thinking of a savings goal in the same way you are. Plus, it's been awhile since I actually used one in quicken, so I might not remember correctly how they worked there. Perhaps you could refresh me? Thanks, -Scott On Thu, Mar 30, 2000 at 11:10:57AM -0500, Lauren Matheson wrote: > Hello. > > Just wondering what the consensus is for migrating savings goal > accounts. One idea I have > is like this: Create liability accounts for each 'savings goal', > possibly as sub accounts > under a common liability of 'savings goal.' Then, create a sub account > of the bank account > as an asset and use it for marking funds to savings. This would keep > the actual account > clean and it will match bank statements line by line (something I found > frustrating in > quicken) and you could see the amount you have unallocated in the > account by looking at the > total listed on the main gnucash account list screen. How does that > sound? Have there > been better ideas suggested? A feature that would be handy to make this > kind of transition > much easier would be a search and replace for account names in a > register. > > Lauren Matheson > Queen's University > > -- > Gnucash Developer's List > To unsubscribe send empty email to: [EMAIL PROTECTED] > > -- -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
Lauren Matheson <[EMAIL PROTECTED]> writes: > A feature that would be handy to make this kind of transition much > easier would be a search and replace for account names in a > register. You're exactly right. As folks become more sophisticated in their understanding of accounting and how to use it, they need to be able to "retroactively" make policy changes in the way they keep their books. By hand is no fun; having a good transaction-finder is important. I'm actually working on this right now with help from Dave to get the register display stuff right. The idea is that you'll be able to do a "find" operation to open a special kind of register display which shows transactions from any account that match your criteria. Once you get that register up, you should be able to add or delete transactions from the display until you get the "just right" set of transactions. Then, you can run a "transform" operation to modify transactions in a variety of ways. As of last night the "find and display" part is more-or-less working. There's a fair amount of cleanup to be done still, and very little user interface exists, but it's a start. Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
Herbert Thoma wrote: > I don't use Quicken, so I'm not sure what a savings goal account is. > If I understand right, you want to have a certain amount of money > by a certain date, and Quicken tells you how much is still missing. > > So the solution for GnuCash would be a savings account for each > savings goal (easy, already existing) and a report that tells you > how much is missing (yet to be done). > > Herbert. The idea of savings goals in Quicken is that they are 'virtual' accounts, in that they are money that you are setting aside in your mind for a purpose, but there is no 'real' transaction happening. ie, I want to save $5000 for tuition for the next year. Each month when I recieve my pay cheque of $1000 I deposit it to a bank account and set aside $500 of it in my mind as savings for the next school year. So, while my bank account may have $2600 in it, $1500 may already be set aside so really only $600 is 'available' to me to spend. The reporting/reminding part is a secondary bonus - could be helpful, but not necessary for the underlying idea. Scott Haug wrote: > My account structure looks something like this: > > + Cash On Hand > + Bank Accounts > - Checking > - Savings > - Certificate of Deposit > + Savings Goals > - Honeymoon > - European Vacation > + ... > + ... > > 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." I basically treat a savings goal as a logical holding account > so that I don't try to spend those funds. How do you transfer money into the savings goal though? Would that be with transactions from each of your bank accounts? What I was thinking was that if you use a: + Cash On Hand + Bank Accounts +Checking - Savings Goals + ... ... + Savings Goals - Honeymoon ... Then the Checking account could match your bank statements line by line without savings goal transactions in the way, and then transactions to allocate amounts of money from Checking towards a goal could be made from the Checking:Savings Goals to the appropriate goal. Savings Goals will have a negative balance reducing the Checking balance shown on the main screen to the balance in the Checking register minus the Savings Goals. > > What is your reasonng for making them liabilities? Maybe I'm not thinking of a > savings goal in the same way you are. Plus, it's been awhile since I actually > used one in quicken, so I might not remember correctly how they worked there. > Perhaps you could refresh me? The idea of making them liabilities was that that is money that you 'owe yourself' or 'owe' to a specific goal. Since there really isn't any transaction taking place when you allocate money to a goal it seems wrong to me to enter one in a real asset or bank account. Lauren. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
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? 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... -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
> Hello. > > Just wondering what the consensus is for migrating savings goal > accounts. One idea I have I'm not clear what a savings goal account is, but it sounds like a budgeting issue. Does it make sense to represent budgets as accounts? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
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]
Re: quicken migration
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 > financi
Re: quicken migration
> > (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. Actually, you are able to have goals that are not tied to a specific account. Each account has only one sub account called "Savings Goals" which is used to enter transactions with the set of Savings Goal Liability accounts. So if you have a savings goal of "vacation" then this is the liability account "Savings Goals:Vacation" which may have transactions from "Chequing:Savings Goals" and "Savings:Savings Goals". The liability account will reflect the amount allocated from all accounts. Lauren. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
Have you looked at budget-report.scm yet? Right now it's at a proof of concept stage, but I think I've proved my concept. 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. 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
Re: quicken migration
> 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
Re: quicken migration
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 v
Re: quicken migration
So we want the same result. The report framework certainly works fine. The question then becomes whether to tightly integrate budgeting as a central pillar of the program, or leave it to reporting. There is certainly a case for the latter in terms of simplicity and familiarity, but the recent discussion of "savings accounts" as in Quicken made me think that people wanted to use budgeting in their main accounts rather than in a report. It's not clear that the added complication is worth it, but it is something to think about. -Patrick Baker On Thu, 30 Mar 2000, Bryan Larsen wrote: > 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 a
Re: quicken migration
Of course, what I suggested in the last message could probably be simply accounted for by having the budgeting module automatically put a Budgeting Balance transaction, similar to an Opening Balance transaction into every Expense and Income account. The Budgeting Balance would be adjusted every day to account for the increased money allowed for spending. This transaction could be turned on or off by a user interface switch. -Patrick On Thu, 30 Mar 2000, Bryan Larsen wrote: > 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 y
Re: quicken migration
On Thu, 30 Mar 2000 16:12:12 EST, the world broke into rejoicing as Patrick Baker <[EMAIL PROTECTED]> said: > 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. I'm a "math geek" who has studied the unusual (or not!) area of *discrete calculus.* None other than Donald Knuth has written a notable work on this; the joint authored book with several other TeX_related luminaries entitled "Concrete Mathematics." There is *some* merit in treating the idea of budgeting as if it involved some notion of "velocity," with "continuous" equations. It is quite convenient to look at macroeconomic activity in this way. It is, however, *not* accurate to look at personal budgeting in such a continuous manner, because our activities do *NOT* involve continuous transfers of cash. Personally, I get paid exactly twice a month. 99.999% of the time, the "velocity" of money is $0. Two seconds per month, the velocity is positive, at some thousands of dollars per second. At other times, the velocity is negative, at tens or hundreds of dollars per second. Thanks, but no thanks. I would MUCH rather look at my finances in a discrete manner. Admittedly, we could head to even "higher" calculus, with integrals involving Dirac functions and the likes; it may be integrable and all, but I rather think it makes a lot *MORE* sense to stay with discrete math, where the point is to have a decent scheduler to indicate when cash flows are expected. > 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. I'd *surely* be game to take an approach like this to my tax bill; it is *quite* fair to treat it thus: --> Twice a month, I earn income on which I have some estimate as to how much tax I owe. And I pay something to the government to prepay this. There are two ways to look at this: a) I'm just plain paying taxes each time. So: DRCR Bank 2000 Income 3000 Income Tax Expense 1000 b) I'm accruing a tax bill each time, and paying into an asset account, of prepaid taxes. Thus: DRCR Bank 2000 Income 3000 Prepaid Income Taxes 1000 Along with: Income Tax Expense 900 Income Taxes Payable 900 [It's $900 because I'm consistently overpaying; what I expect I *truly* owe is only $900/period...] At the end of the year, this would build up so that the balance might look like: Assets: Prepaid Income Taxes $24,000 Liabilities: Income Taxes Payable$21,600 Expenses: Income Tax Expense $21,600 And then, when the *actual* bill turns out to be $22,000 (since I was overoptimistic), the transaction to clean things up is thus: Tax Refund: Cash $2,000 IT Payable: $21,600 Prepaid Taxes: $24,000 Income Tax Expense: $400 which clears out the payable/prepaid accounts, reflects the money that the IRS (or CCRA, or whomever...) sent me, and fixes up the tax expense. > 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. The term for this sort of thing i
Re: quicken migration
It's been rumoured that Bryan Larsen said: > > 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. Well, at least part of the debate of 'velocity' vs. 'discrete events' seems to be about getting that smooth graph. Technically, I think the 'discrete events' aproach is the correct, standard, accredited way of doing things. But that does not mean that there's no way of smoothing things out, espcially when the large bumps are due to expected expenses. What comes to mind is the black & sholes equation, although that's a bit of an overkill. As originally applied, it predicts option prices based on stock price, due date & volatility. In some way, we can do the same: if we know that we've budgetd $600 every month for e.g. rent, then, if you want to have a smooth graph, it makes sense to 'depreciate' it daily, so that your expenditures graph doesn't have a stairstep in it ever month, and so that your budget graph doesn't have a $600 up spike on rent due date, and an equal down-spike a few days later when youn actually pay the rent. On average, the budget graph should really look pretty flat, if you've budgeted correctly. Don't let the big noisy spikes fool you. --linas -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
Linas said: > In some way, we can do the same: if we know that we've budgetd > $600 every month for e.g. rent, then, if you want to have a smooth > graph, it makes sense to 'depreciate' it daily, so that your > expenditures graph doesn't have a stairstep in it ever month, and so > that your budget graph doesn't have a $600 up spike on rent due date, > and an equal down-spike a few days later when youn actually pay the > rent. On average, the budget graph should really look pretty flat, > if you've budgeted correctly. Don't let the big noisy spikes fool you. > If you don't always pay the rent on the same day, categorize your rent as "recurring" rather than "trigger on date". You'll only get a spike if you're 30 days late. And then you deserve one. Bryan -- - 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]
Re: quicken migration (savings goal)
Lauren Matheson wrote: > Hi! I don't use Quicken, so I'm not sure what a savings goal account is. If I understand right, you want to have a certain amount of money by a certain date, and Quicken tells you how much is still missing. So the solution for GnuCash would be a savings account for each savings goal (easy, already existing) and a report that tells you how much is missing (yet to be done). Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: budgets Was: quicken migration
What I've always wanted was a way to relate each transaction to the budget category and period it belongs to. So if I put off paying a bill for a few months (maybe there's a dispute as to the correct amount or something), when I finally do pay it it sould count against the budget period it logically belonged to, not the one in which the payment finally occurred. And it would be wrong to say I had managed to go $1000 under budget simply because I postponed paging a large bill. There would seem to be a planned envelope of spending for each budget period, estimates of committed spemding (which ought to fit within the spending envelope), and actual spending when the cheque is in the mail. I'd like some mechanism that keeps track of all this gracefully. But a savings-goal subaccount is a lovely stopgaps to make one feel worried at the right moments about the big picture. -- hendrik. P.S. Maybe some thing this perverse, but I enjoy the practice we seem to have of quoting the entire discussion in each message. It provides a really convenient, printable summary. And I can delete old messages that have been followed up on so as not to fill up the 20gig hard disk I've just ordered :-). Well, it's not quite perfect; sometimes there are several replies ot one message. :-( > Of course, what I suggested in the last message could probably be simply > accounted for by having the budgeting module automatically put a Budgeting > Balance transaction, similar to an Opening Balance transaction into every > Expense and Income account. The Budgeting Balance would be adjusted every > day to account for the increased money allowed for spending. This > transaction could be turned on or off by a user interface switch. > > -Patrick > > On Thu, 30 Mar 2000, Bryan Larsen wrote: > > > 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 u
Re: budgets Was: quicken migration
Hendrik Boom <[EMAIL PROTECTED]> writes: > P.S. Maybe some thing this perverse, but I enjoy the practice we seem > to have of quoting the entire discussion in each message. It's certainly not a practice all of us have (or like). -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: budgets Was: quicken migration
> Hendrik Boom <[EMAIL PROTECTED]> writes: > > > P.S. Maybe some thing this perverse, but I enjoy the practice we seem > > to have of quoting the entire discussion in each message. > > It's certainly not a practice all of us have (or like). When I wrote the P.S., I thought " Everyone will probably think I am being sarcastic, but I'm not." In retrospect, I probably was being sarcastic and didn't realize it because I was tired. What's really needed is not massive quoting (quadratic bandwidth usage), but a way to reconcile multiple partially quoted partially edited messages so that you can, if you choose, see the entire conversation history easily. But that's probably not a problem for gnucash to solve. -- hendrik. > > -- > Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 > > -- > Gnucash Developer's List > To unsubscribe send empty email to: [EMAIL PROTECTED] > > -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: budgets Was: quicken migration
Hendrik Boom <[EMAIL PROTECTED]> writes: > What's really needed is not massive quoting (quadratic bandwidth > usage), but a way to reconcile multiple partially quoted partially > edited messages so that you can, if you choose, see the entire > conversation history easily. But that's probably not a problem for > gnucash to solve. You might already know about this, and it might not be what you want, but threaded mail readers (like Gnus, mutt, etc) help tremendously. I can't imagine dealing with the volume of mail I get without Gnus. FWIW -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
