Topic: Fröhliche Gewinnermittlung für die Steuer - softwaregestützt: CoinTracer - page 10. (Read 51493 times)

Hey, hatte mal bei Kraken wegen eines Histroy exports via csv-Datei angefragt.

Antwort: Sie arbeiten daran.

Okay - dann werde ich's wohl so machen, dass der CoinTracer bei doppelten Zeilen innerhalb eines Importvorgangs nachgefragt wird, ob diese mehrfach oder nur einmal importiert werden sollen. Wenn es aus einem früheren Import bereits Datenzeilen mit gleichem Inhalt gibt, kann man meiner Einschätzung nach aber mit hoher Wahrscheinlichkeit davon ausgehen, dass es sich um Dubletten handelt, die nicht importiert werden sollten.


Ach herrje, das sehe ich mir heute Abend mal an...


Du hast Recht, habe die Stelle gefunden! Das war in der Tat noch krummer Code (der Bitstamp-Import ist älter als das Datenfeld "Betrag abzgl. Gebühr") - beim Kauf von BTC wird beim Bitstamp-Import dieses Datenfeld noch falsch gefüllt, eigentlich sollte hier die Gebühr abgezogen sein. Wird umgehend korrigiert, danke für den Hinweis!


Stimmt! Hoffen wir trotzdem mal, dass wir die so bald nicht wieder sehen  


Bis nachher!

Hallo,

danke für deine Antwort.


Die Zeilen sind in der Tat identisch. Da hilft wohl nur eine Abschaltmöglichkeit oder Nachfrage beim importieren.
Ich werde das morgen nochmals prüfen, aber wenn ich mich richtig erinnere wurden 8 Transaktionen übersprungen, ich konnte aber nur zwei Dubletten-Pärchen finden. Welche anderen Gründe kann es denn geben, dass Transaktionen ausgelassen werden?

Ändert leider nichts.
Wenn ich in Tabellen/Trades im Kontextmenü "Trades bearbeiten" auswähle und das grüne "+" bekomme ich eine Maske mit ID 420. Abspeichern scheint ok zu sein, aber in der Tabelle bleibt die höchste Nummer 419. Ein neues "+" gibt mir auch wieder ein leeres ID 420. Das bleibt auch so, selbst nach Neustart des Programms.
Scheint also eher beim abspeichern schief zugehen als beim Anzeigen.
Ändern einer vorhandenen Transaktion funktioniert gut.


Hmm, verstehe ich immer noch nicht.
Für diese Zeile aus Bitstamp csv
2,2013-10-08 06:46:21,0.82311168,-102.00,123.92,0.51
würde ich erwarten Betrag = -102.51 Betrag abzgl Gebühr = 102.00 oder?
Ich sehe aber Betrag = -102.51 Betrag abzgl Gebühr = 102.51 !
(Das waren noch Einkaufspreise :-)

Gute Nacht

Hi Discuss4Wisdom,

keine Sorge - Du frustrierst mich nicht, ich bin ja ehrlich froh über konstruktive Rückmeldung. Auch wenn Sie meine Release-Zeitplanung über den Haufen werfen...

Also: zunächst mal herzlichen Dank für die detaillierten Meldungen und die Vircurex-Beispielzeilen. Ich werde das dann heute wohl doch nicht mehr final in den Griff bekommen - aber zum WE hin sollte es was geben mit neuer Version.

Aber im einzelnen:

Hm - die Beispiele, die Du geschickt hast, lassen ein Problem mit Datumsformatierungen vermuten. Das muss ich aber genauer analysieren...

In der Tat: bei Bitstamp habe ich das Problem, dass die History nur aus diesen Spalten besteht: Type,Datetime,BTC,USD,BTC Price,FEE
Es gibt also keine eindeutige ID pro Zeile, daher prüft der Algorithmus zur Vermeidung von Doppelimporten aktuell Typ, Zeitpunkt und Betrag (also die ersten drei Spalten). Wenn die Angaben doppelt vorkommen, wird nur einmal importiert.

Würde es in deinem Fall helfen, wenn ich beim Import alle Spalten in die Prüfung mit einbeziehen würde? Oder hast du komplett identische Zeilen, die auch wirklich jeweils eigene Trades darstellen? Da wüsste ich so spontan nicht, wie ich das abfangen sollte, ohne die Dublettenprüfung komplett wegzulassen?!

Ah - das wird ein "einfaches" Problem in der Aktualisierung der Übersicht sein. Hast Du mal versucht, auf dem ersten Reiter "Übersicht" die Plattformen ein- und auszublenden? Damit werden die Summentabellen neu geladen. Wenn das bei Dir die Lösung ist, weiß ich, wo ich das sehr einfach korrigieren kann.

Das stimmt, ist nicht ganz leicht nachzuvollziehen und hat i. W. "historische Gründe", wie man so schön sagt... 
Die einzelnen Gebührenzeilen dienen nur einem Zweck: sie werden bei der Übersicht unter "Abgänge" informatorisch summiert. Jede einzelne Trade-Zeile ist aber für sich selbst gesehen vollständig hinsichtlich der zu buchenden Beträge. Bei der manuellen Erfassung von Trade-Daten kannst Du die Gebühren auch weglassen, ohne damit irgendwelche Steuerberichte zu beeinträchtigen.

Die Spalten "Betrag" und "Betrag abzgl. Gebühr" sind bei den "normalen" Trade-Zeilen aber wichtig (und einigermaßen selbsterklärend, denke ich - oder?)


Schön gesagt! 

Wie das mit lokal zu installierender Software eben so ist: jeder Benutzer hat im schlimmsten Fall eine andere Umgebung - und das Sicherstellen, dass die Software überall (oder zumindest bei den Meisten) läuft, ist richtig Arbeit...

Aber ich bleibe dran und freue mich - wie gesagt - immer über hilfreiches Feedback!

Hallo,

das ist ja mal eine schnelle Reaktion :-)
Tatsächlich habe ich leider kräftig zu kämpfen mit deinem Programm.
Bin aber gerne beim verbessern behilflich.

Folgende Probleme:
- Import von vircurex gelingt leider nicht. Sagt was von allen Zeilen falsches Format, obwohl das eigentlich gut aussieht.
[edit: habe dir gerade per private message Beispielzeilen gesendet]
- Beim import von bitstamp kam die Meldung das 8 Buchungen ausgelassen wurden.
Nach einigem suchen habe ich bisher zwei gefunden, die ausgelassen wurden. Die sehen aus wie Dubletten, sind aber tatsächlich zwei Buchungen mit gleichem Betrag und gleichem Zeitpunkt (das war eine standing offer von mir, die anscheinend von einem Bot in Kleinbeträgen aufgekauft worden ist oder so).
- Der Versuch Manuell Buchungen einzutragen gelingt nicht. Er sagt zwar ok, aber die Buchung ist nicht da. Weder für vircurex noch für bitstamp (wobei ich auch versucht habe einen leicht anderen Betrag mit leicht anderer Zeit anzugeben)
- Gebühren sind mir nicht ganz klar: "Gebühr" und "Betrag abzgl. Gebühr" sehen immer gleich aus. der Betrag in der Tabelle ist mit Gebühr. In der nächsten Zeile kommt dann die Gebühr nochmals einzeln.

Ich werde jetzt mal die Dubletten schon im csv zusammenfassen, damit sollte das gelöst sein.

Ich hoffe ich schocke und frustriere dich jetzt nicht.
Wie gesagt, super Programm - wenns funktionieren würde.

Hallo Discuss4Wisdom! Vielen Dank für die Rückmeldung! Dass bei Dir der Report nicht funktioniert, ist nicht schön, eigentlich sollte es so aussehen:


Ich bin bisher davon ausgegangen, dass der ReportViewer Bestandteil des .NET-Frameworks ist - das scheint aber nicht der Fall zu sein. Ich prüfe das heute mal etwas genauer und gebe noch mal Feedback!

Das andere Problem mit der ständigen Meldung, dass der Programm offenbar zum ersten Mal gestartet sei, ist mir ebenfalls neu. Sehe ich mir auch gleich mal an...

Bis nachher!

Hallo,

danke für das nützlich aussehende Programm.

Bei "Bericht anzeigen" bekomme ich allerdings eine Fehlermeldung wg. fehlendem "Microsoft ReportViewer.WinForm Version 11.0.0.0"
Das selbe auf zwei Windows Installationen (Win7, Win8.1) und auch nach Installation von  http://www.microsoft.com/de-DE/download/details.aspx?id=6610.
Ist in "Bericht anzeigen" mehr enthalten als bei "Bericht in Zwischenablage"? (Ausser der in der Doku sichtbaren überschritt)

Ausserdem werde ich jedes mal mit "Sie starten das Programm offenbar zum ersten mal" begrüsst. Die Daten sind dann aber da.

Sind das bekannte Bugs?

Okay, ist aufgenommen und wird im nächsten Release eingebaut.

Eine ganz praktische Rückfrage noch: ich habe selbst bei Kraken < 50 Trades, kann das mit der 50er-Grenze also nicht gut testen. Ich könnte jetzt zwar einfach ein bißchen traden, um über die 50 zu kommen, aber das würde wahrscheinlich noch mindestens eine Woche dauern.

Wäre jemand mit mehr als 50 Trades gewillt, mir beim Testen zu helfen? Ich würde ihm/ihr via Mail oder PM die entsprechende Zwischenversion schicken, mit der man den Datenabruf dann prüfen könnte.

<- Fürsprecher

Würde ne Menge Arbeit ersparen^^

Ah - danke für den Hinweis. Wenn ich mir die Kraken-API ansehe, erscheint mir das aktuelle Limit von 50 Trades pro API-Abruf aber kein echtes Problem zu sein: es gibt beim Abrufen der Ledger-History einen Start(-Zeitpunkt)-Parameter, so dass man einfach alle Trades jeweils in 50er-Chargen abholen könnte. (Zumindest theoretisch - vlt. komme ich am WE dazu, das in der Praxis einmal durchzuspielen.) Das ist nicht performant, weil zwischen den einzelnen Kraken-API-Request ein paar Sekunden Abstand liegen müssen - aber grundsätzlich lösbar.

Wenn es mindestens noch einen zweiten Fürsprecher gibt, mache ich mich mal daran...

Aktuell wird wohl auch der Import über API nicht viel bringen, siehe hier: https://bitcointalksearch.org/topic/m.6590424
Les dir dazu ruhig mal die darauf folgenden Posts durch, vllt kannst du ja was damit anfangen.
Und fallls du oder Dario eine vernünftige Lösung dazu finden, könnt ihr euch ja gegenseitig informieren, bzw. du informierst mich und ich informiere dich

AFAIK nur wenige, z.B. BTC Guild:

Das klingt doch nach einem vorzüglichen Plan.

Es gibt für viele Alts entsprechende Blockexplorer, auch mit API.
Nur ein Beispiel: https://bitcointalksearch.org/topic/cryptocoinexplorer-one-of-the-original-alt-coin-explorer-sites-584847

Danke für das Feedback! 

In der Tat: Mining-Erträge könnten zwar im Reiter Tabellen bei den Trades manuell erfasst werden, aber praktikabel ist anders...   
Bisher ist das Tool aufs Traden auf den integrierten Plattformen ausgerichtet, aber Du bist nicht der erste, der Minen anspricht.

Ich frage mich nur, wie man das am elegantesten einbauen könnte?! Da wären viele Wege denkbar: bei Bitcoin könnte man seine Mining-Adresse(n) konfigurieren und die entsprechenden Einzahlungen könnte der CT via Blockchain-Api abholen. Bei anderen Coins ginge das wahrscheinlichlich auch, allerdings bin ich da technisch nicht so tief drin, um den Aufwand realistisch einschätzen zu können.

Da ich selbst nicht mine, muss ich nachfragen: bieten die gängigen Mining-Pools denn auch so etwas wie einen CSV- oder anderen Daten Export, für den man dann entsprechende Importe in den CT einbauen könnte? Oder gar eine API, mit der man die Ertragsdaten abholen kann?

Dann wäre da noch der steuerliche Aspekt: aktuell gibt es nach meinem Wissen zwei Einschätzungen hierzu: die einen sagen, Mining-Erträge sind (im privaten Bereich) steuerfrei, weil für eine Bewertung als privates Veräußerungsgeschäft der Part der Anschaffung fehlt. Weiter verbreitet ist die Einschätzung, dass Coins mit dem tagesaktuellen Wert bewertet werden müssen und sich der Gewinn bei Veräußerung aus der Differenz von den damaligen und den Kurs bei Verkauf ergibt (wobei Aufwände für Hardware, Strom usw. Abgezogen werden können).

Wenn Du hier Vorschläge hast: gerne her damit! 

Hab mir die Software mal angeschaut sieht sehr Professionell aus.
Allerdings wenn ich damit meine Multipool mining erträge und trades berechnen möchte hab ich kein leben mehr.

Version 0.8.5.2 ist live!

...ist ein reines Bugfix (und ein wenig Kosmetik): der CT speichert jetzt nach Auswahl des Speicherorts für die Daten und Konfigurationsdateien auch wirklich nur noch an die gewünschten Stellen. Außerdem ist der (noch aus der Debug-Phase) stammende "Button1" wieder aus der Übersicht entfernt.

Wie immer: viel Spaß!

Version 0.8.5 ist live!

...mit diesen verbesserten/geänderten Punkten:

• Kraken-Import: kann jetzt zuverlässiger mit vielen gleichzeitigen Trades umgehen. (Das Problem bestand darin, dass die Trade-Zeilen intern immer nach Zeitpunkt sortiert werden, damit die Reihenfolge, in der man die Ledger-Seiten in den CT kopiert, keine Rolle spielt. Wenn aber viele Trades zur exakt gleichen Sekunde ausgeführt wurden, sind Zeilen durcheinander gewürfelt worden, was den Import aus dem Tritt gebracht hat... Mann, es wird wirklich Zeit für einen vernünftigen API-Import! Mal sehen, ob ich dafür demnächst etwas Zeit freischaufeln kann.)
• Trades in US-Dollar: Die Wechselkursdaten können jetzt in der Tabellenbearbeitung angezeigt (und bei Bedarf bearbeitet) werden. Außerdem reagiert die Gewinn-Verlust-Berechnung jetzt intelligenter auf fehlende Wechselkursinformationen: der Stichtag für die Berechnung wird bei Bedarf automatisch auf das letzte Datum der vorliegenden USD-Wechselkursdaten zurückgesetzt.
• Portabiliät: Bisher sind lokale Einstellungen (also z.B. zuletzt genutzer Import, Einstellungen zum Online-Offline-Modus und so etwas) in den .NET-eigenen Konfigurationsdateien abgelegt worden. Jetzt werden Anwendungs-Einstellungen immer am selben Speicherort wie die Datenbank gespeichert. Da jener unter Extras->Einstellungen konfigurierbar ist, ist der CT nun inkl. aller Einstellungen portabel.

Viel Spaß damit!

Hallo FlensGold, hatte schon verstanden, dass Du den Kraken-Import meinst, das ergibt sich aus der Problembeschreibung.  Für den Import würde ich Chrome empfehlen, schaue mir übers WE aber auch gern nochmal an, was mit Firefox bzw. IE passiert. Wenn die beiden Browser tatsächlich andere Trennzeichen zwischen die Spalten packen, müsste ich den CT dahingehend bestimmt noch einmal anpassen.

Wenn sich das Importfenster sang- und klanglos schließt, ist das ein Indiz dafür, dass keine einzige Zeile als gültig formatiert erkannt würde.

Was die Meldung mit den fehlenden Gegenbuchungen angeht: in der Ledger-History wird ja jeder Kauf oder Verkauf in jeweils 2 Zeilen dargestellt: eine, in der das Coinkonto aufgeladen, und eine, in der das Fiat-Konto entladen wird (oder halt umgekehrt). Wenn der CT bei einem Kauf oder Verkauf nur eine einzige Buchungszeile findet, kommt die Meldung. Wenn Du möchtest, kannst Du mir gern deine History (auch auszugsweise) als PM oder an [email protected] schicken, dann schaue ich mir das mal genauer an.

Der Kraken Export läuft per Copy&Paste aus dem Browser heraus in die CoinTracer Anwendung.

Irgendwas scheint hier gewaltig schief zu laufen...


Wie öffnest Du das im Browser???

Wollte das Tool gerade mal testen. Gibt es Empfehlungen bzgl. des Browser/der Einstellungen?
Mit IE/FF bekomme ich gar nichts importiert, das Importfenster schließt sich ohne Rückmeldung nach dem Klick auf "Importieren".
Mit Chrome scheint es zu klappen, allerdings erhalte ich hier immer wieder Fehler wg. vermeintlich fehlender Gegenbuchungen, so dass auch hier kein reibungsloser Import möglich ist.
Die Darstellung in der "Ledger-History" beim CoinTracer ist bei Chrome auch etwas anders als bei den anderen Browser. IE/FF scheinen hier noch Trennzeichen einzubauen, das Eingabefeld sieht etwas chaotisch aus. Bei Chrome herrscht da leserliche Ordnung
Grüße