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

Export Account Transactions has wrong tax #141

Open
ralfescher opened this issue Nov 10, 2024 · 6 comments
Open

Export Account Transactions has wrong tax #141

ralfescher opened this issue Nov 10, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@ralfescher
Copy link

ralfescher commented Nov 10, 2024

Hi,

I am a beginner in Python programming and managed to get this (great) program running under a virtual Python 3.9 on my new Mac mini.

While exporting the transactions dl_docs, I noticed that the taxes were incorrectly displayed.

Output: 2024-11-01;Interest;187.16;Zinsen;;;;-6,704
The real value is: 187,16€ and 67,04€ tax (instead of 6704€).

Additionally, I have the problem of importing .csv files into Excel on my Mac (German locale)
(comma/period and UTF-8 -> Mac-Roman).
Would it make sense to offer a specific option for this?

Additional question: Does it make sense to get this app running under Python 3.12 as well? (As mentioned, I’m new to Python).

Thanks
Ralf

@ralfescher ralfescher added the bug Something isn't working label Nov 10, 2024
@ralfescher ralfescher changed the title [BUG] Export Account Transactions has wrong tax Export Account Transactions has wrong tax Nov 10, 2024
@pinzutu
Copy link
Contributor

pinzutu commented Nov 10, 2024

Hi, you can change pytr's csv locale using the export_transactions --lang argument. Excel should also be able to parse semicolumn separated csvs.

Furthermore, could you share the (redacted) json entry of the event with the erroneous tax (all_events.json)?

@msdn65
Copy link

msdn65 commented Nov 11, 2024

In account_transactions.csv I also get wrong or malformatted tax:
2024-11-01;INTEREST;146.51;Zinsen;;;;-3,137

snippet from all_events.json:
{
"title": "Transaktion",
"data": [
{
"title": "Angesammelt",
"style": "plain",
"detail": {
"text": "€177.88",
"type": "text"
}
},
{
"title": "Steuern",
"style": "plain",
"detail": {
"text": "€31.37",
"type": "text"
}
},
{
"title": "Gesamt",
"style": "plain",
"detail": {
"text": "€146.51",
"type": "text"
}
}
],
"type": "table"
},

@ralfescher
Copy link
Author

ralfescher commented Nov 12, 2024

I have the same situation: the values in the JSON look correct (as with @msdn65)
Btw. the command pytr export_transactions does not export the interests to the csv file.

@pinzutu
Copy link
Contributor

pinzutu commented Nov 14, 2024

I see and yes, this event is not yet supported. To add support and for validating potential changes, please share the full json event entry with unaltered keys, nesting, and value formatting.

@SegFaulty
Copy link

SegFaulty commented Nov 17, 2024

Hi, you can change pytr's csv locale using the export_transactions --lang argument.

chnaging the language does not change the outcome, only the format ... tax is wrong

transaction-de.csv:2024-11-01;INTEREST;224,34;Zinsen;;;;-8.035
transaction-en.csv:2024-11-01;INTEREST;224.34;Zinsen;;;;-8,035

80.35 would by correct

BUT I digged deeper:

all_events.json: in locale "en"

             {
              "title": "Steuern",
              "style": "plain",
              "detail": {
                "text": "€80.35",
                "type": "text"
              }
            },

is parsed here (I think) in /pytr/event.py in locale "de":

# Iterate over dicts containing tax information and parse each one
            for taxes_dict in taxes_dicts:
                parsed_taxes_val = cls._parse_float_from_detail(taxes_dict, "de")
                if parsed_taxes_val is not None:
                    return parsed_taxes_val

BUT "text": "€80.35", is not in locale "de" its 80.35 so cls._parse_float_from_detail(taxes_dict, "en") will fix it?

derterz pushed a commit to derterz/pytr that referenced this issue Dec 28, 2024
…g#141)

It seems the "Steuer" value can either be represented as "€11.14" or as
"11,14 €" string.

The "€11.14" representation was misinterpreted as 1114.
@derterz
Copy link

derterz commented Dec 28, 2024

I ran into exactly the same problem. After looking into #125 and #126 I wrote a small test for the known string formats. The pull request contains a simple format detection heuristic that works for nicely for the known examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants