Topic: CoinTracking - Gewinn/Verlust Portfolio und Steuer Reporting für digitale Coins - page 29. (Read 211510 times)

Super danke so wirds gemacht.
Ich habe vorhin noch 5 TX nachimportiert bekommen... mal sehen ob auch der Rest noch in den nächsten Nächten folgt.
Falls nicht werde ich mich direkt an den Support wenden und gleich die API Daten mitsenden damit das im Detail geprüft werden kann.
Danke für die schnelle Antwort und es bleibt spannend

Ich denke du hattest das für beide gemeldeten Probleme gemeint, oder?
Also 1x die Direktanbindung der BSC und 1x den API Import.

@mole0815
Genau. Bitte noch über das Wochenende warten und sonst die Infos per Ticket/Mail senden. Danke.

Ich habe gestern meine ersten Pancakeswap Erfahrungen sammeln dürfen und dabei natürlich auch direkt cointracking berücksichtigt.
Jetzt aber zum Problem - die BSC Anbindung: https://cointracking.info/import/bc_address/ funktioniert ja wie von ETH gewohnt.
Nun wurde heute Nacht aber keine TX importiert und ich habe vermutlich auch die Erklärung dafür gefunden:

Geprüft wird: https://explorer.binance.org/address/xxx (wo keine Daten zu sehen sind)
Lt. https://bscscan.com/address/xxx ist aber alles korekt.

Ist das nun eine Sache von Binance oder prüft CT den falschen Explorer?

//edit: Binance habe ich per API angebunden und der Job läuft lt. auch korrekt. Nur fehlt der Großteil der Vorgänge von gestern... dabei handelt es sich um normale trades, ein Direktswap und auch "Dust to BNB".
Soll ich für gestern lieber zusätzlich zur Anbindung 1x per CSV importieren oder noch ein paar Nächte abwarten bzw. alle Daten zur Analyse per Mail senden?

Updates und Verbesserungen
API
- Neuer API Import: KuCoin Futures
- Bybit und viele weitere Börsen der Live Balance Ansicht hinzugefügt
- Kraken (KSM Staking optimiert)
- FTX (Gebühren für Market Order Transaktionen optimiert)

CSV
- Neuer CSV Import: Digital Surge, Hodlnaut & Criptan
- OKEX (neues CSV Format hinzugefügt)
- Binance (Optimierung für Commission Rebate, Staking & Liquid Swaps)
- Trezor (Unterstützung für das neue CSV Format)
- Nexo (Unterstützung für das neue CSV Format)
- Kraken (KSM Staking optimiert)
- Ledger (Delegate und Reveal verbessert)
- BlockFi (Unterstützung für ACH Trades)

Blockchain
- Weitere Blockchains der Live Balance Ansicht hinzugefügt
- DFI Chain via Altcoin Importer (nur Basistransaktionen, kein LP)
- Verbesserungen für AVAX, SOLANA, ETH & POLKADOT

Sonstiges
- Mehrere Anpassungen zu Coin Tickern
- Steuerbericht Updates: Aktualisierter US Steuerbericht, Verbesserungen für den Flowchart, HMRC und ACB
- Neue Partner Benefits: Cryptoquant & Steuerbot

Quelle: https://cointracking.info/new_features.php

@Hilde X
Das kann passieren in dem sich so schnell ändernden Umfeld. Bitte alles manuell eintragen, was nicht automatisch importiert wird und Auswirkungen auf Bilanzen hat.
Du kannst auch gern ein Ticket/E-Mail senden mit Bsp. TX hash und wallet ID. Dann nehmen wir es auf die Verbesserungsliste.

Hallo Andreas!

Ich frage mich gerade, wie bei Etherscan als "Internal Txns" klassifizierte Transaktionen importiert werden. Das sind Smart Contract Transaktionen, z. B. Überweisungen aus Blockfi oder auch manche DEX-Trades.

Trotz Auto-Imports des Wallets tauchen diese bei mir nicht auf.  

@Soonandwaite Der Fehler ist hier eindeutig. Evtl. hast du keine oder eine falsche Passphrase (große Buchstaben oder Leerzeichen) verwendet. Diese muss beim Erstellen des Keys auf Coinbase Pro eingegeben werden.

Ich habe ein Problem mit der Coinbase Pro Api. Ich habe alles so gemacht wie beschrieben aber bekommme folgende Fehlermeldung :

So soll man es Eintragen



Und diese Fehlermeldung kommt dann :



Jemand einen Plan was es sein könnte.Komme einfach nicht weiter mit dieser Api dort : Danke

Danke – ja, diese Frage ist relativ nah am Thema Steuerberatung. Ein Gespräch mit meinem SB ist für 2020/21 so oder so unerlässlich.

Das mit der Depottrennung werde ich ausprobieren… die Uralt-ETH, zumindest die relevanten, dürften auf einer anderen Adresse gelegen haben, d.h. die Chancen stehen vmtl gut, dass das funktioniert. Besten Dank.

@allyouracid
Bitteschön, sehr gern.
Wir sind keine Steuerberater, jedoch würde ich hier die Depottrennung verwenden und ggf. diesen Trade auf einer separaten Börse stattfinden lassen.
Wenn natürlich alles in deinem ETH Wallet stattfindet, wo auch Uralt-ETHs liegen, nimmt er natürlich diese zuerst. Und bei FIFO ohne Depottrennung die ältesten im gesamten Account.

Vielen, vielen Dank – Deine Hilfe hier ist einfach großartig.
Bzgl. Binance werde ich wohl deren Support mal anschreiben. Vielleicht reagieren sie ja irgendwann mal.  


Nachtrag:

…und schon wieder eine Frage:

Angenommen, ich habe einen Uralt-Coin ABC, den ich über die steuerfreie Einjahresfrist halte. Diesen verkaufe ich gegen ETH auf einem Dex, und die ETH tausche ich direkt danach gegen Tezos. Nun habe ich dank FIFO das Problem, dass er zwar den Verkauf von ABC korrekt als steuerfrei erkennt, aber für den folgenden Verkauf dieser frisch "gewonnenen" ETH irgendwelche Uralt-ETH heranzieht, die damals zu einem Bruchteil des Preises gekauft wurden. Resultat sind trotz steuerfreiem Verkauf von ABC astronomische "Gewinne" durch den Verkauf dieser "Vehikel-ETH", die der Dex mir reingedrückt hat.

Meine Idee: einfach eine Tradegruppe "steuerfrei" machen und den ABC→ETH-Trade da reinpacken, und diese Gruppe dann beim Generieren des Steuerreports ausschließen. Dann wiederum habe ich das Problem, dass, wenn ich irgendwann später nochmal in völlig anderem Kontext ETH handle (verkaufe), meine ETH-Pools leer sind und er einen Kauf am selben Tag für 0€ annimmt. Also wieder unverhältnismäßig hohe Gewinne.

Gibt es für dieses Szenario eine sinnvolle Vorgehensweise? Irgendwie müssen die ETH ja dann zum aktuellen Preis in meinem Portfolio verwendbar werden, damit sie Bestandteil weiterer Gewinn-/Verlustrechnungen ab Eingang sind. Ggf. die ABC-Coins als Ausgabe (oder Auszahlung? Wo ist der Unterschied?) eintragen und die ETH als Einnahme, beides jeweils zum derzeit aktuellen Preis? 🤔

@allyouracid
Wenn API V1 (ohne Slider) gute Ergebnisse liefert, dann reicht diese aus. Wenn V2 dann eben in Verbindung mit dem "generate all statement" Dateien (oder eben auch ohne und manuell ein paar Transaktionen ergänzen). Das bleibt dir überlassen.

Gehebelte Trades, Margin/Futures, immer als Gewinn und Verlust (PnL) eintragen - also die Resultate aus den gehebelten Trades. Und nicht die Trades selbst.
Dafür gibt es separate Transaktionsarten "Margin Gewinn" oder "Derivate/Futures Verlust".
Binance stellt nur leider die Margin PnL Daten pro Trade nicht bereit und sagt nicht, wie man aus Margin Trades den Gewinn/Verlust errechnen kann. Wir bitten jeden Kunden, bei Binance danach zu fragen, damit sie diese Daten wie andere Börsen (z.B. Kraken) bereit stellen. Binance hat uns auch nach mehrmaligem Nachfragen nicht mitgeteilt, wie diese PnL Daten zu berechnen sind.
Ohne diese Daten gibt es keine Möglichkeit, diese sauber für Warnungsfreie Steuerberichte einzutragen.
Es gibt hier derzeit evtl. nur die Möglichkeit, die Tages PnL Daten zu verwenden. Jedoch wissen wir nicht, wo diese Daten genau zu finden sind und ob dies funktioniert.
Alternativ könnte man diese Margin Trades als "Black Box" evtl. behandeln wie hier beschrieben: Fehlende Daten durch Börse/Wallet nicht mehr vorhanden oder keinen Zugriff (https://cointracking.freshdesk.com/a/solutions/articles/29000034626?lang=de)
D.h. den Slider der Margin Trades deaktiviert lassen, weil dir die Trades nichts nützen und du die PnL Daten auch nicht bekommst. Bei Futures stellt Binance die PnL Daten bereit.

Kommt mir grad noch ein Gedanke bzgl. des Binance API Imports: empfiehlt es sich grundsätzlich, den Import über die API v2 zu machen? Die verlinkten Hilfeartikel und Anmerkungen erzeugen den Eindruck (zumindest bei mir), dass das hauptsächlich in Kombination mit dem CSV Komplettimport sinnvoll ist, um die Daten, die nicht über die API reinkommen, vollständig zu kriegen.
Nun habe ich mir das Hilfedoc angeschaut, und die Punkte, die dort genannt werden, treffen auf mich entweder nicht oder nur vernachlässigbar geringfügig zu, d.h. die Abweichungen, die ohne den CSV-Import (für den ich ein paar Monate bräuchte, dank der Binance-Exportbeschränkung von 5x 3 Monate pro Monat) entstehen, kann ich problemlos hintenan stellen.

Auch sagt die Doku, dass man Binance Margin Trading am besten bleiben lassen sollte, weil es nicht vernünftig auswertbar ist. Was nun, wenn man es trotzdem gemacht hat? Bei mir entstehen da so Probleme, dass z.B. bei einem angenommenen Litecoin Short der Verkauf der geliehenen LTC beim Steuerreport die Meldung auslöst, dass es keinen Topf mehr mit LTC gibt und daher ein Kauf am selben Tag für 0€ angenommen wird. Das wiederum resultiert in einem angenommenen Profit in Höhe des Wertes der verkauften LTC, was die errechnete Steuerlast in die Höhe treibt. Ist es sinnvoll, einfach im API Import Margin Trades komplett auszuschließen? Vermutlich nicht…?

Es ist nur ein Display Timeout. Wir sind hier bereits an Verbesserungen dran sodass dies dann nicht mehr auftritt.
Es ist wie beschrieben dann dennoch erfolgreich.
Danke auch für die technischen Infos.

Ich tippe auf die Anzahl der Trades, sodass entweder irgendein Timeout in eurem Nginx oder PHP* getriggert wird oder eben der Request an die Datenbank mit etwas über 110.000 Einträgen einfach zu groß ist.
Ich denke, das sieht soweit gut aus mit der Anzahl. Trotzdem habe ich mir die Seite zur Tx-Validierung mal angeschaut und dabei noch einen "Leerzeichen am Ende des Börsennamens" (das Feld war einfach leer, da der Eintrag nicht auf einer Börse stattfand - habe es jetzt auf "Private Buys" oder sowas geändert) und ein paar Negativwerte bei Trades von stex.com gefunden. Dass diese Börse es nicht hinkriegt, einen vernünftigen Datenexport umzusetzen, wundert mich nicht, muss ich mal so sagen. ^^

Nach der Korrektur aller Fehlermeldungen habe ich nochmal ein Backup versucht zu erstellen. Dieses Mal mit Google Chrome. Problem besteht weiterhin, was meinen Eindruck oben zu erhärten scheint.

* Kleiner Hinweis: ihr könnt eure Response Header z.B. in der Nginx Config anpassen, sodass eure Webserver-Software + Version sowie verwendeter Preprocessor nicht "geleakt" werden. Kein großes Drama, aber macht es potenziellen Angreifern nochmal ein kleines bisschen schwerer.

@allyouracid
Könnte an der Anzahl der Transaktionen liegen plus ggf. Browser.
Du siehst im Backup die Anzahl der TX und nach dem Restore auf dem Dashboard auch bzw. auf Coins Eintragen Seiten. Wenn diese übereinstimmt, ist alles vorhanden.
Eine weitere Ursache könnten fehlerhafte Einträge sein auf der https://cointracking.info/validate_transactions.php?notices=0

Mal ne Frage: warum ist es eigentlich so, dass Cointracking jedes Mal, wenn ich ein Backup wiederherstelle, eine Viertelstunde lang nicht verwendbar ist? Dann laden die Tabs, und sie laden und laden und laden. Irgendwann mache ich dann irgendwas anderes (einkaufen, schlafen gehen) und wenn ich wieder zurück bin, funktioniert es wieder.
Ist das was Globales? Also, verursache das Wiederherstellen von 6-stelliger Anzahl an Records einen Ausfall für alle oder nur für mich?

Edit: Frau kann die Seite problemlos aufrufen, und ich kann es in einem anderen Browser (nicht eingeloggt) auch. Aber im Firefox (eingeloggt) kriege ich nur Ladebalken.

Edit2: und wenn ich im Chrome versuche, mich einzuloggen, geht auch nix mehr. Bzw. ich konnte mich einloggen, aber es dauert eeeeeewig, und sobald ich im Menü irgendwo hin navigieren will, passiert wieder nix. Account allyourbase, könnt ihr das reparieren bitte? ^^

Edit3: Wiederherstellung des letzten Backups bringt das hier:


Nun weiß ich nicht, ob die Daten korrekt wiederhergestellt sind. Sieht zahlenmäßig ok aus, aber drauf verlassen möchte ich mich nach einer Fehlermeldung beim Wiederherstellen lieber nicht - dafür stecken schon zu viele hundert Stunden da drin, als dass ich jetzt einen potenziell fehlerhaften Stand weiter bearbeiten möchte.

@domitian
Wenn es sich um LP Transaktionen handelt, dann bitte so eintragen oder alternativ als Trade https://cointracking.freshdesk.com/a/solutions/articles/29000037542?lang=de

Hallo,

ich habe eine Zeit lang Farming  mit der WANChain betrieben, hier die Wallet auf Wanscan: https://www.wanscan.org/address/0xC661671289399Ef9a970eab54B1f18820Aa4F09d?page=1
Ich habe keinen Plan wie man das alles in Cointracking eintragen muss.
Mein Prozess war etwa so:
1) Transferieren von XRP nach WANXRP(gewrapped)
2) Aufteilen 50-50 dieser nach WANXRP und WAN
3) Diese Anteile in einen Pool gegeben und WSLP als Liquidity Tokens erhalten.
4) WSLP dann in das Farmin Zookeeper zur Verfügung gestellt: https://www.zookeeper.finance/zoo
5) Immer mal wieder "geerntet" und dafür ZOO und WASP tokens erhalten.
6) WASP un ZOO immer wieder mal zum nativen WAN token verkauft.
7) Am Ende die gewrappten WANXRP wieder nach XRP konvertiert.

Kann mir hier jemand helfen, wie man all diese Tranksaktionen korrekt erfasst?
Ich habe den Support schon angeschrieben, aber die haben nur auf die Liquidity-Mining Seite verwiesen: https://cointracking.freshdesk.com/de/support/solutions/articles/29000038185-wie-werden-liquidity-pool-transaktionen-importiert-
Ich denke aber, dass mein Fall komplizierter ist.

Danke und schöne Feiertage

Großartig! Danke für die schnelle Hilfe & den Link !