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).
Since inception, the intent was to abstract the "interface" to allow for
a general-purpose CLI accounting ledger. However, there appears to be
confusion about whether the underlying implementation is `ledger`
accounting software or `hledger` accounting software.
So, making it clearer that it's `hledger` accounting software (although,
will continue to keep the `ledger` command for backwards-compatibility).
Since inception, the intent was to abstract the "interface" to allow for
a general-purpose CLI accounting ledger. However, there appears to be
confusion about whether the underlying implementation is `ledger`
accounting software or `hledger` accounting software.
So, making it clearer that it's `hledger` accounting software (although,
will continue to keep the `ledger` command for backwards-compatibility).
- Implements support for docker-finance C++ plugins
- Adds shell command execution wrapper
- Refactors previous loader path
* A './' path is unnecessary and will break calls to '/' path
- Adds plugin type support
* Adds pseudo-paths to help usage
* Adds arg parsing of given plugin name
- Prepended pseudo-paths will use repo or custom plugin
- Generates new custom plugin directory layout upon `gen`
* Allows for drop-in client-side/container-side custom plugins
- Moved container plugin example into container's plugins
* Plugin is no longer generated upon `gen` (it's available in-repo)
- Updates plugin example
- Provides requisite lib_finance initialization
- Refactored, added more checks
- Expand example case
- Linter fixes
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.
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.
