Removes potential interpretation of percent signs in various types of
descriptions/notes/labels (otherwise, import may break).
Resolves "fatal: not enough arguments to satisfy format string" under
certain conditions.
BTCPay Server v2.2.0 has a new "Invoices" export format that is more
complex than the prior "Legacy Invoice Export" format.
To help facilitate the transition to the new format, upstream has
provided a plugin for backwards compatibility. However, this plugin
happens to provide additional columns that must be supported.
Additionaly, the "Wallets" format also has new columns with fee
information, so the impl now supports tx fees (prior, fees required
manual input).
The "Wallets" impl also now defaults to a refund expense account for
outgoing txs and adds tax rules & documentation for rationale.
- Fixes broken import of any tx that contains non-alpha character(s) in
its currency (digits, etc.)
* Currencies may now contain any character(s) supported by hledger
- Implements support for unified API via Etherscan V2 (ethereum-based)
* All ethereum-based L2s are now accessed via single API endpoint
- Chains are now available via chain ID
* Updates API key requirement for `fetch` ethereum-based subaccounts
- The API key's value must now be prepended with "etherscan"
* Previously was prepended per-chain ("ethereum" or "polygon")
- The API key is now *required* (can be generated at etherscan.io)
* Resolves fatal error in Etherscan::parse_response()
* Impl will now handle if:
- Config's API key/value is malformed
- Etherscan API key was not given
- Etherscan response is fatal
- Adds support for more L2s
* Arbitrum (One)
* Optimism
* Base
- Adds more L2s to existing accounts
* Coinbase Wallet
* Ledger Live
* MetaMask
- Updates documentation
* Update default generated `fetch` config
* Update `fetch` usage help
* Update README
- Creates per-wallet / per-account compliance for IRS Rev. Proc. 2024-28
- Needed for wallets that may share the same subaccount name on the same
device but are entirely different wallets that support different
networks and/or assets within that network.
- Creates per-wallet / per-account compliance for IRS Rev. Proc. 2024-28
- Needed for wallets that may share the same subaccount name on the same
device but are entirely different wallets that support different
networks and/or assets within that network.
This addition is treading a fine line between finance and other
accounting, as Vultr cloud service is related to DevOps and is also not
a financial entity. However, financial information is provided; so this
addition is useful.
With this commit, a precedent is set for other cloud services to be
added to the repository (services that provide CSV financial accounting
data) and I believe that they could (should) be added as needed.
NOTE: there are several upstream CSV issues:
- Only expenses are given
* Transfers must be added manually (manual import or custom rules)
- Sales tax is not included
* Sales tax expenses must be added manually
If electrum-provided prices aren't available, 'No Data' will be given.
Attempts to calculate this string will result in 0.00 for fiat values.
Do not attempt to calculate this string. Instead, leave the column empty
(for bitcoin.tax calculations).
Issue #51 describes at least a few undocumented bitcoin.tax issues:
- Bicoin.tax gives unexpected cost-basis results when `Fee` is given
with `Total` (when `Total` is given in place of `Price`). The
expectation is that bitcoin.tax will perform the cost-basis
calculation on `Total` when `Fee` is also given.
However, bitcoin.tax *will* give expected cost-basis results if
`Price` is given in place of `Total` (with `Fee` also given) *or* if
`Total` is given *after* local cost-basis adjustments are made (but
*without* `Fee` given).
The rationale for why docker-finance doesn't use `Price`:
* docker-finance has all of the `Total`s; so `Price` isn't
necessary.
* Local price information isn't available for most trades (and
shouldn't be necessary since all `Total`s are available).
- Additionally, when `Fee` is non-fiat (crypto), it now must be marked
as a SPEND in order to be disposed (and to produce an accurate
closing report).
- Finally, if `FeeCurrency` *does* not match either `Symbol` or
`Currency` (e.g., BTC-ETH w/ BNB fee), it's unknown if cost-basis
must be calculated locally as well (if `Total` is given). Local
calculations cannot be done because `Fee` price information is
(almost certainly) not available for this type of trade.
Until upstream can assert that attaching the `Fee` will subsequently
adjust the cost-basis of `Total` *and* dispose of the `Fee` in the
process (while also allowing `Total` to be used in place of `Price`),
the `Fee` (and `FeeCurrency`) column(s) must not be populated and values
instead moved to SPEND (as described above).
Upstream is aware of these issues (since May) and they're in the process
of resolution. In the meantime, docker-finance work-arounds should
suffice for all trades that have a fiat `Fee` and/or a
`Fee`/`FeeCurrency` that matches one side of the trading pair.
Issue #51 describes at least a few undocumented bitcoin.tax issues:
- Bicoin.tax gives unexpected cost-basis results when `Fee` is given
with `Total` (when `Total` is given in place of `Price`). The
expectation is that bitcoin.tax will perform the cost-basis
calculation on `Total` when `Fee` is also given.
However, bitcoin.tax *will* give expected cost-basis results if
`Price` is given in place of `Total` (with `Fee` also given) *or* if
`Total` is given *after* local cost-basis adjustments are made (but
*without* `Fee` given).
The rationale for why docker-finance doesn't use `Price`:
* docker-finance has all of the `Total`s; so `Price` isn't
necessary.
* Local price information isn't available for most trades (and
shouldn't be necessary since all `Total`s are available).
- Additionally, when `Fee` is non-fiat (crypto), it now must be marked
as a SPEND in order to be disposed (and to produce an accurate
closing report).
- Finally, if `FeeCurrency` *does* not match either `Symbol` or
`Currency` (e.g., BTC-ETH w/ BNB fee), it's unknown if cost-basis
must be calculated locally as well (if `Total` is given). Local
calculations cannot be done because `Fee` price information is
(almost certainly) not available for this type of trade.
Until upstream can assert that attaching the `Fee` will subsequently
adjust the cost-basis of `Total` *and* dispose of the `Fee` in the
process (while also allowing `Total` to be used in place of `Price`),
the `Fee` (and `FeeCurrency`) column(s) must not be populated and values
instead moved to SPEND (as described above).
Upstream is aware of these issues (since May) and they're in the process
of resolution. In the meantime, docker-finance work-arounds should
suffice for all trades that have a fiat `Fee` and/or a
`Fee`/`FeeCurrency` that matches one side of the trading pair.
Issue #51 describes at least a few undocumented bitcoin.tax issues:
- Bicoin.tax gives unexpected cost-basis results when `Fee` is given
with `Total` (when `Total` is given in place of `Price`). The
expectation is that bitcoin.tax will perform the cost-basis
calculation on `Total` when `Fee` is also given.
However, bitcoin.tax *will* give expected cost-basis results if
`Price` is given in place of `Total` (with `Fee` also given) *or* if
`Total` is given *after* local cost-basis adjustments are made (but
*without* `Fee` given).
The rationale for why docker-finance doesn't use `Price`:
* docker-finance has all of the `Total`s; so `Price` isn't
necessary.
* Local price information isn't available for most trades (and
shouldn't be necessary since all `Total`s are available).
- Additionally, when `Fee` is non-fiat (crypto), it now must be marked
as a SPEND in order to be disposed (and to produce an accurate
closing report).
- Finally, if `FeeCurrency` *does* not match either `Symbol` or
`Currency` (e.g., BTC-ETH w/ BNB fee), it's unknown if cost-basis
must be calculated locally as well (if `Total` is given). Local
calculations cannot be done because `Fee` price information is
(almost certainly) not available for this type of trade.
Until upstream can assert that attaching the `Fee` will subsequently
adjust the cost-basis of `Total` *and* dispose of the `Fee` in the
process (while also allowing `Total` to be used in place of `Price`),
the `Fee` (and `FeeCurrency`) column(s) must not be populated and values
instead moved to SPEND (as described above).
Upstream is aware of these issues (since May) and they're in the process
of resolution. In the meantime, docker-finance work-arounds should
suffice for all trades that have a fiat `Fee` and/or a
`Fee`/`FeeCurrency` that matches one side of the trading pair.
Issue #51 describes at least a few undocumented bitcoin.tax issues:
- Bicoin.tax gives unexpected cost-basis results when `Fee` is given
with `Total` (when `Total` is given in place of `Price`). The
expectation is that bitcoin.tax will perform the cost-basis
calculation on `Total` when `Fee` is also given.
However, bitcoin.tax *will* give expected cost-basis results if
`Price` is given in place of `Total` (with `Fee` also given) *or* if
`Total` is given *after* local cost-basis adjustments are made (but
*without* `Fee` given).
The rationale for why docker-finance doesn't use `Price`:
* docker-finance has all of the `Total`s; so `Price` isn't
necessary.
* Local price information isn't available for most trades (and
shouldn't be necessary since all `Total`s are available).
- Additionally, when `Fee` is non-fiat (crypto), it now must be marked
as a SPEND in order to be disposed (and to produce an accurate
closing report).
- Finally, if `FeeCurrency` *does* not match either `Symbol` or
`Currency` (e.g., BTC-ETH w/ BNB fee), it's unknown if cost-basis
must be calculated locally as well (if `Total` is given). Local
calculations cannot be done because `Fee` price information is
(almost certainly) not available for this type of trade.
Until upstream can assert that attaching the `Fee` will subsequently
adjust the cost-basis of `Total` *and* dispose of the `Fee` in the
process (while also allowing `Total` to be used in place of `Price`),
the `Fee` (and `FeeCurrency`) column(s) must not be populated and values
instead moved to SPEND (as described above).
Upstream is aware of these issues (since May) and they're in the process
of resolution. In the meantime, docker-finance work-arounds should
suffice for all trades that have a fiat `Fee` and/or a
`Fee`/`FeeCurrency` that matches one side of the trading pair.
