On Tue, Jan 14, 2014 at 9:22 AM, Kaito Michishige <[email protected]> wrote:
> > I was thinking that I could just subdivide my accounts like > "Assets:Checking:Food", and then query "Assets:Checking" for an overall > balance, along with the balance of each "bucket". The issue I'm facing is > tracking the cash I carry around, which would not be in "Assets:Checking", > but in "Assets:Cash" instead. For petty expenses, I can just assign it to > "Expenses:Cash", and treat it as spent, but I often withdraw money to pay > for non-trivial things, such as dining at a place that doesn't accept > cards. YNAB "solves" this by keeping the buckets and accounts separate, but > I'm not sure if I can do the same with Ledger. I was thinking virtual > transactions and accounts might help me solve it, but I'm having trouble > visualizing a solution. > Avoid virtual transactions. There's never a need for them. I'll argue that if you really think you need them, especially at an early stage of using the DE bookkeeping method, you're almost surely doing something wrong. Beancount - my own iteration on a Ledger-like system - does not support virtual transactions in the latest version (I removed them, I managed to replace all my uses of virtual transactions by coming up with correct DE entries instead). As for budgeting, I think an easier way to deal with allocations would be specify an amount of allowed expenses for each expense category and have some reporting of the difference amount against the allocation. I don't know if Ledger can do that OOB, but you could surely script it on top. (Your description gave me an idea for how to implement this and I think you could easily add a prefilter for transactions from a Beancount ledger to flesh this out, see beancount/bin/bean-example-custom-filter if you're interested in hacking something.) But at the EOD, and almost always, you could find a better way to do this with the DE method without modifications: what you could do is for each expense account, have two of them: one that receives a budget allocation and one that computes the difference to the allocation (let's call that "actual"). This requires no modification to the method, and all the budgeting is done on the expense side, which IMO is a better place for it, as it does not impact all your asset accounts (you described checking and cash, but there's also credit cards, etc. this is just the wrong place to allocate for expenses IMO as each of these would have to receive a budget allocation subaccount and you don't know in advance where you're going to spend from so it's impractical). One idea would be to split all the expense accounts in two subaccounts: budget and actual. When you want to allocate, you move money from actual to budget. When you spend, you book that against actual. At any point in time, the budget account shows you how much you have budgeted, and the actual account shows you what you still have remaining to spend (as a negative number). The sum of the two subaccounts is the expenses total for that category, as previously (all this requires from the part of the system is a way to aggregate the subaccounts). I created a test file that fleshes out this idea: https://hg.furius.ca/public/beancount/file/6e95d6550246/doc/development/budgeting-expenses.beancount (At the EOD, I think that there should be a layer on top of this, as it's not as nice as it could be.) > Unfortunately, the built-in budget model using periodical expenses doesn't > suit me, since my income and expenses vary wildly month to month. > I also feel that forecasting should only be approximate, because that's the case for everyone: it never happens that you can precisely predict all the exceptions that occur in practice. IMO future entries should only be synthesized in "the future", that is, beyond the last transaction that occurs in an account. In other words, once you're updated an account, none of the synthesization should take place in that time range. That's how I plan to add forecasting transactions in Beancount (not done yet), I just think the potential for errors is too large otherwise. -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
