bitsofwinter / cryptotaxsweden

Script for generating a tax report for cryptocurrency trading which can be sent to the Swedish tax authorities.
GNU General Public License v3.0
52 stars 24 forks source link

Getting "Exception: Selling currency EUR which has not been bought yet" #5

Closed mburazin closed 6 years ago

mburazin commented 6 years ago

Hi,

I'm trying to use your script which seems really useful, especially to me who doesn't speak Swedish :-) If I could just get it to work...

After importing all the data from exchanges to CoinTracking, exporting the data to trades.csv and running the report.py script, it fails immediately with exception:

Exception: Selling currency EUR which has not been bought yet

I've been looking into the code a bit, and from the first glance it seems to me that it could be due to that trade types "Deposit" and "Withdrawal" are not supported by the script... Or am I misunderstanding something ? Also, adding to the same question, are transfers between the exchanges supported ?

Thanks for all the hard work :-)

Regards, Marko.

joelfak commented 6 years ago

Please look at the discussion following my incorrect poll request https://github.com/bitsofwinter/cryptotaxsweden/pull/3. I had the same problem and my first thought was that there was something missing in the program. However, this works as intended since deposits and withdrawals are not trades. You have to add entries in your csv files corresponding to the initial buy of euros (in my case from swedish crowns).

This should answer your second question as well. A transfer of funds between exchanges should not affect the total amount of assets. Only trades between different kinds of assets do, so if you have imported the data from all exchanges to CoinTracking it should work. I have not tested it myself though.

mburazin commented 6 years ago

Thanks for the quick reply. Excellent! I will try out your suggestion and get back with the results.

I have deposited EUR on a couple of occasions throughout the year. Should I add the mentioned CSV entries then at exact dates as they occurred, or all of them at the beginning before all trades ?

mburazin commented 6 years ago

One more potential issue I see with this, I have noticed that some (not all) of the transfer of funds between exchanges actually incur a small fee, which could mean that this fee is viewed as a disposal of asset, which could be a taxable event. In that case one would need to take withdrawals into account, and if there is a fee paid for it, that fee should be included as a taxable event...

Any thoughts on this ?

bitsofwinter commented 6 years ago

Not sure about how the transfer fees should be handled. I have just ignored them in my own tax report. If you find any information on this let me know.

mburazin commented 6 years ago

OK, now I have tried to run the script again by taking @joelfak 's suggestion into account and it has generated the entries.

But, I have two more quite relevant questions:

1) In the K4 forms that are generated (PDF), I can see that in the section C there are FIAT values being calculated and win/loss related to SEK, the same as for other crypto coins. Is this also required to put into tax declaration ?

2) More of a general question on the amounts. The prices of coins and other FIAT is what is provided by the cointracking.info website. Are we sure that this is ok and that we shouldn't use some other exchange rates? Is there any requirement from Skatteverket on which exchange rates we should use? Sometimes one trades on exchanges which don't even have FIAT currencies, so I guess what we get by cointracking.info is good enough? Any thoughts on this?

Sorry for the long questions and thanks again.

metalmetalmetal commented 6 years ago

I have an additional question. I currently have a problem exactly like this, but it's for a coin instead of a fiat currency. But I can't really grok what you are saying is the answer.

What I've done so far is to

  1. add the Deposits in CoinTracking (I now have a positive balance in the overview),
  2. then export the Trade Prices CSV. (I have verified that these deposits are included in the CSV)
  3. Tried running the script and get this:
raise Exception(f"Selling currency {trade.sell_coin} which has not been bought yet")
Exception: Selling currency BCN which has not been bought yet

Am I not supposed to add these deposits as Deposits but trades instead? I'm not quite following what the solution is. :/

metalmetalmetal commented 6 years ago

Ok, so after having tinkered around with this, I think I understand what you are talking about. You are saying that instead of

bitsofwinter commented 6 years ago

Regarding reporting fiat trading, I have't investigated if this really needs to be reported but my gut feeling was that I am doing these fiat trades (SEK->EUR and EUR->SEK) for trading purposes and then they should likely be reported as currency trading. But I could be wrong. You can always remove these trades after you've imported the SRU-files on skatteverket.se.

Regarding which exchange rates are used when computing the value of cryptos at a specific time I have just trusted that cointracking has good data given that they also have a service for generating tax reports. I'm just guessing that if there are any errors in their data the difference in the resulting tax to be paid will not be that big and if Skatteverket decides to investigate me I will not get into trouble for this but might get some money back or pay a little extra, but nothing major.

Regarding errors such as "Selling currency BCN which has not been bought yet", this usually means that hard forks or airdrops haven't been reported properly. Deposits/Withdrawals are ignored currently because I've only used these to transfer coins between my own wallets and this isn't something that changes the tax situation. If you receive income or buy things with crypto this isn't handled yet by the script. Hard forks and airdrops should currently be reported as Gift/Tip on cointracking to be included in the tax report by the script.

mburazin commented 6 years ago

Thanks for the answer. We can close this issue, since the original problem in the headline turned out not to be a bug.