Summary: | Creating new currencies causes false entries in the database | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | mahead |
Component: | reports | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | REOPENED --- | ||
Severity: | grave | ||
Priority: | NOR | ||
Version: | 5.1.1 | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/office/kmymoney/commit/d58f9df16a7e14ef1a3f93fce67dd4460e36f53b | Version Fixed In: | 5.1.2 |
Attachments: |
anonymized data file
Correct report category to what look for The correct report |
Description
mahead
2021-02-21 11:55:38 UTC
Can you create/provide a sample file that shows the problem and attach it to this bug entry? This would help to duplicate/analyze the problem. TIA. Created attachment 136056 [details]
anonymized data file
See screenshots how to open correct report, the displayed amount shouldn't be 0,00000.
Created attachment 136057 [details]
Correct report category to what look for
Created attachment 136058 [details]
The correct report
See screenshots how to open correct report, the displayed amount shouldn't be 0,00000. The problem actually is not the reporting but the creation of the currency which is wrong. It creates the wrong entry causing the reporting problem. Here's the extract from the anon file showing the problem: <CURRENCY type="3" symbol="ETB" id="ETB" name="Ethiopian Birr" scf="100" rounding-method="0" saf="100" pp="4"/> <SECURITY type="4" symbol="ETH" id="ETH" name="ETH" rounding-method="0" trading-market="" saf="100000" trading-currency="" pp="10"/> <CURRENCY type="3" symbol="€" id="EUR" name="Euro" scf="100" rounding-method="0" saf="100" pp="4"/> Git commit d58f9df16a7e14ef1a3f93fce67dd4460e36f53b by Thomas Baumgart. Committed on 27/02/2021 at 17:09. Pushed by tbaumgart into branch '5.1'. Assign correct attributes to currencies Creating new currencies actually created security entries which is wrong. This change presets the necessary attributes so that currencies are created correctly. Editing also updates the attribute so false entries can be corrected by editing the currency and saving the entry. FIXED-IN 5.1.2 M +4 -0 kmymoney/dialogs/kcurrencyeditdlg.cpp https://invent.kde.org/office/kmymoney/commit/d58f9df16a7e14ef1a3f93fce67dd4460e36f53b Git commit 7ee95e43f56a7259490c56c1cf96ca3a825b85ea by Thomas Baumgart. Committed on 27/02/2021 at 17:26. Pushed by tbaumgart into branch 'master'. Assign correct attributes to currencies Creating new currencies actually created security entries which is wrong. This change presets the necessary attributes so that currencies are created correctly. Editing also updates the attribute so false entries can be corrected by editing the currency and saving the entry. (cherry picked from commit d58f9df16a7e14ef1a3f93fce67dd4460e36f53b) M +4 -0 kmymoney/dialogs/kcurrencyeditdlg.cpp https://invent.kde.org/office/kmymoney/commit/7ee95e43f56a7259490c56c1cf96ca3a825b85ea (In reply to Thomas Baumgart from comment #6) > The problem actually is not the reporting but the creation of the currency > which is wrong. It creates the wrong entry causing the reporting problem. Okay, so the real issue is the "CURRENCY" vs. "SECURITY"? I happen to notice it by myself too, but didn't realize it might affect here also. In my own file, can I just correct that, or is there anything else that I should take care of? Yes, you can change SECURITY into a CURRENCY and make it type="3". You can also remove the attributes that are only used for SECURITY entries but they should disappear the next time you save the file anyway. (In reply to Thomas Baumgart from comment #10) > Yes, you can change SECURITY into a CURRENCY and make it type="3". You can > also remove the attributes that are only used for SECURITY entries but they > should disappear the next time you save the file anyway. Okay, I did that. We are halfway there now. :) The report displays the entered amount, but the "convert as base currency" doesn't work as expected. If it's not ticked, I expect the report to display the same values that very used when using the category. This happens and is ok. But when the option is ticked, the amount is just rounded according to base currency precision, but the actual conversion rate haven't been used. The report displays the entered amount, but the "convert as base currency" doesn't work as expected. If it's not ticked, I expect the report to display the same values that very used when using the category. This happens and is ok. But when the option is ticked, the amount is just rounded according to base currency precision, but the actual conversion rate haven't been used. I am unable to duplicate this using the anon file attached to this bug and executing the income/expense report after I have edited the ETH currency and saved it back (to fix the original problem). The only thing I noticed (and that is worth a different bug entry) is that the value is printed with more than 2 digits when the values are converted to the base currency (EUR). Thomas Baumgart kirjoitti 7.3.2021 18:44:
> --- Comment #13 from Thomas Baumgart <tbaumgart@kde.org> ---
> I am unable to duplicate this using the anon file attached to this bug
> and
> executing the income/expense report after I have edited the ETH
> currency and
> saved it back (to fix the original problem). The only thing I noticed
> (and that
> is worth a different bug entry) is that the value is printed with more
> than 2
> digits when the values are converted to the base currency (EUR).
I toyed with this yesterday and noticed that if the category I'm using
for the transfer, is in base currency, everything works as I expect. So
maybe I had understood the report "Convert to base currency" setting
wrongly.
Although, what the setting should do if one creates a transaction with
different currency setting category?
|