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

Fix Trade Republic PDF-Importer to switch Save Back from Buy to delivery inbound #3987

Conversation

Nirus2000
Copy link
Member

Fix Trade Republic PDF-Importer to switch Save Back from Buy to delivery inbound

#3874 (comment)

…ery inbound

Fix Trade Republic PDF-Importer to switch Save Back from Buy to delivery inbound

#3874 (comment)
@Nirus2000 Nirus2000 added the pdf label May 3, 2024
@Nirus2000 Nirus2000 merged commit fd421b3 into portfolio-performance:master May 3, 2024
2 checks passed
@Nirus2000 Nirus2000 deleted the Fix-Trade-Republic-PDF-Importer-to-switch-Save-Back-from-Buy-to-delivery-inbound branch May 4, 2024 13:16
@christen90
Copy link
Contributor

Hi Alex,
I think further adaptation is needed.

If we import Saveback as delivery inbound we should skip (or marks as NonImportable - already covered with other document) the saveback line 20-21.

Please find the PDF dump attached.
Kontoauszug09.txt

I would do it myself, but I'm not at home this week and have no access to my eclipse pc. :-)

BR Christian

@Nirus2000
Copy link
Member Author

Great.
So let's undo everything. I could have guessed that there is an actual cash flow with SaveBack and that the bookings are generated. So the "Buy" transaction was correct.

@christen90
Copy link
Contributor

Actually the saveback transaction needs to be imported anyway to get the details. I would prefer the inbound delivery and skipping the compensation payment.
Saveback document is generated on start of month, the correction at the end of month. So the users would be more up to date with using the inbound delivery and no buy transaction.
Does it make a difference at the end? Just one transaction in addition but no different result of the calculations. Right?

@Nirus2000
Copy link
Member Author

Nirus2000 commented May 6, 2024

That's another fundamental discussion. The transactions exist on paper, so they are read in one-to-one, just like in all the other importers.
It is then up to the user to decide whether to accept them or not. For this purpose, we have created the option of not importing individual transactions or converting them into deliveries (manually).

In addition, we do not have to loop exceptions in importers, whether transaction X or Y is imported forever in the source code.

In the comment you wrote that there were no costs on a contra account and now they do exist. That confuses me a little.

I will withdraw the PR and integrate this PDF import in the account statement.

@christen90
Copy link
Contributor

In the comment you wrote that there were no costs on a contra account and now they do exist. That confuses me a little.

Sorry I should have triggered the export before raising the question. The corresponding transactions take place at the same day. It didn't felt like costs.

Probably you are right and your approach is more robust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants