Nice question.
red’s importers has the most active community by far, and seems to focus heavily on a “run the script every time you look at the reports” workflow The purpose of reds_importers is to make writing importers easy by factoring out the most laborious parts. It actually uses beangulp*, and is simply a higher level layer over it. reds_importers doesn’t impose any particular workflow outside beangulp’s, but if you are referring to this script <https://reds-rants.netlify.app/personal-finance/putting-it-all-together-into-a-workflow/>, that’s only a reference workflow presented to inspire and jumpstart people new to Beancount, importers, or scripting. The sample script <https://gist.github.com/redstreet/6f1addb87c667826fb79b509d5d88a51> is a simple layer that calls beangulp’s bean-identify, bean-extract, and bean-file, which you can do yourself too. The idea is to have you build a workflow that works for you (including, for example, verifying smart_importer's categorization). I wrote reds_importers originally because I wanted to eliminate a lot of repeated code in importers. The fundamental idea is, all any importer should do is handle quirks in the input file, and map data columns to standard fields. Everything else should be handled by a common transaction builder, which exist for investment accounts, banks/credit cards, and paychecks. A few other problems were also solved along the way: - readers + common functions to manipulate (single and multi-table) csvs, pdfs, xml, json, etc. (libreader) - a set of utilities: bean-download (for direct downloads, and determining what to download), ofx-summarize (for peeking into ofxs) - Balance assertions and several options for dating these So for each importer, you simply specify a reader and a transaction builder, and then express only the quirks and field mapping. reds_importers follows the standard approach of relying on other tools to do what they do well (eg: ofxparse, petl, beangulp, smart_importer for categorization, etc.), which lends itself to building your own automation workflow. I don’t have unit tests on my importers, and I’m importing from CSV’s because I just got the simplest thing working. It’s a KISS setup that’s exactly as messy as it sounds. You probably already noticed the advantage of beangulp, which has a framework to write unit tests. Which reds_importers also uses. So given that I need to do an overhaul anyways, I’m curious why, for example, James doesn’t use red’s scripts. Is it just that a fully automated setup is harder to build? The peace of mind from looking at the web UI to verify stuff? I’d be curious too. Mini rant: I’d love for anyone who writes an importer to come to the same realization Felipe did, and *write it using the beangulp API*. This makes workflow and testing integration far easier for other users not to mention pulling it into higher level import systems like reds_importers, beancount-import, and such. Of course, consider writing importers for reds_importers, beancount-import and so on, but of course, these are third-party projects, so I understand if you don't. I’m guessing this is not as common because most either aren’t aware of beangulp’s existence or perhaps because it *seems* like a barrier to understand the API and work with it. As Felipe discovered, it’s actually very simple. **Technically, it uses the importers code in Beancount v2: bean-{identify, extract, file}, because beangulp has no release right now. But for the purposes of this discussion, these two are practically the same, and I refer to the v2 importers code as beangulp.* -- 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 beancount+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/16aac21d-4e9e-4413-89d7-759243bc0cdan%40googlegroups.com.
