On Sun, Oct 19, 2014 at 9:32 AM, Wm... <[email protected]> wrote:

> Sat, 18 Oct 2014 17:23:34 <CAK21+hMneyWt_NaUJt9cEKp3YFh9nfMa_ooUc9sM2J_
> [email protected]>
> Martin Blais <[email protected]> wrote...
>
>  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.
>>
>
> I do not want to explain to my accounting s/w why I took some money out of
> my account.  I do that by saying how I spend it.  If you and other people
> withdraw money from a machine and *only* ever spend it on what you decided
> on at that moment I feel sorry for you.


You are still not understanding what I said. There is no expectation that
you would have to explain anything. The validation check was just there to
make sure you don't accidentally enter the very very same transaction twice
(entirely identical transactions on the same day happens to be pretty rare
in practice). The check worked by hashing all the fields on a transaction
object to a unique signature, and then collecting all those signatures and
verifying all of them were unique. You could have easily made _any_ part of
the transaction unique to disambiguate it. The most semantically applicable
way to do this would have been to add a unique link to it:

  2014-02-02 * "WITHDRAWAL" ^2
    ...

In the above, "^2" is the link field. It gets hashed along with the rest of
the transaction data.

By the way, did you notice that I made both of the validation checks you
commented about optional, and that those checks don't trigger by default
now?




 The bank never made a mistake, the user did. It's easy to make mistakes.
>>
>
> How?  Do you mean I booked a hiking trip in Nepal kind of mistake ?


No, not so much by actually _booking_ it twice but rather by _copying_ the
transaction data twice.
Surely, if you copied an expensive Nepal hiking trip twice by accident you
would want some sort of error checking that reports that.



 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.
>>
>
> Isn't the obvious check, "do my accounts agree with my bank" ?


The double-entry method does not necessarily provide checks for all
accounts. You can typically only enter balance checks for Assets and
Liabilities accounts, rarely if ever for Income or Expenses accounts (their
lifetime balance generally has no associated external balance counter). So
in the case of small cash expenses that you enter manually, unless you add
explicit balance checks on your "cash" account (e.g., by counting the
dollars in your wallet and entering a corresponding balance check in your
ledger to assert it), erroneous duplicated cash transactions could easily
go undetected. This is the kind of mistake - a mistake in user entry, not
from a bank - that the validation check was intended to prevent you from
making.


[...]

>  About the precision issue, I've already written a proposal doc to outline
>> what the problems are,
>>
>
> as I and other people have noticed, you do that a lot, I hope it makes you
> feel better.


Writing is thinking. The purpose of the documents is to describe a problem
that occurs to become familiar with its various aspects, summarize the
solutions that all the projects have come up with to address it so far,
point out benefits and flaws in all these solutions and to try to propose a
better solution, and then  begin a discussion and reach for feedback from
other developers. Many of the other developers have commented on them, so
it has not been a futile exercise so far. Putting the ideas down also has
helped me understand them better (yes, that makes me feel good).  If you're
not interested in the development aspect of these things, you don't have to
read the proposals.



 and what could be a great solution, which will get
>> implemented:
>> https://docs.google.com/document/d/1MY2JMiiXUmcwsOT0CkiK-fCo0ZE7nbr8uTcT
>> L50b6X4/
>>
>
> oh, you're going to implement it?  great!
>
> what a pity the link doesn't work, but that might be your crap quoting


To "open" a link, bring up a web browser and copy-paste the text of the
link (this is called a "URL") in the location bar. The location bar is the
text field at the top of the window. If you're reading this email from a
web browser and the text is blue, you may also be able to just click on the
blue text with the mouse.



 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.
>>
>
> ok, I guess you'll be just the same place in a year or two's time.
>
> Gour will be no better off and I'll have some nice SQL reports to show.
>

Can't wait to see them.  Please share some great results with us (and some
code!), it would be lovely to compare what the GnuCash community produces
with the Ledgerverse. There's always room to grow I'm sure.

-- 

--- 
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.

Reply via email to