Kalkulator podatkowy

[Wojtas]

Witam!

Jak wspominałem, pracuję nad kalkulatorem podatkowym dla raportów Interactive Brokers Acticvity Statement w języku English, w formacie CSV.

Jest już dostępny pod adresem: www.kalkulatorpodatkowy.info.pl

Przesłane raporty muszą swoim zakresem obejmować oczywiście co najmniej cały rok podatkowy, za który dokonywane jest wyliczenie.
Generowane przez kalkulator zestawienia otwierają się poprawnie nie tylko w przeglądarce, ale także i w Microsoft Word'zie.

Inspirowałem się tym co dyskutujemy w wątku: Jak prawidłowo rozliczyć podatek od zysków z giełd

Na razie traktowałbym go w formie testowej.


Kalkulatory innych autorów:
- IBTAX
- USSoft

[Wojtas]

Wprowadziłem drobną korektę dla wyciągów Lynx. Zapomniałem, że one różnią się od IB nagłówkiem, który jest sprawdzany.

[Pixel2]

Kalkulatory innych autorów:
...
- USSoft

Odnośnie USSoft - liczą źle transakcje na opcjach. Traktują je memoriałowo (od razu zaliczają w koszty i przychody w dacie transakcji) a tu ustawa mówi wprost jak to robić. Napisałem do chłopaków tydzień temu wraz z odesłaniem do podstawy prawnej, na razie bez info zwrotnego.
Warto mieć to na uwadze.

[andr3w]

Na wstępie dzięki za udostępnienie kalkulatora. Wrzuciłem swoją listę transakcji i generalnie większość wyników pokrywa się z liczonymi przeze mnie "półautomatycznie" w GSheet.

Dwie rzeczy, które zauważyłem:
1) przy przeliczeniach poszczególnych transakcji dotyczących jednego waloru, Twój kalkulator nie zaokrągla poszczególnych kwot kupna/sprzedaży w PLN do dwóch miejsc przecinku; dopiero finalna suma w PLN dla danego waloru jest zaokrąglana. Ja w swoich obliczeniach zaokrąglałem poszczególne kwoty transakcji kupna/sprzedaży danego waloru przed ich finalnym zsumowaniem. Różnica w końcowym wyniku (jeśli w ogóle występuje) to 1 grosz, ale tak właściwie to się zacząłem zastanawiać które podejście jest "bardziej prawidłowe".
---
2) data/czas w Activity Statement jest generowana w strefie czasowej Stanów Zjednoczonych EST (przynajmniej u mnie), co może czasem powodować problemy z braniem niepoprawnej daty do przeliczeń. Zauważyłem to dla jednej transakcji na giełdzie w Australii - przykładowe dane:
Symbol: LYC
Currency: AUD
Date/Time = 2020-03-04, 19:12:23
W polskiej strefie czasowej ten Date/Time oznacza 2020-03-05, 01:12:23, czyli jako dzień transakcji (z punktu widzenia polskich obliczeń podatkowych) powinien być brany chyba 2020-03-05 (i 2020-03-04 jako dzień kursu AUD/PLN), a w Twoim kalkulatorze jako dzień transakcji jest brany 2020-03-04 (i poprzedzający dzień go dzień jako dzień kursu AUD/PLN).

[Wojtas]

Twój kalkulator nie zaokrągla poszczególnych kwot kupna/sprzedaży w PLN do dwóch miejsc przecinku; dopiero finalna suma w PLN dla danego waloru jest zaokrąglana.

To powinienem wyjaśnić na starcie.

Wszystkie obliczenia są liczone do 9-tego miejsca po przecinku i z taką samą precyzją importowane są też dane z wyciągów IB/Lynx.
A dopiero przy generowaniu finalnego zestawienia (czyli w warstwie prezentacji), przeprowadzana jest operacja zaokrągleń.

Zaokrąglenia co do zasady są do pełnych groszy, w taki sposób, że: kwoty mniejsze niż pół grosza są pomijane. A kwoty pół grosza i więcej zaokrąglane są do pełnych groszy.

Od tej zasady są następujące odstępstwa:
- ilość akcji nie jest zaokrąglana przed prezentacją (tak, mogą być ułamkowe akcje i można takie kupować),
- kursy walut są zaokrąglane do 4-tego miejsca po przecinku (a nie do 2-giego) przed ich prezentacją.

Efekty są takie jak piszesz. W wyliczeniach mogą wychodzić różnice na poziomie groszowym.

Nie jest to jednak błąd, a celowe działanie.
Wydawało mi się, że tak powinno być. Chciałem liczyć dokładnie, ale nie chciałem prezentować dokładnych danych, bo nikt nie chce mieć w zestawieniu takiej prowizji: -6,156655245 PLN, skoro czytelniej jest mieć -6,16 PLN.

data/czas w Activity Statement jest generowana w strefie czasowej Stanów Zjednoczonych EST (przynajmniej u mnie)

No to jest bardzo ważna informacja. Przyznam, ze o tym w ogóle nie pomyślałem. Będę musiał dodać funkcję korygującą czas.
Bo pół biedy jak godzina się nie zgadza, ale jeśli nastąpi przeskok dni, to już będzie inny kurs średni NBP. Tak jak pisałeś.

[Wojtas]

Poprawki:
- poprawiono rozpoznawanie opisów transakcji oraz ich tłumaczenie na polski (dla innych opłat oraz odsetek),
- dodano obsługę obligacji.

Liczone są teraz pozycje dla: Akcje, Akcje (CFD), Dywidendy, Opcje, Obligacje, Forex, Forex (CFD), Odsetki oraz Inne opłaty.

[Wojtas]

Poprawki:
- dodano korektę strefy czasowej z EDT/EST na CEST/CET dla wszystkich transakcji.

[Wojtas]

Ważna uwaga użytkowa:

Żeby prawidłowo wyliczyć podatek z danego roku, nie wystarczy wyciąg tylko za ten rok.
Często wyciąg powinien być o szerszym zakresie.

Jeśli np kupię akcje Apple w 2015 roku i sprzedam je w 2020 roku, to żeby prawidłowo wyliczyć podatek za 2020, należy przesłać wyciąg obejmujący okres co najmniej okres od 2015 do 2020.
Można nawet przesłać wyciąg od 2015 do 2021 roku, bo kalkulator i tak pominie nadmiarowe dane (przyszłe lata).

Kalkulator liczy dochody rok po roku, przy czym przy każdym roku zachowywane są te pozycje z poprzedniego roku, które nie zostały zamknięte.
Transakcja otwarta więc w 2015, będzie się pojawiać w rozliczeniach za następne lata, do momentu aż zostanie zamknięta.

A jeśli transakcja została częściowo zamknięta, np zakup 100 akcji w 2015 i sprzedaż 50 akcji 2016, to w następnych latach będzie widoczna transakcja zakupu 50 akcji (które nie zostały jeszcze sprzedane) i z połową prowizji (która nie została jeszcze rozliczona).

[reuptake]

Dobra uwaga z tymi prowizjami… będę musiał sprawdzić, czy sobie to dobrze liczę. Aczkolwiek to są małe stosunkowo kwoty.

Oczywiście zgadzam się, że nie wystarczy wyciąg tylko za ten rok.

I tu kolejna zagadka: o ile wiem, zgodnie z przepisami, powinniśmy trzymać dowody księgowe 5 lat. Jak to się ma do powyższego? Przychodzi kontrola i nie mamy już wyciągów z 2015 roku…

[reuptake]

A przy okazji: nie dałoby się tego kalkulatora zrobić w wersji off-line? Wrzucanie mojego statementu do internetu łącznie z danymi osobowymi i dokładnymi kwotami nie wydaje mi się dobrym pomysłem.

[Pixel2]

A przy okazji: nie dałoby się tego kalkulatora zrobić w wersji off-line? Wrzucanie mojego statementu do internetu łącznie z danymi osobowymi i dokładnymi kwotami nie wydaje mi się dobrym pomysłem.

dlatego ja zrobiłem sobie w excelu własny :-)
Bo na koniec trzeba wyliczenia przy ewentualnej kontroli obronić i argumentacja "przeliczyłem na kalkulatorze z netu" nie jest zbyt mocna :-(

Wojtas - może podobnie jak w USSoft powinno to bazować na flexqueries na wybranych polach (kolumnach) bez danych osobowych i id konta

[Wojtas]

Poprawki:
- dodałem obsługę nietypowych "wyciągów" Lynx

Bo na koniec trzeba wyliczenia przy ewentualnej kontroli obronić i argumentacja "przeliczyłem na kalkulatorze z netu" nie jest zbyt mocna :-(

Idea jest taka, żeby te zestawienia zachowywać i wykorzystywać jako dowód w kontroli.
Poza tym jak one będą kompletne, to nie ma znaczenia w czym liczyłeś. Możesz nawet powiedzieć, że sam to sobie napisałeś, licząc długopisem na kartce.

Wojtas - może podobnie jak w USSoft powinno to bazować na flexqueries na wybranych polach (kolumnach) bez danych osobowych i id konta

No właśnie mi się ten ich kalkulator z tego powodu cholernie nie podobał, bo przerzucał na użytkownika gros manualnej roboty - w stylu "a wybierz to pole, a wybierz tamto pole, a pamiętaj kolejności o pól, pamiętaj o właściwym rozdzielniku".

Activity Statement ma tą zaletę, że tam nie musisz nic wybierać - tylko zakres dat. Nawet małpa go wygeneruje.
Ja cały czas pracuję, żeby skrypt był idiotoodporny, żeby był prosty i żeby nie wymagał żadnego myślenia. Zrobiłem go głównie dla siebie, z własnych potrzeb i dla własnych rozliczeń, bo mam dużo transakcji spekulacyjnych.
Ale bez sensu żebym tylko ja korzystał, skoro mogą skorzystać wszyscy.


Co do danych osobowych, to te wiersze w ogóle nie są potrzebne. Gdybyś otwarł .csv w zwykłym edytorze tekstu i je usunął przed wysłaniem, to nie ma to żadnego wpływu na działanie. I tak dostaniesz raport.

Mnie są potrzebne tylko wiersze z:
- nazwą brokera (tym gdzie pisze Lynx B.V. albo Interactive Brokers, bo to jest test, że wyciąg jest właściwy,
- nazwą waluty bazowej (Base Currency), bo ona jest ważna przy prowizjach Forex i muszę ją znać,
- i oczywiście wiersze z samymi danymi transakcji, bo inaczej nie mam jak wygenerować raportu.

Reszta jest zbędna i zupełnie omijana.

Wrzucanie mojego statementu do internetu łącznie z danymi osobowymi i dokładnymi kwotami nie wydaje mi się dobrym pomysłem.

Ustalmy sposób usuwania tych danych.

Mogę:
1. Usuwać je od razu.
2. Czyścić cache np raz dziennie.
3. Dać pole wyboru plus usuwać na żądanie.
Może być np formularz z polem na sumę kontrolną, która będzie podawana po generacji raportu, a której późniejsze podanie będzie autoryzowało żądanie usuwania pliku (w sposób zautomatyzowany).

Wierzcie mi lub nie, ale mnie te dane naprawdę nie są potrzebne. No chyba, że macie tam jakieś super wizjonerskie spółki ;)
Jedyne co mi jest potrzebne to dzienniki, w celu wykrywania błędów i poprawiania.
A to i tak tylko w początkowej fazie kalkulatora. Później nie zamierzam go nadzorować. Chcę to wszystko skończyć, zautomatyzować i skupić się na innych sprawach.


PS.
W dalszej części planuję dodać podsumowania wg giełd oraz sumę całkowitą. No i legendę z wyjaśnieniami dot kursów średnich i zaokrągleń (o których pisałem powyżej), żeby był komplet.
Nie dostaję PIT-8C ani nic innego z IB, więc chciałem mieć zamiennik.

[reuptake]

Ja Ci w zupełności wierzę, ale nadal myślę, że wrzucanie takich informacji do netu jest niezbyt dobrym pomysłem. Identyfikator był i tak wyciął (choć wiele osób te go pewnie nie zrobi).

[reuptake]

dlatego ja zrobiłem sobie w excelu własny :-)
Bo na koniec trzeba wyliczenia przy ewentualnej kontroli obronić i argumentacja "przeliczyłem na kalkulatorze z netu" nie jest zbyt mocna :-(

Masz trochę racji, bo potem może być problem z odtworzeniem tych wyliczeń. Natomiast nadal mnie zastanawia jak to jest w praktyce w przypadku kontroli. Czy ja mam obowiązek "udowadniać" (i jak mam to zrobić), że policzyłem poprawnie, czy urząd ma przedstawić swoje wyliczenie ile powinienem podatku zapłacić?

Tak wygląda "output" z mojego skryptu:

Kod: Zaznacz cały

VNQ
...
28/06/2019 Zakup X VNQ po 328.75 PLN = YYYY PLN
31/07/2019 Sprzedaż X VNQ po 344.63 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
30/08/2019 Sprzedaż X VNQ po 364.71 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
01/10/2019 Sprzedaż X VNQ po 370.84 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
31/10/2019 Sprzedaż X VNQ po 361.73 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
02/12/2019 Zakup X VNQ po 361.94 PLN = YYYY PLN
02/01/2020 Zakup X VNQ po 346.32 PLN = YYYY PLN
31/01/2020 Sprzedaż X VNQ po 365.83 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
28/02/2020 Zakup X VNQ po 342.21 PLN = YYYY PLN
02/03/2020 Sprzedaż X VNQ po 348.39 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
10/03/2020 Zakup X VNQ po 319.59 PLN = YYYY PLN
23/03/2020 Sprzedaż X VNQ po 246.49 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
31/03/2020 Sprzedaż X VNQ po 285.92 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało XXXX
09/04/2020 Sprzedaż X VNQ po 329.85 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało 0
-
11/08/2020 Zakup X VNQ po 304.24 PLN = YYYY PLN
10/09/2020 Sprzedaż X VNQ po 305.62 PLN = YYYY PLN Z/S: ZZZZ PLN [LONG] zostało 0
-
19/11/2020 Zakup X VNQ po 317.97 PLN = YYYY PLN
30/11/2020 Zakup X VNQ po 315.99 PLN = YYYY PLN
31/12/2020 Zakup X VNQ po 313.65 PLN = YYYY PLN

XXXX po 317.97 PLN
XXXX po 315.99 PLN
XXXX po 313.65 PLN
-------------------------------------------------
Stan: XXXX szt.
Z/S PLN: ZZZZ
Wartość PLN:  YYYY

[Pixel2]

Co do danych osobowych, to te wiersze w ogóle nie są potrzebne. Gdybyś otwarł .csv w zwykłym edytorze tekstu i je usunął przed wysłaniem, to nie ma to żadnego wpływu na działanie. I tak dostaniesz raport.

Mnie są potrzebne tylko wiersze z:
- nazwą brokera (tym gdzie pisze Lynx B.V. albo Interactive Brokers, bo to jest test, że wyciąg jest właściwy,
- nazwą waluty bazowej (Base Currency), bo ona jest ważna przy prowizjach Forex i muszę ją znać,
- i oczywiście wiersze z samymi danymi transakcji, bo inaczej nie mam jak wygenerować raportu.

Reszta jest zbędna i zupełnie omijana.

Może na ekranie startowym daj krótkie info, że każdy może we własnym zakresie usunąć "zbędne dane".

W samym raporcie warto w podsumowaniu dać opis sposobu obliczeń (bo jak spłonie znów forum, to kto do tego dojdzie), coś w stylu:
Wygenerowane w dniu XXX na podstawie wyciągu od "nazwa brokera"
- zakres pozycji poddanych analizie od dnia AAA do BBB
- przeliczenia walutowe wykonane na podstawie kursu NBP, tabela M, z dnia poprzedniego względem transakcji
- koszty prowizji zaliczane wraz z zaliczeniem kosztu zakupu instrumentu
- koszty obsługi brokerskiej - zaliczane w roku poniesienie
- operacje przeliczeń walutowych realizowane z pełną dokładnością, prezentowane na wydruku do 2 miejsce po przecinku
- ...
Dla instrumentu:
STK - brane tylko pozycje zamknięte w danym okresie sparowane z pozycjami otwierającymi wg metody FIFO
OPT - brane pod uwagę pozycje zamknięte, dla opcjo wystawianych premia zaliczana w przychód w dniu wystawienia
itd..

Masz trochę racji, bo potem może być problem z odtworzeniem tych wyliczeń. Natomiast nadal mnie zastanawia jak to jest w praktyce w przypadku kontroli. Czy ja mam obowiązek "udowadniać" (i jak mam to zrobić), że policzyłem poprawnie, czy urząd ma przedstawić swoje wyliczenie ile powinienem podatku zapłacić?

W ogólności masz przedstawić dowody (w księgowości dowodem może być wszystko, nawet mail i sms) wskazujące na poprawność wyliczenia.
czyli idąc od tylu - skąd wziąłeś kwoty do PIT38?
jeśli z wielu giełd to zestawienie zbiorcze sumowania
potem dla każdej z giełd wyliczenie przychodu i kosztu, odwołanie do wyciągu od brokera (warto mieć w PDF)...
jeśli broker w PL, to warto mieć pit8c
jeśli transakcje inne niż PLN, to przytoczenie kurs wymiany, daty i nazwy tabeli kursów NBP.

Z jednej strony ma znaczenie kompletność, z drugiej rzetelność.
Można pewnie "rzucić kontrolerowi" pliki z wyciągami od brokera - ale to niekoniecznie najlepsza droga.

[Wojtas]

Poprawki:

- Poprawiłem obsługę różnych odmian wyciągów IB oraz Lynx (zwłaszcza tego ostatniego).

Sorry za zamieszanie. Myślałem, że IB/Lynx stosują jednolity format wyciągu, a one mają czasem odmiany, które nie są w 100% zgodne.
Myślę, że teraz kalkulator powinien je już wszystkie poprawnie rozpoznawać i odpowiednio obsługiwać.

Może na ekranie startowym daj krótkie info, że każdy może we własnym zakresie usunąć "zbędne dane".

Napisałem prosty skrypt w Perlu, który anonimizuje wszystkie wyciągi CSV w bieżącym katalogu (pliki CSV niebędące wyciągami IB/Lynx pomija).

Skrypt: Anonimize_CSV.pl

Perl: ActivePerl dla Windows (darmowy)
W innych systemach niż Windows, Perl jest już na pokładzie.

To jest bardzo toporne w użyciu. Wystarczy wrzucić wyciągi IB/Lynx oraz skrypt do tego samego katalogu oraz uruchomić skrypt dwu-klikiem myszy.
Zanonimizuje on wyciągi IB/Lynx, wyświetlając listę plików, które zanonimizował.

Można to sobie z łatwością potwierdzić, otwierając taki plik w edytorze tekstu i wyszukując swoje dane lub nr konta IB/Lynx (nie będzie ich tam).
Tak zanonimizowany plik działa jednak nadal poprawnie z kalkulatorem, bo on z wyciętych danych i tak w ogóle nie korzysta (ignoruje je).

[reuptake]

Widzę, że też w perlu. Stara szkoła, szacun (ja też w perlu, ale głównie dlatego że była biblioteka gotowa do FIFO).

Ja bym jednak pomyślał nad wersją offline. Zwłaszcza, że tu chyba nie potrzeba żadnego fancy interfejsu.

[Pixel2]

Odpaliłem...
trochą się rozczarowałem ;-) (żart)
a na poważnie - szkoda, że nie ma podsumowania gdzieś na dole tak aby tylko przepisać do PITa :-D
Chciałem porównać z excelem np. "wynik na akcjach/ETF", wynik na opcjach - a nie ma czegoś takiego jak suma :-(
Sprawdziłem wyrywkowo wybrane opcje, akcje gdzie ważne było FIFO - w 100% się zgadza!!!

Bez sum pod tabelkami wg kategorii instrumentu trudno to używać (mam wyniki dla każdej akcji na kalkulatorze sumować?) - nadal potrzebny excel...


Wg mnie masz źle rozwiązane odsetki.
Tzn. pierwsza różnica to różnica pomiędzy Activity a raportem cash w FlexQueris - no ale to nie błąd
Za to wg tego co wyczytałem, to odsetki otrzymane wpadają w dochody kapitałowe tożsame z dywidendą (patrz opis do pola 45 w PIT38)
A odsetki zapłacone stanowią koszty (i dodaje je się do kosztów uzyskania w pole PIT38.23).

Art. 30a.
1. Od uzyskanych dochodów (przychodów) pobiera się 19% zryczałtowany podatek dochodowy, z zastrzeżeniem art. 52a:
1) z odsetek od pożyczek, z wyjątkiem gdy udzielanie pożyczek jest przedmiotem działalności gospodarczej;
...

niezależnie od interpretacji powinna być osobno podsuma odsetki zapłacone i odsetki otrzymane.

Aby było super wygodne to przydatne by było podsumowanie wg kategorii przychodów do komórek PITa, dla przykładu:
Dochody stanowiące podstawę opodatkowania dla PIT-38.G.45 (dochody o których mowa w art 30a. ust.1 pkt 1-5 uzyskana poza granicami kraju):
dywidendy:
odsetki:
suma:
zryczałtowany podatek 19% od powyższego (pole pit-38 G 45): .............
suma podatku zapłaconego za granicą: ..................
suma podatku zapłaconego za granicą zlimitowana wg pozycji do 19% (art. 30a ust.9): ..............

itd...

A tak całkiem fajne... nie tak fajne jak własny excel (bo własny) ale działa skutecznie, poprawnie (sprawdź odsetki) i prosto (dodaj sumy).

[Pixel2]

nie mogę już edytować...
nie ma różnicy w przeliczeniu opłat, odsetek itp.
różnica pomiędzy activity a danym z flex queries jest tylko w dividend accruals /accruals changes - ale widzę, że też to pomijasz tak jak ja.

Zmyliłem się na sumie USD w tabelce "USD - pozostałe opłaty" - ja to w excelu mam rozbite na kategorie i niedosumowałem sobie.

Wszystko się zgadza co do grosza (tylko sum na wszystkich akcjach opcjach nie sprawdziłem).

[reuptake]

Jeszcze pytanie, czy dobrze liczy shorty. Kiedyś się na tym przejechałem, bo liczyłem tak samo jak long, a tymczasem – o ile pamiętam – short się rozlicza w momencie pokrycia pozycji, a nie jak long poprzez odjęcie kosztu od przychodu.

[Wojtas]

a na poważnie - szkoda, że nie ma podsumowania gdzieś na dole tak aby tylko przepisać do PITa :-D

Spokojnie. Ja o tym wiem od samego początku, że potrzebne są sumy.
Po prostu nie chciałem zaczynać wszystkiego naraz, bo niektórzy zaczynają wszystko na raz, a potem nic nie działa jak trzeba.
Najpierw chciałem zrobić coś (trzon). Jak widzę, że trzon działa, to później rozszerzam go kwestie zewnętrzne, takie jak sumy zbiorcze.

Będziesz te sumy miał na dniach. To nie są już programistycznie skomplikowane rzeczy. Te skomplikowane już mam za sobą.

niezależnie od interpretacji powinna być osobno podsuma odsetki zapłacone i odsetki otrzymane.

Zgadzam się. Po prostu w tamtej chwili nie miałem do tego głowy, bo to grosiki były (u mnie).

Widzę, że też w perlu. Stara szkoła, szacun (ja też w perlu, ale głównie dlatego że była biblioteka gotowa do FIFO).

Tak, silnik jest Perlu. Nie chciałem o tym pisać, żeby nie zaczynać flame war.
Bardzo lubię ten język, bo robiłem w nim już całkiem skomplikowane rzeczy i obliczenia, które później działały jak trzeba.
Jego bolączki ogarniam, a z mocnych stron korzystam z lubością.

Z bibliotek do FIFO nie korzystam. Język jest na tyle elastyczny, że większość rzeczy zaprogramowuję sam.

Ja bym jednak pomyślał nad wersją offline. Zwłaszcza, że tu chyba nie potrzeba żadnego fancy interfejsu.

Miałem o tym napisać na końcu, ale powiem od razu jaki miałem plan.
Plan był prosty: robię kalkulator, dopracowuję go, a potem udostępniam.

Rezygnuję z zapłaty, ale wklejam jakąś regułkę w stylu:
Jeśli kalkulator ci się przydał, przekaż jakieś wsparcie (1% podatku albo coś) na fundację.
Dlaczego tak ? Bo miałem fajne dzieciństwo dzięki zwierzakom i nie chcę żeby działa im się krzywda.
A fundację znam o tyle, że prowadzi ją znajoma mojej mamy i wiem, że robią dobre rzeczy.

To jest uczciwe w stosunku do Was i do mnie. Ja wkładam pracę, której nie jest znowu tak mało, a Wy pomagacie. Jeśli oczywiście chcecie, bo tego nikt nigdy nie skontroluje.

Udostępnianie wszystkiego (źródeł itp) w szeroką publikę, nie jest z kolei uczciwe w stosunku do mnie. Dlatego sądzę, że rozwiązanie powyższe, będzie uczciwsze.
Ja będę miał przynajmniej satysfakcję, że zrobiłem coś dobrego dla świata (swój mały kamyczek).

PS. A co do danych osobowych, to to naprawdę da się rozwiązać. Dopiszę regułki prawne, RODO, itp na końcu, gdzie będą warunki przetwarzania i usuwania (np po 7 dniach, a na żądanie od razu).
A jeśli mimo to się boisz (do czego masz prawo), to pamiętaj, że po anonimizacji naprawdę niewiele zostaje.
Przecież na akcjach są dziennie milionowe wolumeny. Wiadomo, że ktoś to kupuje i gros tego stanowią osoby prywatne (na SeekingAlpha nie brak milionerów).
Jak sobie wykupisz podgląd notowań poziomu 2, to nawet będziesz wiedział jakie zlecenia tam wchodzą.
Jakie ma jednak znaczenie informacja, że ktoś (nie wiadomo kto), kupił określoną ilość akcji znanej spółki, które później sprzedał ?
Tego się nie da wykorzystać. No chyba, że jako pomysł inwestycyjny, ale przecież tych jest bez liku na Twitterze.


PS2.
Kurde znowu jestem 2 zajęcia Uniwersytetu do tyłu, a Tomek dla próżniaków i osłów nie ma litości.

Jeszcze pytanie, czy dobrze liczy shorty. Kiedyś się na tym przejechałem, bo liczyłem tak samo jak long, a tymczasem – o ile pamiętam – short się rozlicza w momencie pokrycia pozycji, a nie jak long poprzez odjęcie kosztu od przychodu.

Tak, jest to przychód "zawieszony w czasie". Rozliczasz go dopiero jak odkupisz. Pisałem o tym w temacie głównym.

[Pixel2]

reuptake pisze: ↑12 kwie 2021, 23:27
Jeszcze pytanie, czy dobrze liczy shorty. Kiedyś się na tym przejechałem, bo liczyłem tak samo jak long, a tymczasem – o ile pamiętam – short się rozlicza w momencie pokrycia pozycji, a nie jak long poprzez odjęcie kosztu od przychodu.

Tak, jest to przychód "zawieszony w czasie". Rozliczasz go dopiero jak odkupisz. Pisałem o tym w temacie głównym.

Dlatego trzeba robić po wskaźniku Open/Close a nie Buy/Sell. Buy/Sell wyznacza Ci tylko stronę transakcji.
Wszytko jest liczone dobrze.

Co do "podsum".
Ja mam u siebie tabelkę po latach - w tym tez rok bieżący oraz saldo pozycji otwartych. Co jakiś czas "dogrywam" kolejne pozycje i je ręcznie paruję dodając "rok zamknięcia" - stąd np. tegoroczne dywidendy, odsetki nie mają przypisanego roku, bo tego jeszcze nie zrobiłem.
Liczby trochę musiałem popsuć, część zniknęła po zwężeniu kolumn :-) Z tego trafia to do PITa - mam wszystkie niezbędne wyliczenia.

tabelka.png (56.57 KiB) Przejrzano 22486 razy

Przy okazji - opłat stałych i kosztu odsetek nie dzielę na kraje - wszystko ładuje w US.

[Besso]

Rezygnuję z zapłaty, ale wklejam jakąś regułkę w stylu:
Jeśli kalkulator ci się przydał, przekaż jakieś wsparcie (1% podatku albo coś) na fundację.
Dlaczego tak ? Bo miałem fajne dzieciństwo dzięki zwierzakom i nie chcę żeby działa im się krzywda.
A fundację znam o tyle, że prowadzi ją znajoma mojej mamy i wiem, że robią dobre rzeczy.

To jest uczciwe w stosunku do Was i do mnie. Ja wkładam pracę, której nie jest znowu tak mało, a Wy pomagacie. Jeśli oczywiście chcecie, bo tego nikt nigdy nie skontroluje.

To jest super postawa i bardzo cenie takie. Co prawda z kalkulatora nie korzystałem (być może przetestuję później), ale chętnie podziękuję za pracę wrzucając jakiś grosik na fundację.
Jeszcze podziękowania dla Kuby, który też udostępniał swój kalkulator pro bono. Na pewno sporo osób skorzysta, więc dziękuję Wam w imieniu forum!

[arku]

U mnie podczas generowania raportu wyskoczył błąd "nie rozpoznano tickera w wierszu ..." Sprawdziłem i chodzi o akcje "UU." notowane na LSE. Podejrzewam że problemem jest kropka w nazwie tickera. Da się to jakoś obejść, czy wyciąć tę transakcję ze steatmentu i dodać ją sobie ręcznie?
I jeszcze pytanie czy kalkulator przelicza też transakcje na kontraktach futures?

EDIT:
usunąłem kropkę w nazwie tickera i poszło, ale wyskoczył mi kolejny błąd:
"Wiersz nr 1115 określa inną walutę niż poprzednie transakcje dla tickera ALL"
Problemem jest zbieżność tickerów dla spółki Ailleron z GPW i dla Allstate z Nyse. Dokonywałem transakcji dla obu i stąd program odczytał to jako błąd waluty w drugim przypadku.

[Wojtas]

U mnie podczas generowania raportu wyskoczył błąd "nie rozpoznano tickera w wierszu ..." Sprawdziłem i chodzi o akcje "UU." notowane na LSE. Podejrzewam że problemem jest kropka w nazwie tickera.

Tak, chodzi o kropkę.
Przed importowaniem, program dokonuje tzw walidacji (sprawdzania), gdzie sprawdzana jest poprawność struktury pliku oraz poszczególnych pól.
Dzięki temu program się nie wysypuje, tylko raportuje błędy kiedy coś mu nie pasuje. Te błędy (dziennik) to dla mnie informacja, która stanowi podstawę do poprawek.

Poprawione. Dopisałem kropkę do listy dozwolonych znaków w tickerach akcji (oraz CFD na akcje).

I jeszcze pytanie czy kalkulator przelicza też transakcje na kontraktach futures?

Aktualnie nie przelicza, bo nie miałem z nimi styczności. Ale to nie jest wielki problem, żeby to dopisać do kodu, jeśli będę miał jakiś statement je zawierający.

"Wiersz nr 1115 określa inną walutę niż poprzednie transakcje dla tickera ALL"
Problemem jest zbieżność tickerów dla spółki Ailleron z GPW i dla Allstate z Nyse. Dokonywałem transakcji dla obu i stąd program odczytał to jako błąd waluty w drugim przypadku.

Myślałem i tak też założyłem, że tickery akcji są globalnie unikatowe. Dlatego program "myślał", że skoro taki sam ticker ma inną walutę, to coś jest nie halo.
Teraz wiem, że jest inaczej i dodałem parowanie tickera z walutą. ALL w PLN jest więc teraz rozpoznawany jako coś innego niż ALL w USD.

Poprawione.