Wie kann ich auf die alte optik umschalten? Die Schrift ist ja ganz übel wie 8bit Grafik vom NES .
Ich dachte auch ich guck nicht richtig - Schriften unlesbar und nicht zoombar, Grafiken sehen aus wie vom Viertklässler -WARUM NUR?  Das Design war doch top! War alles kristallklar und nun nur unscharfer Dreck von dem man Augenkrebs bekommt - unbedingt wieder zurück zum alten Design!!!!! |
|
|
|
Hi All
mal eine andere Frage.
Hat jemand die App auf einem Android 4.4. Installiert
Gruß
Tut mir leid, ich war lange nicht mehr im Museum  |
|
|
|
Ich habe eine Frage bzgl. Verlustverrechnung.
Nach meinen Infos täuschen sich einige Steuerberater in Details, da die Materie noch immer recht neu ist und zudem einige Regelungen wohl verschieden ausgelegt werden.
Jedoch weiß ich als Laie nicht vorher, wie gut sich der Steuerberater wirklich auskennt.
Deshalb würde ich gern die Richtigkeit der Aussage meines Steuerberaters bestätigen lassen.
Dieser meint:
"Gewinne, die durch einen Verkauf nach einem Jahr entstanden sind, sind steuerfrei. Gleiches gilt für Verluste die nach einem Jahr der Anschaffung entstanden sind. Sie dürfen sich nicht auf die Steuerbelastung auswirken. Aus diesem Grund haben wir die Long-Term-Verluste bei den privaten Veräußerungsgeschäften nicht mit angeben können."
Das würde ja heißen, dass ich u.U. für Gesamtverluste auch noch Steuern zahlen muss.
Beispiel:
2017 Kauf von 1 Bitcoin zum Kurs von 20.000 EUR.
2019 Verkauf dieses Bitcoins zum Kurs von 5000.- EUR
>>> Verlust: 15000.- EUR
Wenn ich nun 2019 durch steuerpflichtiges Trading (unter 1 Jahr Haltezeit) mit ETH z.B. 10000.- EUR Gewinn realisiert habe, so hätte ich 2019 noch immer einen Gesamtverlust von 5000.- EUR.
Kann nun der Verlust tatsächlich nicht angerechnet werden?
Da hat Dein Steuerberater Recht. Bei privaten Veräußerungsgeschäften darfst Du nur die short-term Gewinne mit Deinen short-term Verlusten verrechnen. Dafür sind Deine long-term Gewinne steuerfrei und auf Deinen long-term Verlusten bleibst Du sitzen. Deswegen kann es manchmal sinnvoll sein Verlustpostionen kurz Ablauf der Jahresfrist zu verkaufen um sie mt Deinen short-term Gewinnen zu verrechnen zu dürfen. Kannst sie danach ja gleich wieder kaufen - wenn Du die dann über ein Jahr hältst und Gewinn machst ist es wieder steuerfrei. |
|
|
|
Hallo,
ich habe eine Frage hierzu und bin mir nicht sicher ob ggf. schon mal geschrieben.
CT rechnet ja bei Altcoin->BTC Trades immer den aktuellen € Preis aus.
Short Trading: Nun habe ich z.b. für einen Altcoin (EK:1000€) Verkauf 0,1 BTC bekommen die an dem Tag 1500€ wert sind.
Somit müsste ich 500€ versteuern, oder?
Aber die 0,1 BTC sind beim erstellen der Steuererklärung nur noch 500€ wert und ich verkaufe die 0,1BTC nicht, somit sind diese für die Steuererklärung nicht relevant, da unrealisierter Verlust/Gewinn.
Oder verstehe ich da was falsch, bitte um Aufklärung.
Vielen Dank und grüße aus Bayern!
Du machst den typischen Anfängerdenkfehler bei der Steuer  Sobald Du einen Coin verkaufst - egal on Bitcoin oder Altcoin - muß der Gewinn/Verlust zu dem Verkaufzeitpunkt in EUR berechnet werden. Du kannst also nie Altcoin gegen Bitcoin "tauschen". Es ist der Verkaufwert in EUR-Wert festzustellen und damit kaufst Du dann Bitcoin. Viele denken Sie würden direkt von Altcoin zu Bitcoin gehen, das ist steuerlich aber nicht der Fall. Dein Beispiel: Kauf Altcoin für 1000 EUR Verkauf Altcoin, Wertfeststellung: 1500 EUR, Gewinn: 500 EUR (zu versteuern) Kauf 0,1 Bitcoin für 1500 EUR Die 500 EUR Gewinn sind also zu versteuern - auch wenn Du die nie in EUR auf deinem Bankkonto hattest. Was Du mit den 0,1 Bitcoin nun machst ist eine andere Geschichte: Wenn Du sie zu 500 EUR verkauft machst Du 1000 EUR Verlust. Diesen Verlust darfst mit Deinen Gewinnen verrechnen (nur wenn Haltezeit unter einem Jahr): Verkauf 0,1 Bitcoin für 500 EUR. Verlust: 1000 EUR. (Verlust mit Gewinn direkt verrechenbar wenn innerhalb desselben Jahres und Haltezeit uinter einem Jahr) Gesamtgewinn/verlust: -500 EUR Wenn Du die 0,1 Bitcoin nicht verkaufst bzw. erst nach über einem Jahr kannst Du den Verlust durch den Bitcoinabsturz nicht mehr mit Deinem Gewinn verrechnen. Dann mußt Du die 500 EUR Gewinn vesteuern und bleibst auf den 1000 EUR Verlust durch die Bitcoins sitzen ... aber Du könntest die 0,1 BTC jetzt verkaufen und den Verlust realisieren, dadurch mit dem Gewinn verrechnen und morgen wieder 0,1 BTC kaufen und Jahre halten... |
|
|
|
Dann erstmal danke für die gute Idee.  Das Problem ist ja nicht die Frage ob das steurrechtlich zulässig ist, da muss jeder selber entscheiden wie er sich bei der unsicheren Rechtslage verhält. Und es ist auch nicht abzusehen ob und wann das geklärt wird. Es geht vielmehr darum ob es möglich ist die gleiche Vorgehensweise wie beim Bitcoin auch bei Altcoins anzuwenden. Es gibt ja sicherlich viele die nicht nur Bitcoin langfristig halten wollen (um aus der 1 Jahres Frist zu kommen), sondern auch Ether, Bitcoin Cash, Litecoin und andere. Es ist ja kein Problem Altcoins langfristig mit Cointracking zu halten. Mache ich ja auch. Darfst halt nur nicht mit dem Altcoin zusätzlich traden. Immer nur zukaufen bis ein jahr vorbei ist Es wird automatisch von CT für jeden Coin eine eigene FIFO Berechnung gemacht. Nur mehrere FIFO pro Coin geht halt nicht. Ich finde es gut, daß Cointracking nur die rechtlich sicherste Lösung anbietet. |
|
|
|
Hallo,
ich habe gerade ein Feature request Ticket erstellt. Aber da der Support wohl zur Zeit sehr ausgelastet ist und dieses Thema vielleicht auch andere interessiert erläutere ich das hier nochmal. (Vielleicht hat ja auch schon jemand eine andere Lösung)
Es geht um das Problem eine separate FIFO/LIFO Berechnung pro Account/Wallet zu machen. Das ist insbesondere dann wichtig wenn man coins in einer Wallet hält und gleichzeitig auf einem Exchange handelt. Bei der Gewinnberechnung über alle Accounts werden so die Haltefristen der coins in der wallet nicht korrekt berücksichtigt.
Hier im Forum kam die großartige Idee für die Wallet über die eine separate FIFO/LIFO berechnung durchgeführt werden soll eine eigen Währung anzulegen. Das sieht dann folgendermaßen aus:
1. eigene Währung erstellen z.B. BTC_paperwallet
2. eigenen Preis für die Währung festlegen: BTC_paperwallet = 1 BTC
Und schon wird für die BTC in der wallet eine separate berechnung durchgeführt.
Das Problem ist aber das dies für Altcoins nicht funktioniert, da der Preis für eigene Währungen nur in BTC angegeben werden kann.
Wenn man den Preis für die Eigene Währung auch in Altcoins angeben könnte wäre die getrennte FIFO berechnung sehr einfach. Es Müsste nochnichtmal ein beliebiger Preis in Altcoins angegeben werden könnten. Man müsste den Preis eben nur auf eine andere Währung fixieren können. Also LTC_paperwallet= LTC, ETH_wallet=ETH, ZEC_wallet=ZEC,...
Ich hoffe das war verständlich. Beste Grüße.
Das Thema hatte ich ja schon vor zwei Jahren gestartet - das Problem ist, daß es immer noch überhaupt nicht geklärt ist ob es steuerlich zulässig ist die Coins in beliebig viele einzelne FIFO-Wallets aufzuteilen. Mit der FIFO Berechnung über alle Börsen und Coins hinweg ist man auf der sicheren Seite. Ich habe das mit dem getrennten Paperwallet für Bitcoin gemacht (der von Dir genannte Vorschlag oben stammte bestimmt von mir) und es ist 2016 auch nicht beanstandet worden vom FA aber die Bitcoins wurden auch nachweislich nicht bewegt. Für Altcoins würde ich persönlich keine eigenen "Trading-Wallets" anlegen wollen. |
|
|
|
Guten Morgen,
wie geht Ihr vor, wenn Ihr wegen euren Veräußerungsgeschäften von Kryptowährungen die Steuer abgebt, was ist denn alles für die Abgabe notwendig?
Reicht es aus, alleine die Anlage SO mit den Gewinnen und Verlusten innerhalb des Steuerjahres zu erfassen, oder legt man noch irgendwelche Anlagen/Belege bei, wie beispielsweise Auszüge aus dem Steuer-Report von Cointracking? Oder reicht man diese Belege nur auf Anfrage des Finanzamtes nach?
Der Ausdruck der Berichte des Steuerreports mit Inhalten (z.B. Kapitalertragsbericht, Einkommensbericht, ...) sollte mindestens als Anhang beigelegt werden. Stand heute müssen auch noch die Tradinggebühren gefiltert und ausgedruckt werden, da diese bei den Steuerreports nicht berücksichtigt werden. https://cointracking.freshdesk.com/de/support/solutions/articles/29000018276-fehlende-gebühren-im-steuerreport Wie bitte??? Die Gebühren werden nicht abgezogen??? Aber darf ich nicht nur die Gebühren für short-term abziehen? Die für steuerfreie long-term verkäufe darf ich doch nicht als Kosten abziehen oder? Wie soll ich das denn unter "fees" trennen? |
|
|
|
Nein, daran lag es doch nicht. Es bleibt weiterhin egal ob ich bitcoin.de oder bitcoinaverage als Kursbasis einstelle - es wird der identische detailierte Steuereport erzeigt nur mit anderem Datum/Uhrzeit. Da stimmt also etwas nicht.
Das Einstellen der Kursbasis hat meines Wissens nur Auswirkungen auf die FIAT-Bewertung zum Zeitpunkt des Imports/Erfassens der Transaktion und verändert diese nachträglich nicht. Wenn du im Steuerreport nur auf die realisierten Gewinne/Verluste schaust sollte dort keine Änderung aufgrund des nachträglichen Umstellens erfolgen. Danke, das könnte sein aber ich meine mich zu erinnern, daß ich im Sommer schonmal umgestellt hatte und es dann in der detailierten Berechnung auch unterschiedliche Kurse angezeigt wurden. Umd das zu prüfen wollte ich nun alle Trades exportieren als CSV, meinen Account leeren und dann neu einlesen per CSV import. Das klappt aber nur wenn ich einige wenige Trades nehme aber wenn ich alle importieren will (930kb) sagt Cointracking "Die Importdaten sehen gut aus" und zeigt aber in der Vorschau keinerlei Trades ... gibt es vielleicht eine Größenbeschränkung für den CSV import? So siehts aus wenn ich die große Datei importieren will: Validierung: Datensätze in der Import Datei: 0, Trades: 0 Hinweise: Doppelte Trades gefunden: 0 Fehler: Leerer Timestamp: 0, Leere Werte: 0 Habe die Datei nicht verändert. Ideen? |
|
|
|
Bugreport:
Es macht keinen Unterschied ob ich "bitcoinaverage" oder "bitcoin.de" als Datenquelle auswähle, der Steuerreport ergibt genau dasselbe, auch in der detailierten Ansicht!
Habe natürlich die coinberechnung nach Umstellung neu gemacht - da stimmt etwas ganz und gar nicht!
update: Es liegt daran, daß im Steuerreport alle Links zur "detalierten Berechnung" identisch sind. Sie enden alle auf /?tax=85 Es wird also die Nummer des Steuerreports nicht richtig übergeben und man landet logischerweise immer auf derselben Seite. Ich hatte viele Reports, über 40 Stück. Habe nun fast alle gelöscht bis auf einige und nun wird auch die Reportnummer in den Links wieder korrekt übergeben. Nein, daran lag es doch nicht. Es bleibt weiterhin egal ob ich bitcoin.de oder bitcoinaverage als Kursbasis einstelle - es wird der identische detailierte Steuereport erzeigt nur mit anderem Datum/Uhrzeit. Da stimmt also etwas nicht. |
|
|
|
Bugreport:
Es macht keinen Unterschied ob ich "bitcoinaverage" oder "bitcoin.de" als Datenquelle auswähle, der Steuerreport ergibt genau dasselbe, auch in der detailierten Ansicht!
Habe natürlich die coinberechnung nach Umstellung neu gemacht - da stimmt etwas ganz und gar nicht!
update: Es liegt daran, daß im Steuerreport alle Links zur "detalierten Berechnung" identisch sind. Sie enden alle auf /?tax=85 Es wird also die Nummer des Steuerreports nicht richtig übergeben und man landet logischerweise immer auf derselben Seite. Ich hatte viele Reports, über 40 Stück. Habe nun fast alle gelöscht bis auf einige und nun wird auch die Reportnummer in den Links wieder korrekt übergeben. |
|
|
|
|
Bugreport:
Es macht keinen Unterschied ob ich "bitcoinaverage" oder "bitcoin.de" als Datenquelle auswähle, der Steuerreport ergibt genau dasselbe, auch in der detailierten Ansicht!
Habe natürlich die coinberechnung nach Umstellung neu gemacht - da stimmt etwas ganz und gar nicht!
|
|
|
|
Ich habe als Kursdatenquelle bitcoin.de eingestellt.
Nun ist es aber so, daß der im Steuerreport angezeigte Kurs immer ca. 5-10% über dem Kurs bei bitcoin.de liegt! Und zwar egal welchen Zeitraum ich mir anschaue:
augenblicklicher Kurs, 3h Mittel, 12h Mittel, Tageskurs ...
Was wird da also als Kursdaten verwendet?
Der Kurs auf dem Marktplatz Bitcoin.de ist historisch niedriger als auf anderen Börsen, wenn du diesen Kurs bewusst wählst und damit vom default abweichst, ist das Ergebnis genau wie du schreibst. Ich habe ja extra auf bitcoin.de umgestellt weil "Bitcoin Average" noch falschere Kurse lieferte. Da sind die Kurse häufig über 10% höher oder niedriger als die tatsächlichen Verkaufspreise bei bitcoin.de und kraken. Aber darum ging es mir nicht. Meine Frage war welcher bitcoin.de Kurs verwendet wird, da der in Cointracking verwendete zu dem Zeitpunkt nie bei bitcoin.de erreicht wurde. Weder im Durchschnitt der letzten 3, 12 oder 24h. Das muß ja bei einer Prüfung nachvollziehbar sein. Deswegen habe ich auch zu bitcoin.de verwendet da dort das deutsche Finanzamt noch am ehesten das nachvollziehen kann. Wenn aber im Steuerreport z.B. 12881 EUR um 11 Uhr heute drin stehen und man dann sich die Kurse von bitcoin.de um 11 Uhr anschaut und dort zu diesem Zeitpunkt dieser Kurs nie auch nur ansatzsweise ähnlich ist kann das doch nicht angehen  |
|
|
|
Berechnungsgrundlage Eurokurs? Wenn ich z.B. auf Bittrex Altcoins verkaufe muß ja deren Wert in EUR festgehalten werden. Den verwendeten Kurs sehe ich dann in der detailierten Berechnung im Steuerreport. Ich habe als Kursdatenquelle bitcoin.de eingestellt. Nun ist es aber so, daß der im Steuerreport angezeigte Kurs immer ca. 5-10% über dem Kurs bei bitcoin.de liegt! Und zwar egal welchen Zeitraum ich mir anschaue: augenblicklicher Kurs, 3h Mittel, 12h Mittel, Tageskurs ... Was wird da also als Kursdaten verwendet? Das Problem ist, wenn ich die nun erhaltenen Bitcoins gleich anschließend gegen EUR verkaufe mache ich jedesmal steuerlich 5-10% Verlust ... Beispiel Testrade: heute, 26.12 um 11 Uhr für 1 BTC NEO verkauft auf Bittrex: Kostenbasis BTC/EUR Wert laut detailierter Berechnung im Steuerreport: 12881 EUR Kurs Kraken: 12687 EUR Kurs Bitcoin.de gew. 3h: 12550 EUR Kurs Bitcoin.de gew. 12h: 12251 EUR Kurs Bitcoin.de gew. 24h: 11962 EUR Insbesondere wenn ich steuerfreie Altcoins (Haltezeit über ein Jahr) gegen Bitcoins verkaufe und dann anschließend die Bitcoins gegen Euro verkaufe erhöht sich somit der steuerfreie (longterm) Gewinn und der zu versteuerende (short term) Gewinn verringert sich. Das ist zwar toll zum Steuern sparen aber nachvollziehen kann ich das nicht |
|
|
|
Hallo allerseits, ich habe einen sehr interessanten Artikel zu diesem Thema gefunden ( https://www.meetup.com/de-DE/invitations/messages/boards/thread/50804138/post/130404308/). Darin steht unter anderem: Völlig steuerfrei bleibt der Verkauf einer privat geminten Coin. Dies teilte das Finanzministerium auf eine Anfrage von heise online mit. Nach Auffassung der Finanzverwaltung fehlt es hier an einer Anschaffung, weshalb keinerlei Frist in Lauf gesetzt wird.Das hatte ich bisher anders verstanden. Kann das irgendjemand bestätigen? Der genannte Heiseartikel stammt aus 2013 ... https://www.heise.de/newsticker/meldung/Einkuenfte-aus-Bitcoin-Mining-koennen-steuerpflichtig-sein-1981629.htmlWahrscheinlich ist die Abgrenzung von "privat" am schwierigsten. Wenn Du da ohnehin nur 3 EUR fuffzich gemint hast interessiert das niemanden. Wenn Du aber ein halbes Rechenzentrum laufen lässt mit richtig Umsatz - wie kann das noch privat sein? Mining lohnt sich doch eh nur noch mit enormen Hardwareeinsatz und möglichst kostenlosem Strom (z.B. auf Island) ... oder? |
|
|
|
Wie genau trage ich eigentlich einen ICO ein? Bei der Teilnahme sende ich ja schon vor der Token Distribution meine BTC oder ETH an die Funding-Adresse. Die Haltefrist beginnt ja aber vermutl. erst mit der Distribution des Tokens bzw. da findet dann ja quasi der eigentlche Kauf statt. Der maßgebende Fiat-Preis von BTC ist dann der Preis, zu dem ich Geld an den ICO gesendet habe? Wie handbabt ihr das?
Nein, mein Steuerberater sagt die "Haltefrist" beginnt schon mit der Bezahlung. Also sobald Du die Bitcoins an die ICO Adresse transferiert hast (steuerlich ist der Zahlungszeitpunkt relevant, nicht der Liefertermin). Wann die Token verteilt werden spielt deswegen keine Rolle. Das war z.B. wichtig bei IOTA - 1,5 Jahre zwischen Investition und Tokenlisting ... konnte man sofort steuerfrei verkaufen ... Zum Eintragen: Ich lege zunächst einen neuen Coin an (Fantasiename), solange es den noch nicht an den Börsen gibt. Und gebe dann meinen Kaufwert in Bitcoin an. Wenn er dann irgednwann in Cointracking aufgenommen ist ändere ich einfach den vorläufigen Fantasienamen in den richtigen um ... und alles stimmt. |
|
|
|
@polister:
Kein Problem.
Freut mich, dass alles wieder passt.
VG,
Dario
Hi Dario, funktioniert leider doch nicht. Ich habe jetzt mal folgendes getestet ob es an den Daten liegen kann - kann aber nicht: 1. Backup eingespielt vom 27.7.2017 (also weit vor jeglichen Problemen) 2. eine Polo-CSV vom 4.8.2017 eingespielt (also auch vor Problemen und die früher problemlos eingespielt werden konnte) Ergebnis: Auch diese Trades werden von CT nicht als bereits bestehend erkannt! Das kann nicht sein. Es MUSS also etwas seitens CT geändert worden sein. Ich meine genausowas hatte ich schonmal vor einem Jahr als ich mich mit CT erstmals beschäftigt habe - das Problem verschwand dann plötzlich nach ein paar Wochen wieder! Um meine Polotrades überhaupt importieren zu können muß ich die jetzt jedes mal im csv editor öffnen und die alten Trades löschen. Das wäre als Dauerlösung sehr nervig |
|
|
|
Hey,
wie gesagt, wenn du mir per PM deinen Usernamen sagen könntest, kann ich mir das schnell ansehen und ggf. anpassen.
Änderungen Seitens CoinTracking gab es nicht.
Bei mir taucht das auch nicht auf.
Also würde mich interessieren wie das passiert ist.
Ja, danke Dario. Wollte den Account aber nur notfalls mitteilen. Was ich bereits erreicht habe: Alle Polo-Trades gelöscht, dann Polo neu importiert, dann probeweise versucht nochmal zu importieren - siehe da: CT erkennt die als bereits importiert. Momentan funktioniert es also wieder. Aber schon schade, daß ich nicht weiß woran es lag. |
|
|
|
Hey, die Polo CSV hat leider gar keine Trade-IDs. Darum ist der CSV Import auch nicht mit dem API Import kompatibel. Um Duplikate bei einer CSV ohne Trade-IDs zu erkennen, prüfen wir die exakten Werte (also Datum, exakte Uhrzeit inkl. Millisekunden, Menge, Coins, Preise, Gebühren, usw.). Sofern alle Werte übereinstimmen, wird der Trade als Duplikat erkannt. Ich habe es aber soeben getestet da ich noch ein paar alte Polo CSVs rumliegen habe und muss sagen, dass sich das Format kein bisschen geändert hat. Also kann das nicht der Grund sein. Andere Ursachen könnten sein: - Deine bisherigen Polo Trades kamen über die API - Du hast einen anderen Account verwendet - Die CSV wurde zuvor mit Excel (etc.) geöffnet und gespeichert wobei Excel einige Zahlen oder Formatierungen geändert hat - Polo stellt die CSV in diesem Moment um und einige User haben bereits eine neue File (sehr unwahrscheinlich) Falls das alles nicht hilft, lass es mich bitte wissen. Irgendetwas muss ja, wie du sagst, anders sein Ist ja merkwürdig. Die von Dir genannten Ursachen treffen auf mich nicht zu (habe nie die Api verwendet, habe nur einen Account und die csv wird direkt in Cointracking upgeloadet). Muß demnach ja irgendwie an meinem Setup liegen. Puh - das wird eine schwierige Suche, da ich nicht wüßte was ich geändert haben soll. Ich importiere die polo-CSV ja fast jeden Tag seit Monaten. Habe als erstes die csv Daten verglichen - sehen absolut identisch aus - als nächstes werde ich mal einen anderen Browser/PC etc. versuchen. Muß das Problem irgendwie eingrenzen ... Trotzdem erstmal Danke! Habe nun probiert: Anderer PC, anderer Browser - hat keine Effekt. Habe versucht ältere CSV Daten von Polo zu importieren (also jene, die ich schon vor Tagen oder Wochen erfolgreich importiert hatte): Cointracking erkennt keinen der alten Trades! Was aber seltsam ist: Ich habe gestern als Zwischenlösung nur die neuen Trades (also die nachdem der Polo-Import nicht mehr korrekt ging) importiert (csv editiert - alte gelöscht). Diese Trades erkennt CT als bereits importiert ... Wenn ich mir das anschaue muß ich derzeit sagen: Am 5. August zwischen 7:49 Uhr und 18:47 Uhr ist der Poloniex-Importer verändert worden Wahrscheinlich werde ich jetzt so vorgehen: Backup erstellen, Polo komplett löschen und dann komplett neu importieren - mal schauen ob es dann geht |
|
|
|
Hey, die Polo CSV hat leider gar keine Trade-IDs. Darum ist der CSV Import auch nicht mit dem API Import kompatibel. Um Duplikate bei einer CSV ohne Trade-IDs zu erkennen, prüfen wir die exakten Werte (also Datum, exakte Uhrzeit inkl. Millisekunden, Menge, Coins, Preise, Gebühren, usw.). Sofern alle Werte übereinstimmen, wird der Trade als Duplikat erkannt. Ich habe es aber soeben getestet da ich noch ein paar alte Polo CSVs rumliegen habe und muss sagen, dass sich das Format kein bisschen geändert hat. Also kann das nicht der Grund sein. Andere Ursachen könnten sein: - Deine bisherigen Polo Trades kamen über die API - Du hast einen anderen Account verwendet - Die CSV wurde zuvor mit Excel (etc.) geöffnet und gespeichert wobei Excel einige Zahlen oder Formatierungen geändert hat - Polo stellt die CSV in diesem Moment um und einige User haben bereits eine neue File (sehr unwahrscheinlich) Falls das alles nicht hilft, lass es mich bitte wissen. Irgendetwas muss ja, wie du sagst, anders sein Ist ja merkwürdig. Die von Dir genannten Ursachen treffen auf mich nicht zu (habe nie die Api verwendet, habe nur einen Account und die csv wird direkt in Cointracking upgeloadet). Muß demnach ja irgendwie an meinem Setup liegen. Puh - das wird eine schwierige Suche, da ich nicht wüßte was ich geändert haben soll. Ich importiere die polo-CSV ja fast jeden Tag seit Monaten. Habe als erstes die csv Daten verglichen - sehen absolut identisch aus - als nächstes werde ich mal einen anderen Browser/PC etc. versuchen. Muß das Problem irgendwie eingrenzen ... Trotzdem erstmal Danke! |
|
|
|
|
Hi Dario,
es geht um die CSV von Polo. Import hat seit Monaten immer problemlos geklappt.
Ich kann bei Bedarf morgen mal die Trade-IDs vergleichen - irgendwas muß ja anders sein ...
|
|
|
|
|
Show Posts
