> > I'm evaluating switching to the native beancount importer protocol vs > beancount-import so this is a great example to draw on. >
Great! I'm open to developing beancount_reds_importers <https://github.com/redstreet/beancount_reds_importers> to be a mature importer. Feel free to send PRs if my importers work for you. I find importers to be among the most painful things to get right, given a) shared testing is difficult because data files are personal, b) institutions are inconsistent in their use of ofx, and wholly unrestrained with csvs, and c) institutions occasionally change their formats. Separating transaction building from file reading has helped me contain at least the latter two problems. > beancount-import to me has these pros: > I tried beancount-import a while ago. I liked its comprehensiveness. beancount_reds_importers <https://github.com/redstreet/beancount_reds_importers> has a contrasting philosophy: to do one thing and do it well, with minimal code. So I rely upon other software to do some of the things you mention below. I can see both approaches being valid ways. - I like the web UI for interactive import and for its ability to propose > joins between different sources generating two different halves of a > transaction. > I use my zerosum <https://github.com/redstreet/beancount_reds_plugins/tree/master/beancount_reds_plugins/zerosum> plugin for the same thing. The two halves simply post to a common "zerosum" account, where they are resolved. > - Nice deduplication support > I run into the need for deduplication in two cases: 1) already imported transactions: beancount already has this inbuilt for importers, which I rely on 2) deduping two halves of a transaction as you mentioned above: I use zerosum <https://github.com/redstreet/beancount_reds_plugins/tree/master/beancount_reds_plugins/zerosum> for it, but v3 has a proposal to render all this moot by allowing the two halves to be declared separately, as you may be aware > - Ability to see transactions that are uncleared - that is those you've > imported the other half of but the 'authoritative' source hasn't seen it > yet. > Zerosum <https://github.com/redstreet/beancount_reds_plugins/tree/master/beancount_reds_plugins/zerosum> also does this naturally: Postings that haven't seen the other half end up in the zerosum account that you specify. I have my zerosum account under "Assets:Zerosum:<...>", and set them to auto-expand in Fava so I can catch uncleared transactions, but not have to fix them until they "clear" in a future import. Meanwhile, since they appear in my account tree, my net worth is correct (eg: a transfer that has not "landed" yet appears in Assets:Zerosum:Transfers until it lands on the other side). > Downsides: > - The ML prediction algorithm is overly broad in what it considers for > training examples, leading to poor results > <https://github.com/jbms/beancount-import/issues/92>. Hopefully > smart_importer is better about this, I plan to evaluate it. > - It's built around the idea that you'll use web scrapers / tools to > download all the files into the correct directories. Scrapers are the most > brittle part of my infra so I manually download many of my accounts > instead. For that, the beancount importer tooling is a great fit. > I have a bunch of code automating downloads. It's dirty and not release-friendly, but I plan to share it at some point. -- 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/6b3cbd85-a716-4fd6-9bf3-0dffe48f4e85n%40googlegroups.com.
