It was a few tenth of seconds, but some of my reports require a few queries so it adds up. I only look back at previous year data once in a very long while and then usually not for numerical information, just to find a particular transaction.
On Sat, Apr 19, 2014 at 1:30 PM, Martin Blais <[email protected]> wrote: > On Sat, Apr 19, 2014 at 3:19 PM, Craig Earls <[email protected]> wrote: >> >> If you are using a separate file for each year, and don't want ledger >> to have to run through all of the files, you need to establish a >> starting point. I had 16000+ postings prior to this year when I >> started anew. Some of the ledger runs that used virtual transaction >> took a lot longer that I liked. > > > How long was that? Why don't you fix that problem instead of putting these > annoying constraints? Given a year prefix, you could fly through the file > as fast as grep does and ignore everything that's not of the year you care > about. I thought that was the whole point of writing this in C++ in the > first place: speed. > > How do you then deal with processing two files together? ... you have > opening balances and closing balances and they cancel each other out? (I > hope you don't have to change anything in a closed year, you'll then have to > manually update all these entries, sounds like a PIA to me). > > I have 7814 transactions, 11259 entries total (including transactions). > The whole thing parses well under a second (C lex/yacc + Python callbacks > parser). > > One difference is that I only parse once and then serve all my reports from > a local web server, so I don't need to re-parse every time, so I don't care > nearly as much about parsing time. Even a one-second hiccup when I change > the file - the web interface automatically detects a modified input file and > reparses by itself on a page reload - is not much of a disturbance. > > > > > >> On Sat, Apr 19, 2014 at 11:42 AM, Martin Blais <[email protected]> wrote: >> > I don't understand why you need to manually insert an opening balances >> > entry. >> > That's something the system should do for you. >> > >> > The way I handle this in Beancount is that you have different "views" on >> > your transactions. A view is a subset of transactions. The most obvious >> > one >> > is "by year", but there are many others (tagged entries, for instance). >> > For >> > each of these views, there are opening balances report (beginning), >> > balance >> > sheet (ending), income statement, and other reports. >> > >> > The input file has all the transactions. You could split this between >> > files >> > if necessary (concat the files before processing, or implement a trivial >> > include mechanism--I designed the syntax to be order-independent to >> > ensure >> > this is easy). The process of creating the subset of transactions for a >> > year >> > view involves replacing all the past transactions with these special >> > "opening balances" entries so that the reports only include that year's >> > transactions, but the generation of the opening balances transactions is >> > an >> > automated process, not something you should have to do manually. You can >> > look at any period of time in the same way, e.g., 3 months in arbitrary >> > dates. Same process applies. >> > >> > >> > >> > >> > >> > On Fri, Apr 18, 2014 at 7:35 PM, Martin Michlmayr <[email protected]> >> > wrote: >> >> >> >> I separate my ledger files by year, so every year starts with a number >> >> of opening balances. >> >> >> >> So far, I've been using statements like these: >> >> >> >> 2014-01-01 * Opening balance >> >> ; :opening-balance: >> >> Assets:Current:Invest 0.00 GBP >> >> Assets:Investments:Invest 2 AAA @ 20.00 GBP >> >> Assets:Investments:Invest 4 AAA @ 30.00 GBP >> >> Equity:Opening balance >> >> >> >> However, I just realized that a downside of this approach is that the >> >> original purchase date is lost. >> >> >> >> So I've come up with this approach: >> >> >> >> 2014-01-01 * Opening balance >> >> ; :opening-balance: >> >> Assets:Current:Invest 0.00 GBP >> >> Assets:Investments:Invest 2 AAA {20.00 GBP} [2012-02-11] @@ >> >> 40.00 GBP >> >> Assets:Investments:Invest 4 AAA {30.00 GBP} [2013-06-06] @@ >> >> 120.00 GBP >> >> Equity:Opening balance >> >> >> >> This shows the information I expect: >> >> >> >> $ ledger bal --lots Assets:Investments:Invest >> >> 2 AAA {20.00 GBP} [2012/02/11] >> >> 4 AAA {30.00 GBP} [2013/06/06] Assets:Investments:Invest >> >> >> >> Is this the best way to model opening balances for shares or is there >> >> a better way? >> >> >> >> The example above looks pretty straight forward, but in reality, the >> >> purchase price has a lot of digits, e.g.: >> >> Assets:Investments:xxx 415.51 "GB0000468776" >> >> {4.4280282063 GBP} [2013-01-04] @@ 1839.89 GBP >> >> >> >> Oh, I guess I could use {{xx}}, as in: >> >> >> >> 2014-01-01 * Opening balance >> >> ; :opening-balance: >> >> Assets:Current:Invest 0.00 GBP >> >> Assets:Investments:Invest 2 AAA {{40.00 GBP}} [2012-02-11] >> >> @@ >> >> 40.00 GBP >> >> Assets:Investments:Invest 4 AAA {{120.00 GBP}} [2013-06-06] >> >> @@ >> >> 120.00 GBP >> >> Equity:Opening balance >> >> >> >> That also gives the expected result. This is the best solution I have >> >> so far. Is there anything better? >> >> >> >> Note that I always have to specify the total amount with @@, otherwise >> >> -B >> >> doesn't work. >> >> >> >> Example: >> >> >> >> 2014-01-01 * Opening balance >> >> ; :opening-balance: >> >> Assets:Current:Invest 0.00 GBP >> >> Assets:Investments:Invest 2 AAA {{ 40.00 GBP}} [2012-02-11] >> >> Assets:Investments:Invest 4 AAA {{120.00 GBP}} [2013-06-06] >> >> Equity:Opening balance >> >> >> >> $ ledger bal Assets:Investments -B >> >> 6 AAA Assets:Investments:Invest >> >> >> >> John, can you confirm that the approach I've taken is correct and that >> >> the >> >> @@ >> >> is always required? >> >> >> >> If I say 2 AAA {{40.00 GBP}}, why cannot ledger figure out the @@ 40.00 >> >> GBP by >> >> itself? >> >> >> >> -- >> >> Martin Michlmayr >> >> http://www.cyrius.com/ >> >> >> >> -- >> >> >> >> --- >> >> 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. >> > >> > >> > -- >> > >> > --- >> > 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. >> >> >> >> -- >> Craig, Corona De Tucson, AZ >> enderw88.wordpress.com >> >> -- >> >> --- >> 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. > > > -- > > --- > 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. -- Craig, Corona De Tucson, AZ enderw88.wordpress.com -- --- 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.
