On Tue, Jul 1, 2014 at 9:50 AM, Simon Michael <[email protected]> wrote:
> On 6/30/14 9:55 PM, John Wiegley wrote: > >> Martin Blais <[email protected]> writes: >>>>>>> >>>>>> Sure, but then a transaction that does nothing would appear in the >>> register, >>> no? >>> >> > I feel sympathetic to Martin here - a separate directive seems more > orthogonal. Postings are already expressing quite a lot. > I also like the flattening of all directives to have a single meaning. And it keeps transactions simpler, as you say. Though, if not taking journal order into account I would have processed it > last, after any transactions on that day. > I used to feel the same, but I needed both. Then I had a plan for a "balance_end" directive that would apply at the end of the day (otherwise same semantics). Then I realized I did not need it at all, I just fudge the date manually to the next day. I chose the beginning of the day to be consistent with other date ordering things (can't remember now). >From a technical perspective, this would be trivial to add back, BTW, they would just be converted into "balance" directives with date + 1, it could even be done by the parser itself. I'm not convinced adding one more directive is worth it though. What do you think? If taking order into account, which I wouldn't mind doing - h/ledger do it > elsewhere - the separate directive would be just as expressive as the > current scheme, no ? More so, as it would never introduce dummy > transactions and requiring -E to hide (possibly disturbing your report in > other ways). > I feel that ensuring the property that "order does not matter" simplifies the semantics of a ledger quite a bit, I think it's quite an important guarantee. If you have multiple transactions on the same day, I'm not sure what a balance assertion on a posting means; surely it does not mean "the balance at the end of the day of the posting of this transaction" but rather "the balance right after processing this transaction" which appears to happen in file order (in Ledger). Now, because of this, if you reorder your directives, e.g., you insert a new directive before one that has a balance assertion on a posting that affects an account with another assertion on the same date, it might break a balance assertion that had previously been working. Wow, that was a mouthful. So let's take a concrete example instead, let's say you're organizing transactions by section (in this example: credit card transactions and checking account transactions), the following will not generate an error in Ledger, it works: ;; Credit card account 2014/05/01 opening Liabilities:CreditCard $-1000.00 Expenses:OpeningBalances 2014/05/12 dinner Liabilities:CreditCard $-74.20 Expenses:Restaurant ;; Checking account 2014/06/05 salary Assets:Checking $4082.87 Income:Salary 2014/06/05 cc payment Assets:Checking $-1074.20 = $3008.67 Liabilities:CreditCard = $0 If I had instead decided to put the credit card payment in the credit card account section (same set of transactions, I just moved it), this fails (try it): ;; Credit card account 2014/05/01 opening Liabilities:CreditCard $-1000.00 Expenses:OpeningBalances 2014/05/12 dinner Liabilities:CreditCard $-74.20 Expenses:Restaurant 2014/06/05 cc payment Assets:Checking $-1074.20 = $3008.67 Liabilities:CreditCard = $0 ;; Checking account 2014/06/05 salary Assets:Checking $4082.87 Income:Salary mandarine [default]:~/p/ledger-experiments$ ledger -f ordering1.lgr reg checking While parsing file "/home/blais/p/ledger-experiments/ordering1.lgr", line 13: While parsing posting: Assets:Checking $-1074.20 = $3008.67 ^^^^^^^^ Error: Balance assertion off by $4082.87 I much prefer if I don't have to worry about where things are. And this is not an uncommon pathological case. For example, I place my salary income transactions in their own section, though they get paid via direct deposit to my checking account. It is not uncommon that other entries appear in the checking account on pay day. So with balance assertions on real transactions, whether the balance assertion would work or not would depend on whether it is placed on transaction that will appear last in the ledger file. I don't want to have to think about this. IMHO, when designing this, the question you have to ask yourself is: where do the balance amounts you report come from? Usually they come from some statement, you copy the value from the line on your statement which says "your balance on YYYY/MM/DD is X". OFX also has a field that tells you the current balance of the account you just downloaded at the current date (you can convert that to a balance assertion automatically, has no transaction associated to it as the date is often several days after the last transaction). My point is: where those amounts come from often has a separate date from transactions. So with current Ledger semantics, how do you make it order-invariant? One way to be certain it will always work would be to 1) always make balance assertions on dedicated (empty) transactions 2) place all assertions at the end of your file, after all transactions. This is not practice, but it should always work and should allow you to reorder all transactions at will. Choosing to define balance assertions on their own removes _just_ enough degrees of freedom that it makes it unambiguous and order-invariant. I think you could easily do the same thing in Ledger, in fact, this _may_ be the only thing that is needed to make Ledger's balance assertions order-invariant. That would a really nice property to have IMO, and relatively easy change. If the posting-based assertions do remain, then hledger will probably go > ahead and add == to assert against the full multi-commodity amount. How do you plan to disambiguate for the case I point out above? -- --- 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.
