adds new document type Storno Steuerkorrektur to trade republic pdf importer

[christen90]

adds new document type Storno Steuerkorrektur modifications according pr3807

[stoeggich]

@Nirus2000 @buchen I thought cancellation bookings weren't made?

[Nirus2000]

Hello @christen90 We currently do not support cancelations. You can mark them as NonImportable, but posting them as tax refunds would mess up the ratios etc. All importers follow this principle. Reversals are not supported.

Regards Alex

[christen90]

Hello Alex, If a user imports both (Steuerkorrektur + Storno Steuerkorrektur) it should sum up to 0 right? I think it is beneficial, because the user does not need to locate the original booking and delete it. Instead the user is enabled to just import all documents present at banking site and still have correct results at the end. Also it enables to check for completeness.

Im not aware how the mentioned ratios are calculated but expectation would be that it should work.

BR Christian

[stoeggich]

Hallo @christen90 You can simulate this if you include the date in the calculation, that will cause problems. If you do that without a date it would be the same, but that's wrong.

Mfg Richard

[christen90]

Hello Richard, in my case Trade Republic set the same date for Steuerkorrektur and Storno Steuerkorrektur. So it would sum up to zero on that day.

Which calculations/ratios you are refering exactly? Which values I'll need to watch closely during simulation?

BR Christian

[stoeggich]

Hallo Christian

If it's always the same day, that would even work. But buy and sales cannot be canceled. Whether this special case is not just a source of confusion is the other side

Mfg Richard

[Nirus2000]

The same opinion on this document as described in the commentary (https://github.com/portfolio-performance/portfolio/pull/3847#issuecomment-2000131972).

And even if you do, what's the point if both transactions take place on the same day... then you don't need to post either of them at all.

We cannot determine which transaction is canceled. These are special cases and should be done manually by the user.

[christen90]

Hello Alex, in my case trade republic booked

1. in nov 6,3 €
2. in mar -6,3 €
3. in mar 4 €

Benefit of supporting these transactions is, that if a user stores all documents generated by TR in a folder, it is possible to just import all of them and having the correct balance in account after import. Workaround would be to search for the orignal booking, deleting it and importing the correct one. I think it's no special case. It is the usual process for US-Quellensteuer and should affect all US shares.

BR Christian

[Nirus2000]

Hello @christen90 I think there is an error in the understanding of the transaction types and the PDF document. Reversals, here in this example the tax correction, is not a tax refund, but a change to the tax transaction from November.

In your example. November--> 6,30 March --> -6.30 March --> 4.00

The transaction in March corrects the transaction in November. So the 6.30 becomes the 4.00 in November(!!!) and not a tax refund of 6.30 in March and then a tax charge of 4.00 in March.

Do you understand? If you now calculate the key performance indicators the way you do, you get the wrong key performance indicators.

Calculation time for key performance indicators November to March of 6.30 (-6,30) and from March 4.00 vs. November to March of 4.00 (correcting adjustment)

Regards Alex

[christen90]

Hello Alex, although documents are generated at different months (Nov and Mar), all 3 bookings have the same booking date. So they sum up to 4.00 €.

So it should not affect the KPIs?

BR Christian

[buchen]

@Nirus2000 @christen90

Let me try to summarize my understanding:

• PP has no notion of "fixing" existing transactions (and a "Steuerkorrektur" is such a correction booking)
• At the moment, those correction bookings are ignored (and the user must manually edit the existing transaction)
• The actual tax transactions are imported successfully. In the example, the taxes 6,30 and 4,00 are imported successfully

I understand @christen90 proposal as:

• Import the correction transaction as a tax refund
• Import it with the given (historical) booking date (here: back in November)
• In the historical transactions, there are now 2 transactions which effectively cancel out each other
• The balance of the account is correct
• The user can - if he feels so - delete both transactions (which essentially means it applies the transaction)

Personally, it sounds like reasonable proposal that helps the user while bulk importing PDF documents.

@Nirus2000 you link to another comment, but this comment is about "split" transactions. Split transactions are completely different beast. Do you have concerns on the tax transaction?

[Nirus2000]

Hello @christen90

although documents are generated at different months (Nov and Mar), all 3 bookings have the same booking date. So they sum up to 4.00 €.

Unfortunately, this is not correct. As can be seen in the test, the booking date for the cancellation is as follows: assertThat(transaction.getDateTime(), is(LocalDateTime.parse("2023-11-02T00:00"))); The document was created on 05.03.2024 according to the PDF debug and the value date is 02.11.2023. The amount from 02.11.2023 is canceled - ergo, the transaction can also be deleted manually instead of taking a tax transaction in and out again. Insofar as the tax transaction actually took place on 02.11.2023, as there are no documents to confirm the process. Ultimately, it is an incorrect transaction that should/must be corrected manually. In this respect, we would open a window here for all types of these transactions, especially since we would never know whether it was a coincidence that the transaction was made on the same day or not. I still recommend including the transaction here, but processing it in the NonImportable.

---

you link to another comment, but this comment is about "split" transactions. Split transactions are completely different beast. Do you have concerns on the tax transaction?

@buchen... Here I wanted to make it clear that we should set NonImportable transaction.

[buchen]

The document was created on 05.03.2024 according to the PDF debug and the value date is 02.11.2023. The amount from 02.11.2023 is canceled - ergo, the transaction can also be deleted manually instead of taking a tax transaction in and out again. Insofar as the tax transaction actually took place on 02.11.2023, as there are no documents to confirm the process.

I believe the argument is:

Importing both transactions with the 02.11. creates a convoluted account history (adding 6,30 and removing 6,30 immediately). There are two transactions that add up to nothing. Yes, they could also be deleted manually. But on the other hand they are also not wrong. So why not import the transactions and leave it up to the user to find both and delete them? It would mean the user "should" fix it, but "must" not fix.

especially since we would never know whether it was a coincidence that the transaction was made on the same day or not.

Fair. But I think that is the nature of a correction transaction that it corrects with a value date matching the original date. I believe that is one of the reasons why transactions have two dates. We could also add additional checks here.

[Nirus2000]

Closes