On 8/2/13 2:46 PM, John Wiegley wrote:
rob g <[email protected]> writes:
With the following example (similar to the documentation example [1])
2013/08/01 Adjustment
Assets:Cash = $10
Equity:Adjustments
2013/04/01 Stuff
Expenses:Stuff $10
Assets:Cash
2013/01/01 * Opening Balance
Assets:Cash $40
Equity:Opening Balances
I expected to have $10 in Assets:Cash, but I get
Can you explain why you thought that? Here's where the $40 comes from:
You set the balance of Cash to $10.
You transferred out $10, now it is 0.
You added $40.
Therefore, the balance is $40.
It is the sequence of transactions that matters, not their date ordering.
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.
Secondly I wonder if intra-day/intra-transaction balance assertions and
(especially) balance assignments are causing more complexity than they
are worth. If ledger already has an inter-transaction (or maybe it's
inter-day) balance assertion (the check directive), do we also need the
per-posting balance assertions (POSTINGAMT = ASSERTEDAMT) ? And should
we move balance assignments to an inter-transaction directive also ?
Transactions/journal entries already have a job to do: represent a
movement of funds between accounts. Assertions/assignments are
semantically different.
If per-posting balance assertions/assignments do remain in the file
format, I have the feeling I'll need to disallow some cases like
multiple assignments to the same account within a transaction.
--
---
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.
