On Mon, Apr 15, 2019 at 12:39 PM Jonathan Corbet <[email protected]> wrote:
> On Sun, 14 Apr 2019 11:34:13 -0400 > Martin Blais <[email protected]> wrote: > > 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. > I don't understand what you're saying. What's the "real" account balance? Be specific. The whole reconciliation thing... I haven't seen anybody discuss this cogently. I think this stems from a historical method of working--please prove me wrong. I can see possible example interpretations of what "reconciling" could mean to you: 1. "Leave some state on this transaction indicating that I've verified it manually and it's correct" That's a flag. 2. "Indicate that until now all of the past for some account is frozen (and correct) after some point in time." We don't support that. We allow changing the past, especially where it's incorrect. Your numerous assertions are the backbone of your correctness. 3. "I need to integrate pending information that's not materialized as a transaction yet." You use queries for that, and you can sum values from different accounts to derive numbers from them, e.g. checking + checks-made-not-cleared-yet. Maybe that should be formalized more (well there's the Query directive that allows you to define common queries you may want to run). 4. Something else? Please illuminate me. > 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. > How would you use flags to deal wiith deduplication? They don't do that. > 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). > Assertions that ignore a subset of transactions are an interesting concept. How would they be useful to you? I think generally I'd like to have the ability to embed any conditional - as SQL expressions - that are always checked like assertions. Basically, assertions could become programmable, that's a really powerful idea. You could do temporal checks like that, which would lead to budgeting-like features ("assert that no more than X is spent between time A and B"). It's not there yet. > 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. Once the check hits the account, it's cleared. You recognize the payment as a transaction, post it to some other pending account, and when the check is cleared you'll see a transaction from your checking account. I don't understand what you need. Tell us how you do it in QuickBooks. Be specific. I'm ignorant. > 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. > What I mean is that coming from a Linux background, you should be a position to appreciate that most of the tools surviving the test of time are simple and designed to do just one thing well. All those big integrated "applications" (e.g. stuff usually built with desktop UI toolkits on Gnome, KDE, etc.) come and go, most often fall into disrepair after a few years, and almost always fall way short of their commercial equivalents. You still run "ls" but that windowed file manager is probably the 12th iteration you've seen (and ignore every time it pops up). What the PTA tools are attempting to achieve is different: design the simplest systems that will get the most amount of mileage to run bookkeeping out of text files and get creative about how to combine them with scripts to solve custom problems. We don't even invert the signs on Income accounts! It's not a surprise they don't have invoicing, printing cheques, tax / forms support, vendor lists, and nor built-in integration with your bank, etc. This is more like "vi" less like MSDEV. Discussing those things as if they were flaws or even shortcomings is missing the point a bit. > 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... > You could do it on the basis of coordinates on top of the PDF. Xournal could be modified to include the concept of "boxes" in its output data format. One could then very rapidly produce templates matching each form, manually giving field names to the boxes. Those could be shared as text files between users in a repository. The most common forms would probably all be there already (e.g. W4). This is a simple project idea with a lot of potential impact. > > Overall I get the sense that you saw the review as an attack on your work. > I don't know why you say that, I just responded to your review, but in any case I'm completely unfazed. The main thing I care about is whether I might have missed some important idea in the design or schema (or proposals). It provided yet another reminder that the settlement dates proposal really matters and needs to be done at some point, and that having more built-in plugins that do things by default might be more appreciated by users that I usually think it is. > 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/CAK21%2BhM%2B5%3DZxHvOiwT0b95WrPq7616Gh4jpC%2Bh7NriWsGGWkrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
