SUMMARY I have an account A that is using custom currency and what is different than my base currency (EUR). I also have income category C with this same custom currency. Currency rates have been successfully updated from the online source. STEPS TO REPRODUCE 1. I create new deposit into my account A using income category C. 2. I go to Income and expense reports and select default report of this month. OBSERVED RESULT The income value for category C is zero. EXPECTED RESULT The income value should be converted according to currency rates, or the entered amount if conversion option in report settings is ticked off. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon stable (available in About System) KDE Plasma Version: 5.21 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
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?
What is the status of this bug in master?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.