I only just started with automatic imports and am trying out beangulp after
this thread. Coming from a literal pipe-chain workflow:
cat citi.csv | citi2beans.py | dedup.py >> ledger.beans
I like the scalability and deduplication potential of handling all
statements at once. It seems like much of the importer interface is
opinionated about finding+moving files, but I can't think of many
alternatives (download -> delete below) - just that the core bit I'd
imagine sharing is ofx|csv|etc-to-beans. Having the unit tests baked into
the framework and examples is very helpful to encourage quality in
community code. What about...
Cli flags in import.py? So users don't have to type "--existing
ledger.beans ~/Downloads" every time. import.py already has specific
importers/accounts/parameters, it could at least supply the ledger file -
this might extend to a generic import.py with yaml input config.
Can archive just remove files? ofxget makes it easy to retrieve, I may only
keep novel/representative statements. Or an alternative "delete" command.
Downloading statements? I could see "import.py fetch" calling per-importer
fetch methods to fill the Downloads folder before extract. It would be nice
to extend the importer classes for a simple coupling between fetched files
and identify.
If any of these are "issue worthy" I could add to the repo. Might be able
to hack on statement deletion or import flags myself.
Paul
On Monday, May 20, 2024 at 5:04:13 PM UTC-4 [email protected] wrote:
beangulp is a redesign of the old importers code in Beancount v2. The
main goal of the project has always been to define a API for importers
and to build a minimal framework around it that implements most of the
tedious parts.
The common importers API should have enabled importers to be easily
shared and used in import applications implementing additional features
on top or simply implementing a specific workflow.
Judging from the overwhelming lack of feedback we received, I thing that
the goal has not been met.
On the other hand, implementing an importer is so simple that I am not
surprised that there are multiple projects dealing with importing
transactions into a Beancount ledger.
Personally I use beangulp with some extra functionality bolted on top to
do automatic categorization and some cleanup of the imported
transactions. I use Emacs and some personal tools built on top of
beancount-mode for reviewing the imported transactions. I would never
use a browser based solution because it would always be too slow
compared to working directly in Emacs.
Cheers,
Dan
On 20/05/24 20:59, Timothy Jesionowski wrote:
> So now I'm wondering, since I've got a handful of purely custom
> importers and a whole bunch of new importers to write next quarter, what
> does the preponderance of the community use and why? I've heard of Red's
> importers, beancount-import, and now beangulp. I know there's others. I
> haven't looked at any of them personally yet because I'll need to
> package them for my niche linux distro first (NixOS has /some
downsides/).
>
> Just looking at the github repos:
>
> 1. beangulp was written by the same guy that wrote beancount itself (Hi
> Martin!) so I would expect it to integrate very well.
> 2. beancount-import has a web UI, which seems like a very useful tool
> for verifying all this automation (especially for expense
> categorization, which I'm skeptical can /ever/ be particularly reliable)
> 3. 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
>
> 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
> <https://en.wikipedia.org/wiki/KISS_principle> setup that's exactly as
> messy as it sounds. 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?
>
> Sincerely,
> Timothy Jesionowski
--
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/e03f832c-a30b-46d9-bef2-ca2ea6b1458an%40googlegroups.com.
