Jump to content
YetAnotherBTCGeek

Trading-Gewinnermittlung für die Steuer - softwaregestützt

Empfohlene Beiträge

Hallo zusammen,

 

da ich die nächsten Tage nicht mehr so viel Zeit für's Arbeiten am CT werde aufbringen können, habe ich den Ist-Stand jetzt mal in ein neues "offzielles" Release gegossen:

 

Version 0.8.6 ist live!

 

...mit diesen verbesserten/geänderten Punkten (Auswahl):

 

  • Kraken-Import: funktioniert jetzt auch per API-Datenruf auf Knopfdruck. (Da ich jetzt die Grundstruktur dafür im Programm habe, werden weitere API-Importe wesentlich weniger aufwändig umzusetzen sein.)
  • Import vom MultiBit-Client: Die CSV-Exporte des MultiBit-Wallets können jetzt eingelesen werden (mit Spracheinstellung Deutsch oder Englisch).
  • Anzeige Gewinn-Verlust-Bericht: Bisher wurden bei der Installation für die Anzeige benötigte Komponenten nicht mit ausgeliefert (Microsoft ReportViewer). Jetzt sind sie enthalten, d. h. der Bericht erscheint jetzt auch ohne Fehlermeldung...
  • Diverse andere Kleinigkeiten (Importe Vircurex & Bitstamp, Bearbeiten von Trades usw.)
 

Bei Gelegenheit werde ich dann auch mal die CoinTracer-Doku-Seite aktualisieren (diese hier: http://www.cointracer.de/?q=node/4)

 

Viel Spaß damit!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

...na super, mein Provider hat offenbar gerade ein Problem oder führt Wartungsarbeiten durch. http://www.cointracer.de ist gerade nicht erreichbar. Ist hoffentlich bis morgen früh erledigt...   :huh:

Ist erledigt, die Site ist wieder am Netz! :)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Oh Mann, schon wieder Schwierigkeiten auf Seiten meines Web-Providers; www.cointracer.de ist wieder down. Werde mal nachhören, wann mit einer "Genesung" zu rechnen ist... :-\

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Oh Mann, schon wieder Schwierigkeiten auf Seiten meines Web-Providers; www.cointracer.de ist wieder down. Werde mal nachhören, wann mit einer "Genesung" zu rechnen ist... :-\

 

...und wieder da - ein Dienst hatte sich aufgehängt. Jetzt läuft wieder alles.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Servus,

 

vielen Dank erstmal für deinen Einsatz und die Entwicklung dieses wirklich sehr praktischen Tools :)

 

Ich habe noch zwei Probleme beim Einsatz festgestellt:

 

1. Import meiner Bitcoin-Qt Transaktionsdatei funktioniert nicht (wurde unter Linux exportiert, evlt. liegt es daran - welches Encoding wird erwartet?)

Hier die betreffende Datei: http://filenuke.com/f/Ogjjj10

 

2. Nach manueller Eintragung der Wallet-Transaktionen kommt nach Klick auf "Berechnung ausführen" der Fehler "Conversion from Type 'DBNull' to type 'Long' is not valid.". Ich konnte allerdings keinen leeren Wert in der Datenbank finden.

Hier meine Datenbank: http://filenuke.com/f/O8BBBK6

 

Wenn du Zeit findest, dir die Sachen anzuschauen, würde mich das sehr freuen. Insbesondere der zweite Fehler verhindert mir derzeit den Einsatz der Software.

 

Beste Grüße,

Andre

bearbeitet von AtomicBounce

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Servus,

 

vielen Dank erstmal für deinen Einsatz und die Entwicklung dieses wirklich sehr praktischen Tools :)

Vielen Dank für die Rückmeldung! :)

 

Ich habe noch zwei Probleme beim Einsatz festgestellt:

 

1. Import meiner Bitcoin-Qt Transaktionsdatei funktioniert nicht (wurde unter Linux exportiert, evlt. liegt es daran - welches Encoding wird erwartet?)

Hier die betreffende Datei: http://filenuke.com/f/Ogjjj10

 

...würde ich mir gern ansehen, bekomme aber deine Datei irgendwie nicht von FileNuke geladen. Irgendwann kommt was mit "Create Download Link", woraufhin man einen obskuren "Mediaplayer.exe" installieren soll?! Könntest Du einen anderen Filehoster nehmen (öffentlicher Dropbox-Link oder sowas...)

 

2. Nach manueller Eintragung der Wallet-Transaktionen kommt nach Klick auf "Berechnung ausführen" der Fehler "Conversion from Type 'DBNull' to type 'Long' is not valid.". Ich konnte allerdings keinen leeren Wert in der Datenbank finden.

Hier meine Datenbank: http://filenuke.com/f/O8BBBK6

Das schaue ich mir in den nächsten beiden Tagen mal an - und versuche erst einmal, dem ganzen ohne dein Datenbank-Beispiel auf die Spur zu kommen...

 

Wenn du Zeit findest, dir die Sachen anzuschauen, würde mich das sehr freuen. Insbesondere der zweite Fehler verhindert mir derzeit den Einsatz der Software.

Na das sollten wir doch in den Griff bekommen... :D

  • Love it 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Vielen Dank für die Rückmeldung! :)

 

 

 

...würde ich mir gern ansehen, bekomme aber deine Datei irgendwie nicht von FileNuke geladen. Irgendwann kommt was mit "Create Download Link", woraufhin man einen obskuren "Mediaplayer.exe" installieren soll?! Könntest Du einen anderen Filehoster nehmen (öffentlicher Dropbox-Link oder sowas...)

 

 

Das schaue ich mir in den nächsten beiden Tagen mal an - und versuche erst einmal, dem ganzen ohne dein Datenbank-Beispiel auf die Spur zu kommen...

 

 

Na das sollten wir doch in den Griff bekommen... :D

 

Danke, top Idee mit dem Dropbox-Link, habe ich gar nicht dran gedacht. Hier nochmal die beiden Dateien:

 

https://www.dropbox.com/s/5fp6eljoryqeapv/bitcoin-transactions-wallet.csv

https://www.dropbox.com/s/expq97oz5y7ic6h/cointracer.data

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Danke, top Idee mit dem Dropbox-Link, habe ich gar nicht dran gedacht. Hier nochmal die beiden Dateien:

 

https://www.dropbox.com/s/5fp6eljoryqeapv/bitcoin-transactions-wallet.csv

https://www.dropbox.com/s/expq97oz5y7ic6h/cointracer.data

Okay, das hat geklappt! Ich schaue mir das heute Abend an und gebe dann Rückmeldung.

 

Bis dahin!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo AtomicBounce,

 

okay, ich habe die Stellen gefunden, die Probleme machen und kann heute Abend eine neue Version zusammenstellen. Falls es Dir in der Zwischenzeit hilft: das Problem mit den manuell angelegten Trades besteht darin, dass (u.a.) das Feld ImportID (Trades) nicht geschrieben wird. Wenn diese ID-Spalten mit 0 initialisiert werden (oder ich den Null-Wert im Code abfange), dann läuft die Gewinnberechnung durch.

 

Was die Wallet-Datei angeht: in der Tat liegt's daran, dass der Bitcoin-Core-Client unter Windows Latin-1-codierte Dateien erzeugt, der Linux-Client offenbar UTF-8, womit der CT aktuell noch nicht klarkommt.

 

Aber wie gesagt: das ist schnell geändert, so dass der Datentransfer funktionieren sollte.

 

Bei Deiner Beispiel-DB wird dann übrigens bei der Gewinnberechnung ein anderes Problem auftreten, weil es einen Transfer gibt, für den in den Daten nicht hinreichend viele Einzahlungen gibt. Das ergibt sich aber aus den eingelesenen/eingegebenen Trades und ist kein technisches Problem.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

So, eine neue Version ist live (Version 0.8.6.1). Mit dieser klappt auch der Import der Transaktions-Dateien aus dem Bitcoin-Core-Client unter Linux. Außerdem habe ich noch ein paar kleinere Usability-Änderungen und Korrekturen bei der Anzeige des Gewinn-Verlust-Berichts umgesetzt.

 

Viel Spaß damit!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Vielen Dank, die neue Version hat beide Fehler behoben :)

 

Ich kann jetzt tatsächlich die Gewinn-/Verlustrechnung durchführen. Es scheint allerdings noch ein Problem mit der USD/EUR Umrechnung zu geben, alle Euro-Preise sind um den Faktor 10.000 zu klein: sowohl in der Trades-Tabelle unter WertEUR als auch später in der Gewinn-/Verlustrechnung. Ursache dafür sind vermutlich die Einträge in der Kurse-Tabelle (automatisch abgerufen über die Funktion im Programm): da steht bspw. dass am 1.1.2009 1 Euro 13866 USD entsprach. Wahrscheinlich wurde der Faktor 10000 extra verwendet, damit Integer-Zahlen verwenden werden können? Bei späteren Berechnungen muss das dann natürlich auch entsprechend berücksichtigt werden.

bearbeitet von AtomicBounce

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Es scheint allerdings noch ein Problem mit der USD/EUR Umrechnung zu geben, alle Euro-Preise sind um den Faktor 10.000 zu klein: sowohl in der Trades-Tabelle unter WertEUR als auch später in der Gewinn-/Verlustrechnung. Ursache dafür sind vermutlich die Einträge in der Kurse-Tabelle (automatisch abgerufen über die Funktion im Programm): da steht bspw. dass am 1.1.2009 1 Euro 13866 USD entsprach. Wahrscheinlich wurde der Faktor 10000 extra verwendet, damit Integer-Zahlen verwenden werden können? Bei späteren Berechnungen muss das dann natürlich auch entsprechend berücksichtigt werden.

Also das ist kurios! Und bei mir definitiv nicht so (wäre mir beim Testen ja sofort aufgefallen)... Sowohl der Online-Datenabruf als auch das manuelle Einlesen der CSV-Datei mit den Kursdaten funktionieren bei mir.

 

Lädtst Du die Kursdaten auch wieder erst auf einem Linux-Rechner herunter und liest sie dann anschließend über die Import-Funktion ein?

 

Wir kommen da bestimmt weiter, wenn Du mir mal die CSV schicken könntest (als PM oder Mail an info@cointracer.de), die Du unter dieser URL bekommst:

http://www.bundesbank.de/cae/servlet/StatisticDownload?tsId=BBEX3.D.USD.EUR.BB.AC.000&its_csvFormat=de&its_fileFormat=csv&mode=its

 

Danke!

bearbeitet von YetAnotherBTCGeek

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nein, ich habe einfach auf den Button EUR<->USD aktualisieren geklickt. Das CSV kann ich dir gerne schicken, aber denke nicht dass das bei mir anders aussieht als bei dir.

 

EDIT: Ich vermute, es liegt an der Locale. Ich habe mein Windows auf Englisch, und in der CSV-Datei sind die Dezimalzahlen mit Komma eingetragen. Ich vermute, dass das Parsing aus diesem Grund nicht klappt und das Komma einfach weggeworfen wird.

bearbeitet von AtomicBounce

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

EDIT: Ich vermute, es liegt an der Locale. Ich habe mein Windows auf Englisch, und in der CSV-Datei sind die Dezimalzahlen mit Komma eingetragen. Ich vermute, dass das Parsing aus diesem Grund nicht klappt und das Komma einfach weggeworfen wird.

Das wird's mit Sicherheit sein! Ich werde an der Stelle im CT dann noch einbauen, dass die Locale-Einstellung berücksichtigt wird.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ja es liegt tatsächlich daran. Habe mein Windows auf deutsch umgestellt und schon ist es richtig.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

So, nächstes Problem :D

 

Irgendwie wird aus einem einfachen Transfer in der Gewinn-/Verlustrechnung plötzlich zwei, auch der Betrag der Transaktion stimmt irgendwie nicht mehr. Hier die entsprechende Stelle als Screenshot:

https://www.dropbox.com/s/dj31qmt3q0is6uq/double_transfer.png

 

Hier meine aktuelle Datenbank:

https://www.dropbox.com/s/expq97oz5y7ic6h/cointracer.data

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Schaue ich mir morgen mal an. Grundsätzlich ist es aber beim Gewinn-Verlust-Bericht so, dass eine Transaktion (Transfer oder Coin-Verkauf) in mehrere Zeilen aufgesplittet werden kann: das passiert immer dann, wenn Coins verschiedener Kaufzeitpunkte (Kaufdatum) eingesetzt wurden. Der Coin-Betrag wird dabei (normalerweise) passend aufgesplittet.

 

Insofern wundern mich die ersten beiden Zeilen aus deinem Screenshot nicht. Was aber nicht zusammen passt, ist dass die Transfer-Summe im Bericht 5,333223 BTC ergibt, während tatsächlich aber nur 2,66661161 BTC übertragen wurden?! Aus irgend einem Grund scheint der Betrag im Bericht verdoppelt zu werden...

 

Wie gesagt: schaue ich mir morgen an, heute komme ich nicht mehr dazu.

 

Bis dann!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Huhu
ich habe das Problem das bei mir einfach keine Kommata in das Programm übertragen werden.
Einfach bei allen Zahlen die Kommata rausgeschmissen und ewig große Zahlen produziert:
https://www.dropbox.com/s/fzestqhtzxr245z/1.jpg
 
Hätte ich 700.000.000 BTC würde ich glaub gar nicht erst auf ner Börse handeln ^^
 
Vor allem habe ich den ersten Eintrag der "Transactions.csv" von Bitstamp kopiert, also quasi die EInzahlung von Bitcoin.de auf Bitstamp.
Warum hat er jedoch diesem Eintrag die ID 479 gegeben, also quasi die höchste/letzte ID Nummer?

bearbeitet von BitCounter

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo Bitcounter, kannst Du mit vlt. mal die ersten paar Zeilen Deiner Transactions.csv schicken? Der Bitstamp-Import ist auf Basis von Musterdateien von Anwendern entstanden, da ich selbst nicht darauf handle. Ich vermute, dass Bitstamp nun auch Exporte mit Deutschem Zahlenformat bietet - was meines Wissens neu wäre. Im englischen Zahlenformat entspricht das Komma ja dem deutschen Tausenderpunkt und wird daher beim Import folgerichtig ignoriert. Das würde das Verhalten erklären.

 

Andernfalls: Herzlichen Glückwunsch zum BTC-Reichtum! ;-D

 

Was die IDs angeht: warum die letzte ID vergeben wird, kann ich jetzt so spontan gar nicht sagen; die Zeilen der Dateien werden z. T. vor dem Einlesen intern noch einmal umsortiert (i. d. R. chronologisch), das könnte das evt. erklären. Ist in jedem Fall aber kein Problem bei der Berechnung.

 

Ich versuche mal, mir das in den nächsten Tagen genauer anzusehen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hey,

 

ich habe jetzt nochmal selbst versucht, mein Problem zu Umgehen durch Neuaufsetzen der Datenbank und Verzicht auf den Import von der Core-Wallet Transaktionsdatei (dachte das Problem wäre evtl. dass dieselbe Transaktion mehrfach importiert wird, einmal aus der Bitstamp-Datei und einmal aus der Core-Wallet-Datei). Leider hat auch dies nichts genutzt. Auch wenn ich nur die Bitstamp-Datei importiere, ist der Betrag der Transfers zwischen Bitstamp und Core-Wallet stets doppelt so hoch, wie sie eigtl. sein sollten. Vielleicht kannst du dir die Sache ja nochmal anschauen.

 

Vielen Dank!

bearbeitet von AtomicBounce

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hab dir mal eine PN geschickt YetAnotherBTCGeek, solltest du weitere Rahmendaten brauchen geb einfach bescheid!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hab dir mal eine PN geschickt YetAnotherBTCGeek, solltest du weitere Rahmendaten brauchen geb einfach bescheid!

 

Hab dir gerade geantwortet; deine Transactions.csv sieht bzgl der Datenzeilen etwas "sonderbar" aus. Ist aber nichts, was nicht relativ leicht im Programm angepasst werden könnte.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hey,

 

ich habe jetzt nochmal selbst versucht, mein Problem zu Umgehen durch Neuaufsetzen der Datenbank und Verzicht auf den Import von der Core-Wallet Transaktionsdatei (dachte das Problem wäre evtl. dass dieselbe Transaktion mehrfach importiert wird, einmal aus der Bitstamp-Datei und einmal aus der Core-Wallet-Datei). Leider hat auch dies nichts genutzt. Auch wenn ich nur die Bitstamp-Datei importiere, ist der Betrag der Transfers zwischen Bitstamp und Core-Wallet stets doppelt so hoch, wie sie eigtl. sein sollten. Vielleicht kannst du dir die Sache ja nochmal anschauen.

 

Vielen Dank!

 

Ich hab' dich nicht vergessen! ;-)

Bin in den letzten Tagen nur ziemlich eingespannt gewesen, daher brauche ich noch ein wenig Zeit, um hier weiterzukommen. Ich melde mich aber nach Analyse auf jeden Fall!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

×

Wichtige Information

Wir speichern Cookies auf Ihrem Gerät, um diese Seite besser zu machen. Sie können Ihre Cookie-Einstellungen anpassen, ansonsten gehen wir davon aus, dass Sie damit einverstanden sind. In unseren Datenschutzerklärungen finden sie weitere Informationen.