shadowmax31 / crypto_log Goto Github PK

TinyDB is slow.

I think I want to use my own simple file structure to manage the data. Something like, task warrior. This will make it a lot easier to manage the undos.

Now that, I know more about what's needed to make this application work, I need to rethink a structure

Use transactionExists in transaction.py to check if a transaction already exists before printing it to the generated import file.

At the moment, to make sure transactions are not added twice, we only check if it exists in the buy or sell transaction. This adds transactions that already exist to the history when the CSV is imported. This is not wanted, because it adds junk to the EXPORT function

The generated import file should have a already exists section that shows the transaction that are in the database.

We should add a parameter to crypto.ini to specify the frequency at which we should refresh the prices for different crypto.

Each time the application is called, we could make a check to see when was the last call made to CoinMarketCap's api and if it has been long enough we refresh the prices and save them a table called "Price"

Add a way to import CSV files from:

• crypto.com
• Shakepay

The goal is to import multiple CSV files and call the right transactions (buy, sell or exchange).

• To import one file after another we need to be able to create transactions in any order (see #3 for more details).
• Import Shakepay
• Import crypto.com
• Automatically find what type of CSV the application is reading (Shakepay or Crypto.com)
• We also need to be able to import the same file (or a different file with the same transactions) multiple times without creating the same transaction twice. This is useful for Shakepay where we cannot export the transactions by dates. Meaning that every time we import the CSV, we are going to have old transactions that are already in our database. To identify identical transactions, we could use the DateTime and amount of the transaction. The DateTime could be enough too, because one person is not going to make two transactions at the exact same second.
• Make sure the undo and export functions still work
• Add unit tests

Add comments to the code and refactor what should be written better

List of files to go through

• crypto
• capital_gain.py
• config.py
• const.py
• cost_basis.py
• generate_algo.py
• generate.py
• history.py
• report.py
• transaction.py
• undo.py
• util.py
• date_time_serializer.py
• decimal_serializer.pyh

Order the capital gain report by date first. At the moment, it's ordered by ticker and then by date.

Find a way to insert data in any order. At the moment, buys and sells have to be entered in the right order

• We need a way to add the time to transactions to sort them correctly. This is important to get the right cost basis when a capital gain/loss is triggered.
• This also means, that the current way of generating the capital gain event should be changed. Just like for the cost basis, we should calculate the capital gain every time instead of storing it in the database. This might slow things a bit, but it is necessary to allow the user to insert older transaction, without having to redo the whole database. The only time a capital gain is triggered is on a sell transaction (an exchange transaction is simply a sell transaction and a buy transaction).

Since we have to work with amounts that have many decimals (0.031235 btc), we should find a way to use the Decimal class for better accuracy;

Make better descriptions when generating transactions from CSVs

Dust conversions are basically taking a small amount of crypto (ETH, BTC, etc.) and converting it to CRO. This should be treated as an exchange transaction.

The issue is that dust conversions are generated in two (maybe more) rows in Crypto.Com's CSV and we process one line at a time when importing a CSV file. So, we cannot generate the exchange transaction.

It's also worth noting that the interface in Crypto.Com's app allows to select multiple cryptos in one dust conversion. I don't know how this would show in the CSV though, I only tested converting ETH to CRO.

Change the table structure.

Create a ticker table and put everything in it. With this change, we could remove the history table/class and loop through the ticker table to export all the useful data

Add support for prices over 1000.

In the CSV, 1000 has a comma (1,000). This should be supported when importing (crypto generate).

There should some help to explain how the project should be used

We should add a way to manage the capital gain from interests. Basically, all interests are considered to be a buy at 0$

Have a way to change the amount of crypto without changing the cost basis (would be useful to take into account the fees when transfering crypto between wallets, making it easier to go back down to a cost basis of 0 if you don't own any of a certain crypto)

If you say no to an undo, it still logs it as a completed command. This will cause issues when you export the current database and run the generated file. It will undo a transaction that you did not undo.

Maybe the export command should not use the undo history and instead it should generate the transactions from the existing data. It would make more sens this way

Right now, if a transaction fails for some reason, it is still logged in the history.

We should find a better way to track the history