Add parser for parsing of "Potvrzení o zdanitelných příjmech". This can be later used for getting important data as name, birth number, salary, etc. for generation of tax declaration itself.

Also consider, that most people are scanning this document: maybe some kind of OCR will be needed?

Starting from last quarter of 2021 MortanStenley changed the format of account statements to "Quarterly Statement" and the parser just ignores them.

I would love to contribute to this initiative.

I am however not sure, what is right now of priority and open for contribution.

It would be great if the repository contained such list.

Czech portal for taxes is allowing to save tax declaration into zipped xml file & load it back and send it to authorities. Would be great, if we have library which can generate this file and we could automatically generate tax declaration through TaxReporter utility.

Revolut statements from 2021 are not compatible with existing parser. Format of statements probably changed.

The Apache license does not have the year and name of copyright owner filled out.

Overview

Current implementation of parsers mostly doesn't support Sale transactions and this should be improved. Idea is, that if user sell some shares, parser should detect it and include it between Sale transaction for given broker.

This feature has several challenges.

Multi year statements

Typically purchase can be done years before sale and not every broker is having information about purchase price on statement with sale transaction.

This means, that user will need to provide also statements with purchase transactions and parser will need to map those two transactions somehow on each other. This creates problem with list of transactions from old statements - we should give user ability to filter outgoing transactions, for example by allowing him/her to specify, that user wants just transactions from specific year.

FIFO

At least in Czech Republic shares are sold in FIFO mode. It means that for tax authorities doesn't matter which share we sold in reality, they will always consider sold oldest purchased share.

This is creating another set of problems as user doesn't need to sell all shares from 1 transaction, but only portion of them and for proper evaluation we need to know complete history of the broker.

We should also make research on how other countries are solving this to find out if it make sense to have this feature configurable/extendable as StatementParser project (only parsing, TaxReporter project is currently heavily focused on Czech Republic, but wrote in a way it's extendable on other countries) is currently country independent and I'd like to preserve it.

#Exchange rates (TaxReporter extension)
Sale transactions are opening questions about exchange rates as there is multiple strategies which can be used:

• Same yearly exchange rate from current year for purchase and sale price.
• Yearly exchange rate from current year for sale price, but yearly exchange rate from the year of purchase transaction.
• Per day exchange rate for sale price and for purchase price.

Add support for exotic currencies:
https://www.kurzy.cz/kurzy-men/kurzy.asp?A=H&KM=UAH&D1=2.7.2019&D2=2.7.2020&I=1

There were several requests that people would like to provide just their credentials and let the tool to download the statements.

My current thinking is:

1. Create library which allows to download statements for different brokers
2. Create standalone utility which reads configuration file with credentials and just download statements
3. Integrate feature for downloading of statements as optional feature of TaxReporterCLI

Requirements

• User's credentials should be stored securely (cannot be accessible without re-authentication of user or using some master password, computers are being reused by multiple people ...)
• User's credentials must be easily reusable cross multiple computers & operating systems (one year I can use Windows computer, but another year I might use MacOS or Linux).
• Pick solution should allow secure synchronization through some cloud (picked by user).