Using Zero-Sum-Accounts and smart_importer together?

[cha...@gmail.com]

I'm a fan of using Redstreet's great zerosum plugin to handle transfers, and also use smart_importer in order to speed up the ledger update process.

However, using these together doesn't really work that well since the training data for smart_importer is going to have matched zero-sum transactions, such that the predictions for transfers will be matched zero sum transactions when they are not actually matched.

Is there a suggested way to get these two to work together? One possibility is to take the predictions from smart_importer and just regex so that `ZSA-Matched` changes to `Zero-Sum-Accounts`, i.e., going from matched to unmatched. However when doing this on a large import it seems that zerosum has issues matching all the transactions.

[Red S]

Hello there,
Yes, there is a solution I use. Generally, plugins are meant to be computed dynamically each time. Smart importer predicts (instead of computing) statically. What this means is, we generally always want smart_importer to be fed a ledger on which plugins have not yet run. This is true for most plugins (eg: the capital gains classifier).

My recommendation is to do what I personally do, shown in this script from this article:

# So zerosum doesn't run: both for performance and correctness (smart_importer) if be -f <(echo 'plugin "beancount.plugins.auto_accounts"'; cat ${INGEST_ROOT}/../source/* ) $files ; then echo "Return value of bean-extract: $?" if [[ "$nofile"x != "1x" ]]; then bf $files # bean-file fi fi

Basically, this avoids running zerosum or any plugin at all when building a ledger to pass on to smart_importer. Makes it slightly faster too.

​

[Red S]

In case it wasn't clear what is going on above:

My main.beancount contains:

plugin "beancount_reds_plugins.zerosum.zerosum" "{..}" plugin "beancount_reds_plugins.capital_gains_classifier.long_short" "{...}" ... include "source/Assets.Bank.bc" include "source/Liabilities.Credit-Cards:MasterCard.bc" ...

The script above bypasses main.beancount and instead simply builds a ledger based on the source/*.bc files which is where the actual transactions live. The script prepends plugin "beancount.plugins.auto_accounts" to this ledger to avoid unopened-account errors.

​

[cha...@gmail.com]

That all makes sense, thanks.Is the correct way to use zerosum to just keep all the ledger entries as `Zero-Sum-Accounts` rather than changing them to `ZSA-Matched`? I was doing this to make it easier to track in plain text but I know you can just track transactions in Fava, bean-query, etc.

[Red S]

That all makes sense, thanks.Is the correct way to use zerosum to just keep all the ledger entries as `Zero-Sum-Accounts` rather than changing them to `ZSA-Matched`? I was doing this to make it easier to track in plain text but I know you can just track transactions in Fava, bean-query, etc.

That’s how I use it (retain it as 'Zero-Sum-Accounts'), but I wouldn’t say that’s the only way. My original intent was to include a script to “bake in” the rewrites that one was happy with into the ledger, so they become set in stone, and also for performance reasons. It turned out that neither has been an issue in years (I rewrote zerosum for performance at some point), so I never did the “baking in” part for myself, even though that’s become very easy now with autobean. It’s complexity without a clear payoff IMHO. As you touched upon, I rarely have the need to track my source ledger files because my reporting tools are are highly evolved for my purposes both via Fava and on the command line thanks to Beancount being an extremely scriptable library.

But YMMV, and if you decide to bake things in, you will run into the same issue in your OP around smart_importer. The easy way around this is to use the rename_account plugin to rename ‘ZSA-Matched’ to ‘Zero-Sum-Accounts’ when running smart_importer.

​