On Mon, Apr 27, 2015 at 9:57 AM, Michael Iles <[email protected]> wrote:
> (Background: in the process of moving from GnuCash; my main draw to ledger > is #1 the balance assertions, and #2 that it fits into a typical Linux > toolchain, especially that I can use source control for data files.) > > I don't know if this is best practice (feedback welcome!) but my current > approach to import new transactions is to put them in a file which includes > my previous ledger file, and then do 'ledger -f old.ledger --sort d --empty > print > new.ledger' to create a new ledger with everything in the right > order. > > I'm using a lot of balance assertions because I frequently refactor old > transactions. > Ditto here. I'm using balance assertions liberally, and I love the ability to fix things in the past where I need to! It's a really powerful idea. I think other types of constraints should be added eventually, e.g. "check that the value of this account never goes under zero" for example, or that accounts should never be allowed to contain two lots of some commodity with differing signs. > I found that balance assertions require the ledger to be fully sorted, so > I can't avoid this rewriting step. > This is an unfortunate consequence of Ledger's processing model IMO (it processes postings in file order in order to run a single pass over the data). You may want to read this thread, which had a discussion about this in the past: https://groups.google.com/d/msg/ledger-cli/vwkrPh74NFI/foXlCRxXO7IJ I discuss two different types of balance assertions here: http://furius.ca/beancount/doc/proposal-assertions In particular, Beancount and Ledger differ on this matter; Ledger processes postings in line order (AFAIK this is purely for efficiency), where Beancount sorts all types of entries (transactions, balance assertions and all others types) by date+line order before processing verifications (to ensure semantics that are independent of declaration ordering). > I found this refactoring to be very painful in GnuCash precisely because > it doesn't have the ability to do balance assertions, so anytime the > current balance didn't line up I would have to do a laborious binary search > through the account history to figure out where things went wrong. > Without balance assertions and a significant amount of automated verification my experience it that is simply impossible to enter even just a few years of data without making many mistakes. The level of verification and error-detection you will gain from command-line accounting is potentially much higher. As an example, check out this recent feature I've added to automatically detect a class of errors in entering stock transactions: https://groups.google.com/d/msg/beancount/5u-xgR-ttjg/ytpZH8EAtkMJ My problem now is that balance assertions aren't preserved when using > 'print'... so my rewriting step doesn't work because it doesn't preserve > all the information in the ledger. > > What should I do? Is there a flag similar to '--empty' that will tell > ledger to preserve the balance assertions? This would actually be a > showstopper for me, if I was unable to import new transactions and still > preserve old transactions. > My take on this is that you should never have to manipulate your source that way. Source should be pristine, and as your input grows you will want to have lots of comments in there and possibly some organizational structure as well. In particular, you can use org-mode or some other outline mode to segment your transactions in a way that makes sense to you, e.g. by account. This makes manual updates a lot nicer and your input file significantly more readable. Sorting undoes that nice input file, it's not a great compromise. IMO the semantics of the software should be adjusted to match the expectation of the user. This is what I do in Beancount and why I provide dated assertions. No file rewriting is ever necessary. File-based assertions will be added at some point, but IMO they're superfluous (I'll do it because they're so easy to add, and maybe it'll add some more semantic level of portability between Ledger and Beancount). The only drawbacks of dated assertions is that they can only occur at the beginning of a day, so (1) you may have to fudge/increment a date here and there, and (2) you won't be able to correctly do intra-day assertions where amounts are posted before and after the assert. Beancount explicit limits time representation to dates (I really wanted to squeeze the design to optimize for simplicity) and while at first sight this may sound like a potential problem, in my experience this limitation has never been a real issue: cases where you'll really have to skip a balance assertion are quite rare in practice. -- --- 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.
