On Sun, 14 Apr 2019 11:34:13 -0400 Martin Blais <[email protected]> wrote:
> This is a reasonably well-written and fair enough review, though with a bit > of a snarky tone and perhaps some misconceptions (though I can't blame the > author for not seeing through all the nooks and crannies in just a few days > exploration). Here's a response that attempts to address the points made in > the article. And here's a quick response to just a couple of things... > First, I'm impressed that he managed to import his QuickBooks data in just > a few hours. I didn't realize it had become that easy. The tricky part is extracting it from QB. Obviously, once you have the data, formatting it properly for beancount is easy. > The reviewer mentioned the lack of reconciliation as a "nearly fatal flaw." > What he's referring to is not specifically the absence of a flagging > mechanism (because we have one) but rather the lack of support for > different dates in a single transaction. Not really. What matters is not the two dates; what matters is knowing what is outstanding so you can (1) calculate the "real" account balances and (2) reconcile against a bank statement that doesn't show that balance. > The reviewer does mention "the reconciliation pass." This obviously comes > from a history of working without assertions. To a large extent, assertions > obviate the need for this, but he missed that you can use flags for this > anyway (that's their main purpose, e.g. using '*' and '!' to make > transactions are correct or incomplete) and suggests the use of metadata > instead, which is a bit overkill in terms of syntax. I very much did *not* miss the use of flags. I also didn't miss that the documentation describes them as how one deals with deduplication or for marking transactions that "look incorrect", which are different problems. I can certainly see how they could be used for this purpose, but that also did not seem to be the intent of the feature. Assertions would only be helpful here if they ignore transactions with specific flag values. If that is the case, the documentation doesn't reflect it (as far as I can see). > CHECKS & TRANSACTION NUMBERS. > > For those you can definitely use links or tags, or metadata and the > reviewer mentions this possibility, but alludes that it would be work to > "actually write the accounting system." I'd like to know what kind of > processes he'd like to see supported. The biggest thing, of course, is tracking which checks have cleared. It's important information to put on related documents, such as the summary we provide to authors about the payments we have sent them. Otherwise they are really just debits like any other. Automatic number generation for entry and printing is nice, but a secondary feature. > IGNORED LINES. > > I think that comment stems from outdated documentation. Certainly I went from the documentation (which says explicitly that this happens); didn't have the time to experiment with it. > A similar comment > applies for the reviewer's notice of the absence of customers or vendors. > I'd have expected an LWN reviewer to see through that. I'm not quite sure what I should "see through". I made it clear in the review that I was looking for features that were beyond the scope of what beancount was meant to provide. It was all about suitability for a specific task, not a criticism of the system as a whole. > The author mentions that no free accounting systems generate > government-mandated forms; you will never see any free software doing that. Almost, but not entirely true. > There are simply too many variants of forms, too much data that isn't part > of the transaction flow, too many countries, etc. and most importantly, > it's just not a sexy job. That's why companies like Intuit have thousands > of developers being paid to process the minute details some obscure tax > rule in a particular country for a particular year and figure out how to > map some specific constrainted subset of accounts in their ledger to > produce some number in some form, etc. Not Beancount nor any of the other > PTA systems will ever do that. Nobody in their right mind would work on > that on their free time on the weekend. I'd never expect that from any free > system in the first place and I have to wonder why the reviewer did. Did I say I expected that? I simply said that it is not present. Remember, we're talking about escape from proprietary systems, and that is one of the challenges inherent in that task. That said, one does occasionally see support for specific forms pop up in some free systems. But it's rare, incomplete, and usually poorly maintained. > What I > think we might see instead, is a generic PDF overlay project, where one > could combine a PDF file - from a government form - with an associated > template with some input file to insert text where the template specifies > it should (i..e template says "field 'name' is at <coordinates>", input > file says "name = 'Joe'"). This could be easily integrated with something > like Beancount by writing a script to pull the right numbers to generate > the input file and then produce the PDF. That's a conceivable way such form > generation could proceed in the OSS world (I started something like that a > little while ago, but time is scarce). That does sound like a promising way forward, depending on just how badly specific governments obfuscate their PDF forms... Overall I get the sense that you saw the review as an attack on your work. That was not the intent, and I tried to be clear about that in the conclusion. Beancount is good stuff with clear applicability in a number of places, and the fact that it doesn't solve the specific problem I had, when you never set out to solve that problem, does not detract from that. Thanks, jon -- 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/20190415103917.28ab3328%40lwn.net. For more options, visit https://groups.google.com/d/optout.
