-
Notifications
You must be signed in to change notification settings - Fork 39
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
Comments
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 |
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 |
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
This way, the currency is set just once at the top. |
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.)
The text was updated successfully, but these errors were encountered: