On Monday, November 30, 2020 at 11:26:13 PM UTC-5 [email protected] wrote: > On Mon, Nov 30, 2020 at 5:12 PM Aaron Lindsay <[email protected]> wrote: > >> I've been working on automating some accounting tasks lately and am >> curious for feedback from others on my approach, or ideas for doing it >> better in the future. >> >> I really dislike manually organizing my ledger file. I do still want to >> look over incoming transactions, but ideally would like everything else to >> be automated for me - I'd like transactions to be uniformly formatted and >> ordered. `bean-format` can take care of most of the former, but I've been >> using `bean-query example.beancount print` (wrapped in a shell script to >> preserve the options and remove trailing spaces) to do the ordering for me. >> This isn't ideal since it's actually modifying the ledger in the process. >> It seems like there are more possibilities for programmatically managing >> your .beancount file, too: I can imagine keeping prices separate from >> transactions, maybe automatically moving transactions for certain accounts >> to their own file, etc. >> >> Is there a better way to programmatically rewrite ledgers by hooking into >> pieces of the beancount internals today? If not, will v3 have any impact on >> this? I'm looking at the "Intermediate Parsed Data vs. Final List of >> Directives" section of the v3 document, but am not sure I grok the >> beancount internals enough to understand the implications there, if any. >> > > You cannot reinsert the output of "bean-query print" back into the Ledger, > it's just not designed to work that way, that will not work. There's the > input syntax, Beancount parses that, and then makes changes to the > transactions, some which are dependent on the state of the inventories just > before it (chronologically, e.g., matching cost specs to available lots). > In fact, if anything in v3 the introduction of currency trading accounts > and transfer accounts (for postings from a single transaction at different > dates) will make that distinction even more pronounced, as a single > transaction will often result in multiple transactions realized in the > output stream. It may look like they're the same because the data types > coming out of the parser are also reused for the final realization (they're > close enough), but they're different. One is the straightforward > translation by the parser of what it read to a data structure--its AST, if > you will-- an incomplete, partially filled and yet-to-be booked and > interpolated and processed directives, and the other is the final result > after all the work is done, which you be summed up to compute inventory > states. With "bean-query print" you're producing the final result, not a > 1:1 translation of the input. >
Well, it does sort of work - I've been doing it for a few weeks now, for better or for worse. But as you mention, it *does* make things more explicit than they were in the input text. I got started down this path because I didn't have cost basis from a GnuCash import and thought running it through `bean-query print` was the most expedient way to convert those accounts from FIFO to STRICT. Maybe I should've just stuck with FIFO, I don't know... In either case, I'm definitely not arguing that `bean-query print` is ideal. I'd love a better solution. > What you may be able to do instead is manipulate the input text. But in v3 > I'll provide both beginning and end lines as part of all directive data, so > that should allow you to break apart your file cleanly, using the same > parser used for processing. Also, I could easily provide some library > function to accept a file and produce a mapping of > > (parser-directive, text) > > whereby the parser directive is the unprocessed, > straightforward translation of your input text to the intermediate data > structure, which you could more easily inspect and reason about - keeping > in mind that some of the fields may be unset,e.g. if you leave out a number > to be interpolated -- in order to decide where to reinsert the > corresponding text in your output file. Please file a ticket if this would > be useful. I'm in the process of rewriting the parser in C++ (almost done > actually). > I do think this would be useful - I'll try to write it up. How would user code hook into beancount to get this listing? Would there just be a parser function call to be imported and called via arbitrary python that would return a list of these tuples? > One question that will remain is what to do with comments immediately > preceding and/or following a transaction. Those are often associated with > the transaction and slicing and dicing files to put them back together > should probably preserve the comments like that. I'd have to inject > comments into the grammar in order to do that (that may not be trivial). > I can see an argument for pushing the burden of dealing with comments back onto whoever uses such a feature. I think that would mean simply providing them in the same format as non-comments, perhaps keeping everything in the order it appears in the input. User code can decide how to associate them (maybe always to the first subsequent non-comment, maybe fancier heuristics like the 'closest' non-comment when taking newlines into account, etc.). To Justus' point, though, I don't know how that would work for comments which are part of other transactions. Or maybe you're proposing that such comments would be preserved in the `text` portion of `(parser-directive, text)` for that transaction? Thanks! -Aaron -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/822b1943-1fa3-4129-9192-081128337324n%40googlegroups.com.
