>
> I feel like we've added a lot of work (assuming no automation)
>
Agreed. Without automation, it’s probably not worth the effort. In fact,
this whole discussion started with me asking for help with the automation,
and others asking why I would want to do such a thing.
> without solving th
On Thu, Jun 1, 2017, at 06:17 AM, Peter McArthur wrote:
>> 1. This seems to make it no easier to detect and correct errors than
>>a tick mark on your bank statement. To add the final lines you
>>still have to go through the statement line by line.>>
>>
>> 2. There still seems to be no rec
>
> 1. This seems to make it no easier to detect and correct errors than a
> tick mark on your bank statement. To add the final lines you still have to
> go through the statement line by line.
>
> 2. There still seems to be no record tieing your entry to the line item on
> your bank statement.
On Wed, May 31, 2017, at 04:39 AM, Peter McArthur wrote:
> This topic arose in the context of bank reconciliation, so, let’s
> talk about bank reconciliation. The traditional, pen-and-paper way of
> doing it is:
> 1. Go through your accounts and your bank statement, matching them
> item b
> "PM" == Peter McArthur writes:
PM> I'm not experienced with beancount but, so I may have misunderstood you,
PM> but I don't really see what you're getting at. Power and flexibility are
PM> good. The ability to add constraints is also good. They work best when
PM> used together.
I want you
> "o" == o1bigtenor writes:
o> So - -- from your perspective you don't see a value in having something
o> defined that would help with the date paid, date cleared, date issued (more
o> for invoicing) as a specific 'data type' available for use?
Not as part of the internals of Ledger, no. As
Looks like -H is what I need in this case.
Thanks a lot John!
On 30 May 2017 at 21:38, John Wiegley wrote:
> > "VS" == Vladimir Sorokin writes:
>
> VS> I'm trying to generate reports for an account which has transactions in
> VS> different currencies, and I stuck.
>
> Have you tried the -B
On Wednesday, 31 May 2017 18:58:10 UTC+1, John Wiegley wrote:
>
> > "PM" == Peter McArthur > writes:
>
> PM> The manual shows us how unclear the semantics are. Most people seem to
> use
> PM> auxiliary dates as a date when a cheque is *cleared*. But the manual
> also
> PM> shows them bei
On Wed, May 31, 2017 at 12:59 PM, John Wiegley
wrote:
> > "PM" == Peter McArthur writes:
>
> PM> The manual shows us how unclear the semantics are. Most people seem to
> use
> PM> auxiliary dates as a date when a cheque is *cleared*. But the manual
> also
> PM> shows them being used when a c
> "PM" == Peter McArthur writes:
PM> The manual shows us how unclear the semantics are. Most people seem to use
PM> auxiliary dates as a date when a cheque is *cleared*. But the manual also
PM> shows them being used when a cheque is *paid*:
It should be noted here that one of the "features"
Dear Rushad,
Rushad Faridi writes:
> Firs I tried ledger 2.x approach since 3.x can not do the conversion. I
> had not much of a problem installing 2.x but after I issued the command "
> ledger -f myfile.gnucash print > myfile.txt" it spitted out 27 lines of
> error with something "
On Tue, May 30, 2017 at 9:39 PM, Peter McArthur
wrote:
> First I should describe my philosophy.
>
> We’re all computer nerds here, I think, so we all know the value of
> simple, flexible abstractions with strong mathematical underpinnings.
> Relational databases, the lambda calculus, finite autom
12 matches
Mail list logo