Since December we have received several tickets via our HelpDesk. Each time it was about the same topic that we explained to you over and over again.
But I will gladly explain the situation to you again.
Dominik thank you at least for responding here at long last, I do appreciate that. And yes I have been trying to get answers from you for a huge array of questions re problems and perceived bugs since as far back as December. The amount of man hours wasted with this process of finding, identifying, deciphering and correcting the inaccurate data which is introduced by Cointracking is just unbelievable and it is still not right.
I might also add that despite my sending you screenshots and corroborating evidence for each of the particular unique queries a lot of these were never answered or answered unsatisfactorily in my opinion. The answers that were provided in a lot of cases did not address the actual question that I was posing. They were simply stock standard cut and paste answers without regard to the actual unique evidence in front of you. In the end I became so sick tired of trying to point this fact out to you over and over that I just gave up out of total frustration.
A case in point is your current answer to my question which I originally posted 11 days ago in which you have now simply cut and paste that same answer to me yet again. Could I ask you please to never send me that again as I have read it so many times now. To this end I have previously advised you that I only ever select the Transaction Prices method in an effort to reflect the real life transactional values and costs. I am only interested in absolutes and accurate values not some incorrect value inserted by the software that has nothing at all to do with my transaction values. I have to submit my Tax return to the ATO based on the information in the final reports and it has to be ACCURATE as I do not want to risk going to jail for submitting wrong data to the Tax Department. Is that really too much to expect just to be accurate
My question again below was asking you to advise me what and why there are five different values appearing in Cointracking for one simple theoretical transaction to purchase 1 BTC . Could you please advise about each of these individual points so that I can try and understand how and why Cointracking does things this way so that I can then try and mitigate these introduced errors in each and every transaction entry.
1 BTC dummy purchase on 24 /02 /2019, I Entered $5898 as the Cost and $898 as the Fee and Home as the Exchange
$5898 The actual fiat cost value entered into the Enter Coins page (copied from LiveCoinWatch), Populates to the 'Sales Value' box
$5870 Cointracking automatically inserted this figure in the 'Purchase Value' box disagreeing with the above 'Sales Value' box? Why?
$5535 The Cointracking Coin Calculator for 1 BTC on the purchase date value showed this figure when I checked out of interest. Why?
$5875 Showed as the current value of 1 BTC in the Summary box on the Enter Coins page at the exact time of the purchase entry? Why
Next I checked the Total Realised and Unrealised Gains Report and this report uses the incorrect $5870 that Cointracking inserted automatically as a Cost Value to do the calculation which can only ever be wrong!.
This is further complicated and messed up beyond comprehension when I check the Tax Report / Closing Position Report which shows a 5th differing Cost value now inserted for this one simple purchase transaction of $5786. WHY?
The Coin Price Calculator uses the price at a certain time on that day. Your trade has certainly taken place at a different time that day, so a comparison makes no sense. We had already clarified this in a ticket.
The price referred to above in the dummy transaction was checked and retrieved at the actual time of the trade. If your Coin Calculator has some sort of inbuilt time lag and does not correspond to live dynamic values at any given {day:hour:minute;second} then it would be prudent to advise of this situation on the Coin Calculator page wouldn't you agree. Or if as I think that you may have advised earlier that the Calculator uses a different source for this data then I am not sure why you would want to introduce an alternative source of non dynamic price data other than what is already utilised elsewhere in Cointracking as this provides a greater chance of introducing discrepancies from these multiple data sources as there seems to be now?
There may be some technical reason for doing so that is not obvious to me or others but clarity would assist in customer understanding.
If indeed this Calculator just accesses a price at say one time of each day so say 5pm then there is the real risk that daily price fluctuations could be once again massive in the future and this would make a non dynamic price engine nearly worthless?
As I have previously explained to you that when I import transactions from an exchange that only shows the crypto values of transactions and not fiat equivalent values then Cointracking inserts it's own two differing values in the 'Sale Value' and 'Purchase Value' boxes. So at this point in the process how do I (or anyone) determine which of these differing values are correct or even nearly correct as sometimes there are wide differences in the fiat values displayed?
So I choose to use the Coin Calculator to provide the one singular value that I then insert into both Sale Value and Purchase Value boxes in the records from these non fiat exchanges.
In cases where the import is from an exchange that does provide fiat values for the transactions I rely on their provided value and copy it from the Sales Value box where it appears automatically into the Purchase Value box.
Is there any reason why I should not do it this way when I am concerned primarily with being accurate ?
CSV Import
The CSV export of the "Enter Coins" page can be imported again via the "CSV Import" without problems and timestamp errors. If you get an error message, you have either changed the format or edited the file with a program like Excel. We explicitly point out on the Importer page not to do this.
In addition, when exporting this CSV file, no trade ID and no asset values are exported.
This means that the asset values will be filled by our historical prices and duplicates are created if you have not cleaned up your portfolio before.
Please use the "Trades Backup" instead:
https://cointracking.info/backup_trades.phpI used the Export button offered on the Enter Coins page to 'backup' all my entries to my laptop. It is obviously an .csv file which can only be opened in Excel or Libre Calc or similar and was simply saved to a .csv file in a folder. That same file was subsequently selected via the Cointracking .csv Import page and that is when the Timestamp Errors appeared in 86 of the 134 lines of records contained within that previously saved and UNEDITED.csv file. At this point there had not been any editing or changing of any of the records contained within that file but these errors where consistently appearing in the 20 or so times I tried to re-import this file that had been Exported from Cointracking with no editing at that time of re-importing. Why does this happen to some records and not to the others in the same file? You can go on believing that I have done something wrong here or you can admit to yourself that maybe there is a problem that requires fixing from your end. That's up to you you I guess.
When you say 'no asset values' are exported you are referring to just the 'Purchase Value' information as the 'Sale Value' data seems to be successfully exported and re-imported, is this correct?
Then despite the fact that I had gone through all my records prior to Exporting and made sure that the 'Purchase Value' and 'Sale Value' boxes contained the same identical values (as described above) upon re-importing Cointracking just wipes out all of my manual editing that was done to make sure that all the values were identical. No warning about this on the page that I could see either?
I do thank you for pointing out the Trades Backup facility as I was unaware of it and so will use this in the future instead, providing it works as hoped.
I trust that we can get these queries sorted out so that we can all benefit from what I still believe is fundamentally powerful software, albeit with some flaws that can be fixed hopefully.