Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Fallback to defined operating_currency #105

Open
hlieberman opened this issue Jul 27, 2024 · 3 comments
Open

Proposal: Fallback to defined operating_currency #105

hlieberman opened this issue Jul 27, 2024 · 3 comments

Comments

@hlieberman
Copy link
Contributor

Currently, when there's no currency defined at the transaction level or account level, we fall back to CURRENCY_NOT_CONFIGURED. While this is certainly the safest course of action, for csv importers in particular, this is likely to require a lot of redundant currency declarations in each importer.

Beancount already has the concept of an operating_currency, which we could reuse to act as a fallback currency. It seems likely to me that the average beancount user is likely to be using only a single currency, though I have no actual justification for this belief.

Thoughts? (I can easily write the patch to do this, but I didn't want to do so before checking the idea out.)

@redstreet
Copy link
Owner

I like this. Even though this may not be correct in 100% of the case, like you said, good design solves well for frequently used cases and results in an excellent out of the box experience. A patch would be welcome. We can call back on CURRENCY_NOT_CONFIGURED if operating_currency is not defined. Thank you!

@hlieberman
Copy link
Contributor Author

I've been taking a look through how we can access the underlying beancount configuration, and unfortunately it doesn't look like there's a super good way to do it. I could do the same kind of ugly hack that is done in file_account using inspect -- but looking at the v3 branch of upstream, they've totally redone the configuration handling there. I think we should probably hold this feature back until after we've completed the v3 migration in #103.

@redstreet
Copy link
Owner

redstreet commented Aug 4, 2024

Ah yes, I forgot that we can't assume we have access to the beancount ledger from within the importer, as the ledger is not required for the import process.

Now I recall this is why I have the currency setup the way it is. My bad I didn't think of this when responding earlier, sorry!

FWIW, this is how my bean.import looks like:

def bank(importer, acct, config_overrides={}):
    account_number = acct[-4:]
    config = {
        'account_number'  : account_number,
        'main_account'    : acct,
        'currency'        : 'USD',
        'balance_assertion_date_type': 'last_transaction',
        }
    return apply_hooks(importer.Importer({**config, **config_overrides}), [PredictPostings()])

CONFIG = [
  bank(schwab, 'Assets:Bank:Schwab-xx0123'),
  ...
]

This way, the currency is set just once at the top.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants