On Sun, Jan 8, 2017 at 11:09 AM, Christopher Singley <[email protected]> wrote:
> > > On Saturday, 7 January 2017 14:33:43 UTC-6, Martin Blais wrote >> >> >> On a somewhat related note: I wonder if a new type of directive could be >> useful, similar to Balance assertions, that would assert that the total of >> one account matches that of another. I haven't need it myself just yet, but >> it's a simple and appealing idea. >> > > I doubt you'd find that useful. Such assertions are generally needed not > between various accounts on the general ledger, but between G/L accounts > and other records whose utility you've not yet perceived. > I don't see a problem defining an assertion that works across files. In fact, I could probably make use of that today when I create separate ledgers for trips or projects. I think it's a cool idea. One thing to be aware of is that the goal of this project is not to >> replicate nor implement traditional methods of accounting. >> Rather, the purpose is to come up with the simplest possible >> representation that allows one to enter and effectively query data from >> text files in the context of personal finance. >> Given this, I feel quite free to deviate from well-established norms, >> especially when their existence derives from historical limitations. >> For example, Beancount adopts Ledger's idea of doing away with credits >> and debits (preferring signed amounts) and there's no "reconciliation" >> process, instead you declare balance assertions explicitly. >> Furthermore, I think there may be simpler ways to solve some accounting >> problems by taking a CS outlook on them. >> > > The issue is not that traditional methods of accounting are crusty and > benighted... mapping debits & credits to +/- is just normal industry > practice; it's been pretty much universal since the release of Visicalc. > > The real issue is defining the scope of the problem. Accountancy treats > of operations and entities as different from one another as a hummingbird > and a jellyfish. In order to do our own work, we make simplifying > assumptions. It's important to be clear about what assumptions we're > making, the trade-offs involved, where they break down, and how to handle > it when they do break down. > > The biggest assumptions made by beancount seem to involve its input format > - e.g. a single monolothic file with a unified simple format suffices for > all accounting needs of personal finance, and manual data entry is entirely > sufficient for personal finance. I am entirely sympathetic to these design > goals, but it sounds like you're already starting to bump into problems > (the wash sale rules) the root cause of which is insufficient separation of > concerns. I hate to tell you that there's a lot more where that came > from... yes, squarely in the realm of personal finance (unless by "personal > finance" you mean "trivial cases"). > You're very confused. I'm having no problems with tracking my wash sales. Having an open data format has allowed me to build a custom solution for it. Not having any problems with it. Part of the power of an open system like this is that you can easily extract subsets of data from it and write custom code to solve a particular problem. It's an entirely respectable position to limit the scope of the problem to > just the general ledger - to say "beancount doesn't do inventory". > .... but it does. http://furius.ca/beancount/doc/inventories Your system looks fine for that use (although I need to test it) - I'm > pretty sure I could write what I need externally, and dump computed JEs as > text files to hand off to beancount. > > But you're heading into treacherous waters with inventory. Shoehorning > currency exchanges and securities trades into the same inputs as general > ledger entries is a kludge, and if you analyze the workings of systems that > actually handle these cases well, you'll see that you will run into > predictable problems. If you care about these things and want to do them, > it's worth formulating a plan for dealing with the obvious issues that > arise, and incorporating that understanding into the system architecture. > Well so far I've got accounts over four countries and 10 years' worth of data and usage that tell me the model I've chosen is working well, including currencies and investments. If you'd like to criticize it, I welcome it - it can only make my software better and maybe I learn something in the process - but you need to be specific, provide specific examples of where it fails. Talk is cheap; start by doing something, then present us with results or better, code. Then we can talk about performance or representational issues and limitations. I'm probably not the guy you really want to talk to - my knowledge of > accounting is as meager as my understanding of computer science. I can > only claim to have a reasonable experience of real-world personal finance > data that play havoc with all kinds of simplifying assumptions that would > be nice to rely on in an elegant accounting system. Hence my appeal to > generality. > > A tax attorney of my acquaintance says you can separate people into two > categories by placing a large bucket of silver dollars on the floor in > front of them. One group won't deign to stoop, foregoing the windfall in > order to retain an upright and dignified posture. The other group will > dive into the bucket and start grubbing for money, with their asshole > winking at the world. > > It's important to understand that, at its core, accounting is all about > sphincter winkery. If your wash sale problems had amounted to real money, > I imagine you'd be a lot clearer on that, and have a better understanding > of what reconciliation is really all about. As it is, I suppose you have > this enlightenment to look forward to. > > Carry on as you were! > That's the plan. It sounds like you're attached to the traditional ways of doing things, I'll suggest you might look into a commercial package for your work. Good luck, -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPcaNfeaZDm-sJMQKjgtca%3Dxkv%3DneBuQdZEDm4pYn4iXg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
