scoobs
/
cryptools-mirror
mirror of https://github.com/scoobybejesus/cryptools.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Clarified input file writeup.

This commit is contained in:
scoobybejesus 2020-01-18 11:18:41 -05:00
parent 2a8080e0ad
commit e28fc5b3be
1 changed files with 33 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
InputFile_CSV.md
View File

@ -4,7 +4,7 @@ The key to understanding how to use this software is to understand the input fil
This document aims to tell the user all they need to know.
Note: the input file is needed in the *current* version of the software.
Future versions may store the transactional activity in a database or similar file.
Future versions may store the transactional activity in a database or similar file (though there are no current plans for this).
At that time, it may be that additional transactions are entered directly into the software.
For now, however, additional transactions must be added to the input file,
and then the input file is imported ***in full*** every time the software is run.
@ -12,8 +12,7 @@ and then the input file is imported ***in full*** every time the software is run
## Preface
`cryptools` is a command-line utility that does not store data.
It is not a bookkeeping tool.
It does not store your transactions in a persistent ledger.
It is not a full-featured bookkeeping tool that stores your transactions in a persistent ledger.
You cannot open the software later, load the ledger, and enter new transactions.
Rather, you must maintain the input file outside of `cryptools`.
@ -22,8 +21,8 @@ Once you have added new transactions to the input file and wish to view updated
you must run the software again and import the recently-updated input file.
New reports will be generated at that time.
When `cryptools` runs, it imports the input file, it processes the transactions, and it prints reports.
The transaction reports reflect income, expenses, realized gains, and realized losses.
When `cryptools` runs, it imports the input file, processes the transactions, and prints reports (all, or those you choose).
The transaction reports reflect income, expenses, realized gains, and realized losses (and holding period).
At a minimum, the account reports reflect account balances and cost basis of holdings.
Some account reports reflect *all* movements in *every* lot in *every* account, including tracking of cost basis and more.
@ -32,7 +31,7 @@ Once the software has run, you rely on the reports to tell you everything you ne
### Why should I go to the trouble?
Think about this: exchanges have **no way** to track the cost basis of their users' holdings,
Think about this: cryptocurrency exchanges have **no way** to track the cost basis of their users' holdings,
nor can they verify how the funds they disburse are used.
At most, an exchange will be able to provide the gross value of their transactions (what `cryptools` calls `proceeds`).
If exchanges provide a user's trading activity to the IRS, for example, gross value is all they can provide.
@ -56,7 +55,7 @@ Even so, preparing and maintaining the input file is **not** very complicated.
There are a small, limited number of rules to follow, and that's it.
The truth is that the input file is simple to maintain once it is brought current and kept current.
#### Rules of the input file
### Rules of the input file
The rules for successfully preparing and maintaining the input file can generally be summarized as follows:
@ -79,22 +78,22 @@ In order to be successfully imported, the CSV input file **must** be in a prescr
|txDate |proceeds|memo |1 |2 |3 |4 |5 |
|-------|--------|--------|------|--------|-------|--------|------------|
|-------|--------|------------|------|--------|-------|--------|------------|
| | | |Bank |Exchange|Wallet |Exchange|Simplewallet|
| | | |USD |BTC |BTC |XMR |XMR |
| | | |non |non |non |non |non |
|2/1/16 |0 |FIRST |-220 |0.25 | | | |
|3/1/16 |250 |SECOND | |-0.25 | |180 | |
|4/1/16 |0 |THIRD | | | |-90 |90 |
|5/1/16 |0 |FOURTH | | | |90 |-90 |
|5/2/16 |160 |FIFTH | |0.3 | |-90 | |
|6/1/16 |0 |SIXTH | |-0.3 |0.3 | | |
|7/1/16 |200 |SEVENTH | |0.7 | |-90 | |
|8/1/16 |0 |EIGHTH | |0.3 |-0.3 | | |
|9/1/16 |400 |NINTH | |-0.5 | |200 | |
|10/1/16|900 |TENTH | |1 | |-200 | |
|11/1/16|0 |ELEVENTH| |-1.5 |1.5 | | |
|12/1/16|2000 |TWELFTH*| | |-1.5 | |400 |
| | | | USD | BTC | BTC | XMR | XMR |
| | | | non | non | non | non | non |
|2/1/16 |0 |Bought | -220| 0.25| | | |
|3/1/16 |250 |Traded | | -0.25| | 180| |
|4/1/16 |0 |Transferred | | | | -90| 90|
|5/1/16 |0 |Transferred | | | | 90| -90|
|5/2/16 |160 |Traded | | 0.3| | -90| |
|6/1/16 |0 |Transferred | | -0.3| 0.3| | |
|7/1/16 |200 |Traded | | 0.7| | -90| |
|8/1/16 |0 |Transferred | | 0.3| -0.3| | |
|9/1/16 |400 |Traded | | -0.5| | 200| |
|10/1/16|900 |Traded | | 1| | -200| |
|11/1/16|0 |Transferred | | -1.5| 1.5| | |
|12/1/16|2000 |Traded* | | | -1.5| | 400|
---
@ -148,8 +147,8 @@ There must be a value associated with *either* one *or* two accounts in each tra
depending on the type of transaction, i.e.:
* a deposit will reflect a positive value posting to the account where money was deposited
* a payment will reflect a negative value posting to the account from where the money was spent
* an exchange would reflect a negative value in one account and a positive value in another
* a transfer (toSelf) would also reflect a negative value in one account and a positive value in another
* an exchange would reflect a negative value in one account and a positive value in another (differing `ticker`s)
* a transfer (toSelf) would also reflect a negative value in one account and a positive value in another (same `ticker`)
(An exchange transaction will trigger a gain or loss, whereas a toSelf transfer would not.)
@ -162,16 +161,18 @@ The 0.25 represents the increase in the BTC balance, so 0.25 is used.
The same logic applies to the next transaction.
0.25 BTC was used to buy XMR, and the XMR balance increased by 180 as a result.
But the user would have paid a transaction fee, so the amount paid for was really, say, 180.002.
But the user would have paid a transaction fee, so the exchange rate suggested the amount paid for was really, say, 180.002.
In fact, the user would literally have placed an order for 180.002 at a price where they'd pay 0.25.
It doesn't matter, though, that the order was placed for 180.002
because this software only cares about what you receive in your wallet as a result of the transaction.
Or, if the fee is paid in BTC, the order might have been .2498 BTC for 180 XMR, but the total cost is .25 BTC because of a .0002 BTC fee.
The details regarding the fee are irrelevant, however, when it comes to entering the trade in the input file
because this software only cares about what you pay and what you receive in exchange as a result of the transaction.
Looking at the third and fourth transactions, the same amount was withdrawn from one account and deposited into another account.
This is an unrealistic scenario because network transaction fees and exchange transfer fees are ignored.
There are exchanges who will cover the transfer fee, but it's rare.
And it certainly is unrealistic for the user to send from their personal wallet (in the fourth transaction) with no network fee.
This may be an unrealistic scenario because network transaction fees and exchange transfer fees are ignored.
There are exchanges who will cover the transfer fee, but it's not common.
It certainly is unrealistic for the user to send from their personal wallet (in the fourth transaction) with no network fee.
These transactions are oversimplified on purpose.
If you transfer 0.1 BTC from one account to another, and the other account receives 0.0999, then that's what you record.
###### Margin accounts