Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Проблема с формированием tax-statement при перемещении акций с одного аккаунта на другой #13

Open
IlyaKarpelyuk opened this issue Jun 29, 2020 · 2 comments
Labels
long term Not planned to be implemented in the foreseeable future

Comments

@IlyaKarpelyuk
Copy link

IlyaKarpelyuk commented Jun 29, 2020

Добрый день, Дмитрий!

Сегодня обновил Вашу программу до последней версии 1.3.1, продолжаю тестировать её на живом счете и выявил еще одну ошибку.

Я завел второй аккаунт в IB и переместил все акции и наличные средства на него.
Tax-statement на новом аккаунте благополучно формировался до того момента, как я продал один тикер (а куплен он был на старом аккаунте), после продажи программа выводит следующую ошибку (см. скриншот)
А так полагаю, что программа не считала информацию о перемещении данного тикера на новый аккаунт. Факта покупки в файлах нового аккаунта естественно нет, но есть информация о перемещении тикера с аккаунта на аккаунт его стоимости и прибыле/убытке по этому инструменту.

Если есть возможность, исправьте пожалуйста данный баг.
Заранее Спасибо!

P.S. Файлы с активностью по старому и новому аккаунту выслал на почту.

image

@KonishchevDmitry
Copy link
Owner

Добрый день!

Ну, это не ошибка - это вполне ожидаемое поведение, т. к. трансфер позиций я пока не поддерживаю. :)

Спасибо за отчеты! Я в них глянул - на самом деле, там все не так хорошо как хотелось бы:

  1. В Transfers - да, видны все бумаги, но из подробностей там только Market Value, что никак не походит для рассчета налога.
  2. В Mark-to-Market Performance Summary информации - да, чуть больше, но она опять-таки не для рассчета налога.

Чтобы рассчитать налог по FIFO, нужно иметь информацию обо всех сделках с датами, чтобы их можно было пересчитать в рубли.

Единственный вариант это сделать - это добавить возможность объяснить программе что-нибудь вроде "вот тут отчеты одного счета, вот тут - другого - используй только второй счет, но импортируй из первого все позиции, которые были перемещены во второй".

Технически это сделать не сложно - тут никаких проблем, но чисто по объему там довольно много работы, и я, к сожалению, пока не готов инвестировать свое время в решение этой задачи.

Но могу предложить workaround:

Я попробовал взять ваш ActivityUSD_NewAccount.csv и отредактировать период так, чтобы он начинался со следующего дня по отношению к ActivityRUB_OldAccount.csv: Statement,Data,Period,"June 23, 2020 - June 26, 2020".

После этого команда tax-statement успешно отработала.

Но это довольно грубый метод - по факту у вас в результате него получается какая-то довольно непредсказуемая каша из данных, когда программа начинает мержить отчеты (для tax-statement это наверное не важно, но, к примеру, будет важно для analyse).

Поэтому я бы тут рекомендовал просто взять и руками перенести всю значимую информацию из старого отчета в новый (Trades, Deposits & Withdrawals, Dividends и т. п.) и убрать из нового все действия по трансферу (не только бумаг, но и кэша). А дальше уже скачивать отчеты, начиная с даты, следующей за последней датой этого отчета.

Ручной работы тут будет не очень много - и она будет одноразовой, но зато впоследствии сможете работать с программой как и раньше.

@IlyaKarpelyuk
Copy link
Author

IlyaKarpelyuk commented Jul 2, 2020

Добрый день, Дмитрий!

Спасибо, что разобрали мой кейс и отдельное спасибо за советы!
Я использую программу исключительно для подсчета налогов, поэтому воспользуюсь Вашим первым советом, по изменению начальной даты в новых отчетах на "June 23, 2020". Он действительно формирует tax-statements корректно (я уже успел продать и купить нового эмитента, с момента моего сообщения об ошибке и протестировать расчет налога), если сформировать отчет за год и изменить начальную дату на "June 23, 2020".

Но, есть нюанс, программа, как я понял не умеет видеть выходные дни между csv-отчетами. У меня есть csv-отчет по старому аккаунту заканчивающийся 19.06.2020 (это пятница), в IB я могу сформировать новый csv-отчет (по новому аккаунту, но это не важно) только с 22.06.2022 (понедельник) или с 19.06.2020 (пятница), то есть по рабочим дням. И если я их "скармливаю" Вашей программе, то она выдает ошибку (см. скриншот)

Получается, что приходится править csv-отчет в любом случае, редактируя начальную дату на следующий день 20.06.2020 (суббота), даже если он нерабочий.

Другими словами, программа не может мержить отчеты одни из которых заканчиваются в пятницу, а другие начинаются в понедельник.

error

@KonishchevDmitry KonishchevDmitry added the long term Not planned to be implemented in the foreseeable future label Apr 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
long term Not planned to be implemented in the foreseeable future
Projects
None yet
Development

No branches or pull requests

2 participants