[kmymoney] [Bug 448788] New: Incorrect Currency Conversion in Reports
https://bugs.kde.org/show_bug.cgi?id=448788 Bug ID: 448788 Summary: Incorrect Currency Conversion in Reports Product: kmymoney Version: 5.1.1 Platform: Other OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: reports Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY *** Incorrect Currency Conversion in Reports *** Transaction reports of foreign currency transactions (dividends in my case) do not work as intended. Selecting "Convert Values to base Currency" corrupts values and provides erroneous totals (which should not bethere since the reports contains mixed currencies). NOT selecting "Convert Values to base Currency" DOES convert values into the base currency with correct values & totals (and a nuisance currency code before each value when their all in the base currency. An inability to report accurately invalidates storing the data. STEPS TO REPRODUCE 1. Create a foreign currency dividend 2. Run the report "Transactions by Category" 3. Tick the box "Convert Values to base Currency" OBSERVED RESULT The report of foreign values are wrong and not converted to the base currency EXPECTED RESULT Foreign values should be converted to the base currency SOFTWARE/OS VERSIONS Windows: macOS: kmymoney: 5.1.1-ad14462 Linux/KDE Plasma: opensuse 15.2 (available in About System) KDE Plasma Version: 15.8.6 KDE Frameworks Version: 5.71.0 Qt Version: 5.12.7 ADDITIONAL INFORMATION This is a variation of bug 419519 in Vn 5.0.8 Do NOT tick the "Convert Values to base Currency" box & foreign values WILL be converted to base currency (and totalled correctly). DO tick "Convert Values to base Currency" & random wrong values appear with erroneous totals. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 418479] Historical Investment Transactions causes crash
https://bugs.kde.org/show_bug.cgi?id=418479 --- Comment #14 from JAH --- Sorry I've not been able to post for a while. This bug does indeed appear resolve in kmymoney-5.1-291-linux-64-gcc.AppImage. Thank you. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473322] New: SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322 Bug ID: 473322 Summary: SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps?? Classification: Applications Product: kmymoney Version: 5.1.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: database Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- After problems with base currency conversions in reports, I've been running parameterized, preprepared SQL queries from the BASH command line very successfully but they require parsing the fractional value of "kmmSplits"."sharesFormatted" each time the quantity of shares is required. It seems that formatting commas etc have been removed from the comparable "kmmSplits"."valueFormatted" field so it can be used without parsing but "kmmSplits"."sharesFormatted" bears no relation to the quantity of shares at all (seems to be an integer rounding of the "kmmSplits"."priceFormatted" field). It would make life much easier if "kmmSplits"."sharesFormatted" held the decimal value of "kmmSplits"."shares" (albeit as TEXT). Apologies if "kmmSplits"."sharesFormatted" is being used for some other purpose and this is not a bug at all. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473322] SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322 --- Comment #4 from JAH --- Thanks so much for fixing this issue, it will make writing SQL queries so much easier! BTW am I right in thinking these ."valueFormatted" fields will no longer include comma thousand separators (which previously had to be parsed out for calculations)? Or perhaps that was a setting I had made in error in a previous version installation? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473322] SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322 --- Comment #6 from JAH --- Thanks for your kind reply (and work on kmymoney). I use the sqlite3 command to process preprepared .sql queries that produce .csv reports with calculated ratios etc. I noticed that prices (over 1000) stored in the "kmmPrices"."priceFormatted" field for example, include a comma as the thousand separator, which has to be parsed out for sql calculations. These ."Formatted" would be much easier & neater to use in sql calculations but can't be relied upon "raw" if some include commas etc - hence my add on question. (The alternative of parsing fractions for substrings does require some very very long expressions in some instances.) I had not previously reported it as a bug because I inferred from the manual that this formatting was part of the "xFormatted" fields purpose - to improve the readability of large amounts on screen (but hoped there might be a settings option to turn it off - that I had missed) >From the handbook: "Monetary amounts and share values are shown both in numerator/denominator format, and, with a field name suffixed with 'Formatted', in the form as shown on your screens." Perhaps in light of your last comment I should have reported it earlier as a bug? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473322] SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322
--- Comment #8 from JAH ---
>>"I'll see if it's reasonable to add a checkbox to toggle the use of the
>>commas" -
That would be great if possible because as you say, I don't believe they have
any place in a numerical field. Surely it's more properly the program's job to
the formatting
>>Are you sure there is no function in sql to parse a number from a string that
>>does have thousands separators?
They can indeed be parsed out but it makes for unnecessarily messy code.
>>...process that file to read numbers with the thousands separator?
Yes but I'm not just reading & copying data, I need to perform calculations
which is where the commas interfere.
>>Are you depending on the number of decimal places output, or just depending
>>that there are enough to not lose information?
Enough to be accurate to 2 decimal in the result but that sometimes requires
more places in the price
... have you thought about using the unformatted version? in the form of
"x/y"
That is my current choice but here is an example of the in (sqlite) sql code to
parse one value stored as a fraction:
((CAST(substr ("kmmSplits"."shares", 1, (instr ("kmmSplits"."shares", '/' ) - 1
) ) AS REAL ) ) / (CAST( substr( "kmmSplits"."shares", ( instr(
"kmmSplits"."shares", '/' ) + 1 ), LENGTH( "kmmSplits"."shares" )) AS REAL )))
I sometimes want to multiply several values whilst adding and subtracting
others .
Thanks to your fix, in future it can be replaced with
"kmmSplits"."valueFormatted" but that will have to be
REPLACE("kmmSplits"."valueFormatted",',','')) if it contains commas. Hence my
request.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney] [Bug 473322] SLQLite "kmmSplits"."sharesFormatted" Data Corrupt perhaps??
https://bugs.kde.org/show_bug.cgi?id=473322 --- Comment #10 from JAH --- Well I'm very grateful for your consideration and raising the wish list entry. Sorry I misunderstood your point about the function. As a complete amateur I did try an extensive search for a solution / function but only came up with the explicit parsing which though messy does work. Thanks again John -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494072] New: Foreign Dividends - Exchange Rates Incorrectly Recorded on Duplicates
https://bugs.kde.org/show_bug.cgi?id=494072 Bug ID: 494072 Summary: Foreign Dividends - Exchange Rates Incorrectly Recorded on Duplicates Classification: Applications Product: kmymoney Version: 5.1.3 Platform: Appimage OS: Linux Status: REPORTED Severity: major Priority: NOR Component: database Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- Thank you for an excellent, very capable product and continuing to support it! Much appreciated. SUMMARY When DUPLICATING an existing Foreign Currency Dividend entry the exchange rates applicable to the new (duplicated) transaction are not correctly recorded. STEPS TO REPRODUCE 1. Create a Foreign Dividend with Exchange Rate = X 2. Duplicate that Foreign Dividend but with NEW Exchange Rate = Y OBSERVED RESULT Existing exchange rates in kmmSplits.sharesFormatted are NOT overwritten with the duplicate's NEW exchange rates Existing kmmSplits.price & kmmSplits.priceFormatted values are NEITHER overwritten NOR set to "NULL"" As a result I have a database with many foreign dividend split records with the Correct values in: kmmSplits.value kmmSplits.valueFormatted kmmSplits.shares but INCORRECT values in: kmmSplits.sharesFormatted (which should I believe = kmmSplits.value / kmmSplits.shares) Even when the Foreign Exchange Rate is correctly recorded for fresh new transactions, the value posted to kmmSplits.sharesFormatted is TRIMMED to only 2 decimal places. Originally (some years ago) it seems the exchange rate was posted as a fraction in kmmSplits.price and rounded to 4 decimal places in kmmSplits.priceFormatted - providing an accurate record of foreign transactions which is now absent. I have many records where kmmSplits.price & kmmSplits.priceFormatted have neither been reset to "NULL" nor updated with the new exchange rates after duplication. Those fields remain populated with specious old rates that have been duplicated again and again from the original instance of the dividend transaction. EXPECTED RESULT When creating a fresh NEW FOREIGN CURRENCY DIVIDEND entry I believe: A) The relevant split exchange rates are posted in kmmSplits.sharesFormatted trimmed to 2 decimal places B) "NULL" is posted to kmmSplits.price & kmmSplits.priceFormatted Ideally the practice of recoding the accurate rate in kmmSplits.price & kmmSplits.priceFormatted would be re-introduced. Presumably exactly the same should happen when duplicating a previous transaction as when creating a new one. SOFTWARE/OS VERSIONS Linux/KDE Plasma: opensuse 15.5 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.103.0 Qt Version: 2.15.8 ADDITIONAL INFORMATION Data maintained in XML file but saved and examined in SQLite database -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494073] New: Interest Rate Field for Bank / Brokerage Accounts
https://bugs.kde.org/show_bug.cgi?id=494073 Bug ID: 494073 Summary: Interest Rate Field for Bank / Brokerage Accounts Classification: Applications Product: kmymoney Version: 5.1.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: database Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- It would be great to be able to record the prevailing Interest Rate associated with a cash account - especially when they vary so much these days! -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494073] Interest Rate Field for Bank / Brokerage Accounts
https://bugs.kde.org/show_bug.cgi?id=494073 --- Comment #2 from JAH --- Thanks for the prompt reply! Yes indeed you can record the rate in the comments which is what I currently do but it's very messy for simple reports however such as a list of account details. You can't easily parse the rate from the rest of the notes (technically you could using special characters etc but hardly a newbie workaround) so a report must include all the notes (which may take up half the page with) just to detail the associated rate. Mixing it in with notes also precludes using the rate to calculate expected returns on fixed term accounts for example. I agree that you can't download it easily but it one of those useful facts that doesn't change so often you can't update it manually but it does vary (more often now) over time on savings accounts, credit card accounts and loans so it's useful to be able to quickly see and compare rates across accounts in a list. I thought an extra field on the account record would be a useful feature for many users and no so onerous to implement. You're quite right I should have stuck with the more precise account terms I used in the title rather than shorthand-ing them as "cash accounts". Thanks again for your "interest" ;-) -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494072] Foreign Dividends - Exchange Rates Incorrectly Recorded on Duplicates
https://bugs.kde.org/show_bug.cgi?id=494072 --- Comment #3 from JAH --- Created attachment 175584 --> https://bugs.kde.org/attachment.cgi?id=175584&action=edit Zip file of test results compressed with zip -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 494072] Foreign Dividends - Exchange Rates Incorrectly Recorded on Duplicates
https://bugs.kde.org/show_bug.cgi?id=494072 --- Comment #4 from JAH --- Thank you for taking the time to review this issue. I apologise for the slow reply whilst I tried to recreate a dataset to better explain my experience. Your diagnosis seems quite right, that the problem lies with the “save to SQL” process in Vn 537 & 575 that I have tested. It seems to be partly corrected in the current Developer version master-3639 in that the following fields are now correctly populated EXCEPT in the Cash split: kmmSplits.shares kmmSplits.sharesFormatted kmmSplits.price kmmSplits.priceFormatted To test the process I posted one Foreign Currency dividend to a Base Currency Brokerage account (GBP in my case) and then duplicated the dividend twice at different forex rates. In each split, I recorded the forex rate used the memo field. With a Brokerage account in the Base currency, I would expect the sum of the Category Splits (here all in "Foreign Dividends") to equal the brokerage cash posting i.e. Dividend - Withholding Tax = Brokerage Cash In the developer version I notice that when posting these duplicate dividends kmymoney asks for a forex rate as each split is posted but does not ask for a forex rate (as usual) when committing the whole transaction. Consequently you should see in the attached files that instead kmymoney merely re-uses the “cash split” forex rate from the original transaction. Since the brokerage cash value is converted at a different rate from the splits it no longer equals the sum of those splits (highlighted in the attached spreadsheet). When posting these transactions it has always been difficult not being able to see the final brokerage cash value of the complete transaction (since that is what I’m usually trying to replicate). Instead a user has to leave the investment ledger and check the brokerage ledger to ensure the correct cash value has been posted then go back top the investment ledger for the next transaction. Would be possible to see the complete transaction (including brokerage currency values) in the new spit editor so a user could review / verify rates & values before committing the transaction? I have attached 2 files for each of 3 kmmymoney versions (537, 575 and Master3639) I tested. 1.) The original kmm files through which the transactions were input 2.) An highlighted spreadsheet derived from saving the kmm file as an SQLITE database. I did not test inputting transactions directly into the a SQL database. Please ignore any data in the memo fields apart from the Forex rate used (which are correct) I hope this better explains my issue and thank you again for a great product and continuing support. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 498703] Kmymoney crashes when posting NEW stock purchases if the transaction-date pre-dates the stock's creation date.
https://bugs.kde.org/show_bug.cgi?id=498703 --- Comment #2 from JAH --- Resolved: Yes indeed it does work in 5.1.3! My fault. I only ever think of editing investments through the Securities 'Edit investment' dialogue box not as Accounts in their own right. Thanks very much for pointing out the solution. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 498847] New: Confusing terms Equity, Investment, Security etc
https://bugs.kde.org/show_bug.cgi?id=498847 Bug ID: 498847 Summary: Confusing terms Equity, Investment, Security etc Classification: Applications Product: kmymoney Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- After several years of using this great package I still struggle with the ambiguous use, in documentation and on screen, of the terms Securities, Equities etc (which are generally held to have the interchangeable meanings in common parlance) but are used specifically in kmymoney to differentiate between a specific offering (such as Microsoft Ordinary Shares) and a user's Holding of that offering within a specific account. Indeed the Investment view tabs "Securities" & "Equities" had me confused for a long time but perhaps that's just me. Might it be clearer to consistently use: 1) "Securities" when referring to a specific offering i.e VISA Ord Shares, TREASURY 3 1/2% Gilt 22/01/2045, BondAny etc 2) "Holding" when referring the user's holding of that specific investment - for example "100 VISA Ord shares" 3) "Investment Account" (with their related "Brokerage" Accounts) to mean the financial accounts to which holdings are allocated i.e "Broker1 ISA Account", "Broker1Taxed Account", "Bank1 ISA" ... A user may then have several "Investment" Accounts each with assorted "Holdings" some of which maybe of the same "Security". This would also leave the ambiguous terms Security, Equities, Shares etc to be used interchangeably as all referring to a specific investment offering, as in common parlance. The Investment View would then seem clearer to me if the "Equities" tab was renamed "Holdings" (or some such) and the label "Select Account" detailed as "Select Investment Account". It would then be logical to select an Investment Account from the drop down box to filter just the "Holdings" within that account (as the tab name would imply). No doubt others can think of better terms to use than above but I do think that some consistency of use would help make make usage simpler and clearer. Thanks for a great product. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 498703] New: Kmymoney crashes when posting NEW stock purchases if the transaction-date pre-dates the stock's creation date.
https://bugs.kde.org/show_bug.cgi?id=498703 Bug ID: 498703 Summary: Kmymoney crashes when posting NEW stock purchases if the transaction-date pre-dates the stock's creation date. Classification: Applications Product: kmymoney Version: 5.1.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: vanques...@gmail.com Target Milestone: --- This is a revival of bug 418479 which appeared to be resolved in kmymoney-5.1-291-linux-64-gcc.AppImage but has reappeared for me in 5.1.3_fa1eab719 SUMMARY It is not unusual to post a transaction to Kmymoney some days after the physical transaction occurred (i.e on a prior date). The creation date for NEW securities (kmmAccounts.openingDate) is set automatically to the system date and cannot be changed by the user. When the user subsequently posts the purchase transaction with a date earlier than the stock's creation date, Kmymoney crashes gracelessly. In my case this was for security denominated in a new foreign currency (DKK) but the previous bug applied to base currency securities as well. I have tried creating a price for the security on the transaction date - BEFORE posting the transaction but without success Only manually amending kmmAccounts.openingDate in the database resolves the crash. Perhaps it would be possible to add an amendable "creation date" field the Add New Security dialog so users can amend the date? STEPS TO REPRODUCE 1. Create a new security 2. Post a purchase transaction with a date prior to today's date OBSERVED RESULT User can go as far as posting all the transaction fields required including forex rates but as soon as you commit the transaction, kmymoney crashes. EXPECTED RESULT Either the system should not take exception to transaction date prior to the security creation date or the user should be able to set the security creation date SOFTWARE/OS VERSIONS Linux/KDE Plasma: opensuse 15.5 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are the assignee for the bug.
