On Sat, Oct 18, 2014 at 4:11 PM, Wm... <[email protected]> wrote:
> Sat, 18 Oct 2014 13:48:05 <CAK21+hMNcR-j_6skp3w+ > [email protected]> > Martin Blais <[email protected]> wrote... > > 1.1 "Duplicate Entry" drawing 10 cash twice in one day is not an error >>> >>>> >>>> >>> Hmm, so here's the thing, in the implementation, each transaction has a >>> unique signature, a "hash", which allows me to make comparisons between >>> sets of transactions. >>> >> > me, says Martin, me ! The transactions will only be detected as duplicates >>> if and only if _all_ of their fields are exactly the same. This rarely if >>> ever happens in practice. >>> >> > In *your* life! > > This is where I must stand up and say I think you are a fool. > > Your life may be such that you never do something twice in one day, I am > not like that. My life is not like that. > No, you don't understand, it's entirely legitimate to do multiple cash transactions of the same amount in the same day, you can just vary the narration string to make each unique. (From an implementation POV, it's a really nice property for transactions to have a unique signature, it makes it possible to do diffs on sets of transactions.) Anyhow, I've moved this check to be optional following your comment, so it does not get triggered by default, it sounds reasonable that some of the stronger checks should be optional. If you want the check you have to explicitly enable it with a plugin now. GnuCash has the notion of a transaction ID that ledger-cli and beancount > don't. > > Why do you think they have that if not for ordinary repetitive stuff? If > you've only just realised a person may withdraw the same amount of notes > from a cash machine in one day you are living a very restricted life in my > opinion. Again, you're misinterpreting the intent of the constraint. I never claimed you could not do this in Beancount, just putting a unique narration/comment on each transaction disambiguated it in the first place. You probably were cut-n-pasting the same >>> transaction to test things out. >>> >> > Wrong. I, a human being, withdrew a unit note of my countries convenient > currency, unit 10, from a machine, provided by a global bank twice in one > day. > > I am *NOT* going to apologize to you for doing that, OK! Sort your stuff > out. > > TBH, I am finding this bit of you weird, MartinB. > > The reason this exists is that it has happened a few times in the past >>> that in the course of importing a transaction was copied twice - clearly >>> an >>> error. This check exists to detect this. >>> >> > Why should I or anyone else have to play extra checks and padding because > you or your bank fucked up in the past? This is *not* the way to get > people on your side, Martin. The bank never made a mistake, the user did. It's easy to make mistakes. I was trying to provide some help to the user in avoiding to make the common mistake of repeating the _very_ same transaction by accident. (And FWIW, I'm not trying to get people "on my side", I'm just building software. If you don't like it, please don't use it.) Okay, so here's what I'm going to do: >>> - Make the unused account check optional; it will be available through an >>> optional plugin. >>> >> > CoA sensibility suggests this is a good idea. > > - Make the duplicates check optional; similarly will be available through >>> an optional plugin. >>> >> > I think someone else said something about apportioning and accounts not > balancing exactly. I mean, if I sell stuff I don't have *and* I didn't > have Trading accounts would you prevent the record of the transaction? > > This is the issue. Do you record reality or not? I think you are, in > some circumstances worse than ledger-cli because you want to impose. Post > event things may be clear. I don't understand the two paragraphs above. - Beancount specifically does not allow you to reduce units from lots you do not have. That's the key difference between the way inventory booking is modeled in Ledger and Beancount, we take two distinct approaches to this. - Yes, the intent is to create a record of reality in all these softwares. What do you mean by "apportioning"? Can you detail the example of "if I sell stuff I don't have *and* I didn't have Trading accounts"? Those who want super tight checks will have to add the options. >>> Something like this: >>> >>> option "plugin" "beancount.plugins.nounused" >>> option "plugin" "beancount.plugins.noduplicates" >>> >>> By default unused accounts and duplicates would be allowed. >>> How's that? >>> >> > I'm unaffected, your theoretical 3 users may speak. > > Implemented. >> https://bitbucket.org/blais/beancount/commits/01ab95c5ab260fb3d6dc34861e >> 5111c4da3ff35d?at=default >> https://bitbucket.org/blais/beancount/commits/0362940c62197b2ab4b0838b5f >> 7c754afb2ef7eb?at=default >> >> Beancount users: if you still wants these validation checks, add this to >> your file: >> >> option "plugin" "beancount.plugins.nounused" >> option "plugin" "beancount.plugins.noduplicates" >> > > BTW, I think if you dropped the unnecessary precision you might get some > extra users. I'm not sure the cynical comments deserve a response but you're wholly welcome not to use the stuff I build. In fact, I would encourage you not to use it. I don't work for you AFAIK, I built this software to manage my own finances and provide it for free or others who are be interested (it works great and if I'm the only user of it I'll be very satisfied) and love to participate in discussions to solve personal financial management problems. If you don't like it, please go play with something else. About the precision issue, I've already written a proposal doc to outline what the problems are, and what could be a great solution, which will get implemented: https://docs.google.com/document/d/1MY2JMiiXUmcwsOT0CkiK-fCo0ZE7nbr8uTcTL50b6X4/ And thanks for the two bits of constructive feedback 2 or 3 emails prior. I'm always glad to hear of friction others may have and to make suitable adjustments. Good luck, -- --- 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.
