On Tue, Aug 6, 2013, at 3:49, Christophe Rhodes wrote:
> Simon Michael <[email protected]> writes:
>
> > I have to say, this explanation makes no sense to me. In general I
> > expect *ledger to use the dates I've provided to model the order of
> > events. So far this has worked pretty well for me. I think it's an
> > important property; without it I'd feel like the tool is fighting me
> > rather than assisting.
>
> Which dates? The ledger format allows for multiple dates (primary,
> auxiliary, maybe others). In one ordering, a balance assertion (I don't
> use assignments) may be accurate; in another ordering, say by auxiliary
> date, the balance assertion may well be wrong.
I removed auxiliary dates in Beancount v2 for this very reason.
Less is more... and I never had a really good use for auxiliary
dates anyhow. There are two cases where this issue arises:
1. Credit card transactions with transaction and settlement dates
(settlement is usually a few days after the transaction)
2. Inconsistent reporting for transfers between institutions.
For (1), electing to use the settlement date works just fine in practice.
You do lose the transaction date, so if you use this as a way to remember
where you did something, I guess you can still use a comment.
For (2), I think it makes more sense to be able to associate an optional
date to each posting, but I haven't quite found the desire to implement
the complexities that arise with transient inconsistencies (i.e.,
implement this by transferring transient amounts to some "limbo" account).
This is needed only if you want to be strict and have the correct date
that happens on each side's external statement (often-times the
dates differ). If I don't have any assert in between those dates, there
is no problem; otherwise I just move the assert outside those dates
(very rare).
>
> Balance assertions by parse order work reasonably well when the
> transaction order is the bank's and the assertion is the bank
> statement's balance, or when the transaction order is from
> stubs/receipts and the assertion is from some other kind of summation.
> But since ledger permits essentially arbitrary reordering, the balance
> assertions can't work in all orders: one has to be chosen. Given this,
> parse order doesn't seem to be too unreasonable.
The ordering issue doesn't make sense to me. A transaction has multiple
postings; if you organize your postings "by account", some postings
will invariably have to be placed in one account's section over
another, which may be before or after it. There's no guarantee that
you can always find an ordering that works.
--
---
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/groups/opt_out.
