On Wed, May 21, 2014 at 2:46 PM, John Wiegley <[email protected]> wrote:
> >>>>> Martin Blais <[email protected]> writes: > > > If the community accounts straddle the real accounts, you just filter by > the > > CommunityX bit. Imagine for a moment the worse case, that all real > accounts > > have all community subaccounts (in practice this rarely occurs, BTW, > > real-world structure is always more constrained than this deliberately > > chosen "full-product of dimensions" example): > > > Assets:Real:Account1:Community1 > > Assets:Real:Account1:Community2 > > Assets:Real:Account1:Community3 > > Assets:Real:Account1:Community4 > > Assets:Real:Account1:Community5 > > Assets:Real:Account2:Community1 > > Assets:Real:Account2:Community2 > > Assets:Real:Account2:Community3 > > Assets:Real:Account2:Community4 > > Assets:Real:Account2:Community5 > > Assets:Real:Account3:Community1 > > Assets:Real:Account3:Community2 > > Assets:Real:Account3:Community3 > > Assets:Real:Account3:Community4 > > Assets:Real:Account3:Community5 > > They do fully straddle, and this solution above is just too ugly. Ledger > often opts for convenience over theoretic purity, and this is one of those > cases where I find it fully justified. > > When I mentioned my motivation for virtual accounts, I said that part of it > was to make an onerous task less onerous so that I would actually keep up > with > it. The huge amount of account splitting you've suggested above would make > the system laborious enough that I would give up on it. Hence, virtual > accounts. It's true that this is not a "nice" solution, but neither is using virtual accounts, because you give up the balancing check, which in my view is simply not an acceptable option... It might look nice, but it makes it really easy for you to make a mistake that goes undetected. That's not a solution either IMHO. I'm curious as to the reasons behind this structure. Why is the structure of these projects managed in that way? Why do you need to have assets for each community project? Is there a better way to structure this? I.e., how does a company splice and dice their assets between their internal cost centers? (A similar problem.) In my experience there's nothing that can't be sorted out by introducing a level of indirection or two, some intermediate buckets to reallocate the beans... can't the funds from all these real accounts be pooled to some intermediate non-real account and then entries issued to allocate budgets for each of the projects, which could then subtract their entries from their own dedicated budget accounts as they incur them? There has to be a way, I think if we discussed with a corporate accountant it might provide some insight that makes this example solved with regular postings. In any case, I think we can come up with something better that achieves the goal of managing two sets of distinct categorization while still keeping the balances. Here's an idea: What if we marked some accounts (your real accounts in the example above) as "required" to book all of the entries that affect them into two well-defined but distinct subsets of postings, say A and B? Then, when parsing, one would select the A set of postings or the B set of postings. Requiring all those transactions to have two sets of balancing postings would ensure that all the amounts in that account are correctly booked one way or the other. You're basically entering two categorizations in the same place for all transactions that related to some set of accounts, and then choosing one set of categorization across all of them, or another. This could be done early on, even during parsing. I'm convinced we can come up with some other ideas to solve this problem that don't require giving up balancing. -- --- 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/d/optout.
