[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-de...@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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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-de...@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 watching all bug changes.
[kmymoney] [Bug 433870] New: "To Amount" - Currency conversion function uses wrong input value
https://bugs.kde.org/show_bug.cgi?id=433870 Bug ID: 433870 Summary: "To Amount" - Currency conversion function uses wrong input value Product: kmymoney Version: 5.1.1 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kmymoney-de...@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY Using the "To Amount" currency conversion function for a foreign dividend transaction that has BOTH "Fees" and "Interest" values results in extraordinary exchange rates because the function uses the "Fees" value as the denominator of the currency conversion rather than the "Net Transaction Value" (which is what the user is trying to target with the "To Amount" field). STEPS TO REPRODUCE 1. Create a FOREIGN currency dividend transaction (may apply to others) with values for both "Fees" and "Interest" 2. Tab to the end of the transaction dialogue box - the net value may or may not be calculated 3. Press enter to post the transaction 3. When the Exchange to Base Currency dialogue appears select "To Amount" function OBSERVED RESULT The originating foreign amount as stipulated in the text of the dialogue box is only the "Fee" amount EXPECTED RESULT The originating foreign amount should be the Net Transaction Value which can then be converted to a target value to avoid rounding / reconciliation problems. N.B. Using the alternative "Exchange rate / Price" function works correctly on the same transaction. Using the "To Amount" function WITHOUT a "Fees" value (i.e. no net transaction value calculation) also works correctly. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Leap 15.2 plasma 5 (available in About System) KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.71.0 Qt Version: 5.12.7 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418479] New: Posting historical investment transactions causes crash
https://bugs.kde.org/show_bug.cgi?id=418479 Bug ID: 418479 Summary: Posting historical investment transactions causes crash Product: kmymoney Version: 5.0.5 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: kmymoney-de...@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY I frequently "catch up" with posting my investment transactions at the end of the month and that sometimes involves creating new securities for transactions that happened earlier in the month. This hasn't caused a problem before Now, posting investment transactions dated prior to a Security's/Equity's Opening_Date (kmmAccounts.openingDate) (which does not appear to be user definable) causes kmmoney to crash consistently. STEPS TO REPRODUCE 1. Create an new Investment Security as normal 2. Post an Investment transaction (Buy) with a date prior to today's date (i.e. the security's creation date) OBSERVED RESULT Kmymoney crashes EXPECTED RESULT Transaction should post as normal SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.55.0 and 5.45.0 Qt Version: 5.9.7 and 5.9.4 ADDITIONAL INFORMATION Posting the same transaction using today's date or later is successful. By saving the data in a SQL database and then amending the security's kmmAccounts.openingDate to a time earlier than the transaction date allows the transaction to be posted without problem. kmymoney is otherwise brilliant! -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 335804] Default Save As filename & location Incorrect
https://bugs.kde.org/show_bug.cgi?id=335804 JAH changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from JAH --- Forgot I filed this a long time ago and the conversation below got off topic but the problem was restated and fixed in bug 403608 *** This bug has been marked as a duplicate of bug 403608 *** -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 403608] SaveAs defaults to "wrong" file path
https://bugs.kde.org/show_bug.cgi?id=403608 --- Comment #3 from JAH --- *** Bug 335804 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418479] Posting historical investment transactions causes crash
https://bugs.kde.org/show_bug.cgi?id=418479 --- Comment #1 from JAH --- This bug also creates a Data Consistency fault when saving work: "The investment X has no price set for the Opening Date dd/mm/yy" Normally entering the initial "Buy" transaction would also update the opening price but since you cannot complete the "Buy" transaction there is no price history. Nor is it obvious how to solve the data inconsistency because the security (having no holding) does no appear in the Menu > Tools > Prices dialog. I did discover eventually that it can be given a price by going via Accounts> Select Investment > Select Security > Right Click for "Manual Price Update" but that was anything but intuitive and I think many users would have given up by then. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418479] Kmymoney - Historical Investment Transactions causes crash
https://bugs.kde.org/show_bug.cgi?id=418479 JAH changed: What|Removed |Added Summary|Posting historical |Kmymoney - Historical |investment transactions |Investment Transactions |causes crash|causes crash CC||vanques...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418479] Historical Investment Transactions causes crash
https://bugs.kde.org/show_bug.cgi?id=418479 --- Comment #4 from JAH --- Thanks for the quick reply. I have tried my data using AppImage Kmymoney Vn5.0.8 and problem recurs consistently with: Investment Account A000362 Opened 01/01/2019 Security A000366 (and others A000367 A000368) OpeningDate 04/03/2020 posted to Transaction Date 07/06/2019 I note however that the same posting process (i.e. Transaction Date prior to Security Opening Date) used on another Investment Account has been successful and resulted in the Security Opening Date being reset to the (earlier) Transaction posting date. Also new securities added (using Kmymoney Vn5.0.8) to InvAcct A000362 since do not seem to show the same problem. Since it only affected 4 Securities for me I have worked around the problem by manually changing those Security's Opening Date via SQL but if you think it worth investigating, I have anonymised my data. Thanks again for your consideration. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418823] New: Script based online quotes not working
https://bugs.kde.org/show_bug.cgi?id=418823 Bug ID: 418823 Summary: Script based online quotes not working Product: kmymoney Version: 5.0.8 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: kmymoney-de...@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY Script based price updates with URLs in the form ‘file:/path/to/getquote.sh %1’ (or specifically in my case file:///path) no longer work in KMyMoney-5.0.8-efd5847-x86_64.AppImage although they still work in 5.0.0. STEPS TO REPRODUCE 1. Upgrade to 5.0.8 2. Run Online price update 3. OBSERVED RESULT Unable to launch: /home/admin/Kmymoney/GetPrices.sh XYZ.L Unable to update price for XYZ.L (empty quote data) EXPECTED RESULT Price should update as it does in Vn5.0.0 SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: OpenSuse Leap 15.0 (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.45.0 Qt Version: 5.9.4 ADDITIONAL INFORMATION I have checked permissions, tried moving the script, amended the online quote settings URL but without success although all still woks fine in 5.0.0 -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418823] Script based online quotes not working
https://bugs.kde.org/show_bug.cgi?id=418823 --- Comment #1 from JAH --- I should add that I only use this to import a csv file of prices in the format: Symbol, price, date and that if the CSV importer were able to handle that as an update to kmm.prices it would be an ideal alternative to script based price updates for many users because such price csv files can be downloaded from a Yahoo finance portfolio (even though Yahoo finance no longer provides individual prices enquiries) -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418823] Script based online quotes do not work in the AppImage version
https://bugs.kde.org/show_bug.cgi?id=418823 --- Comment #5 from JAH --- Thank you for addressing this issue. The Appimage version is a great way to access the updated version prior to distro updates and this will return it to full functionality for me. Many thanks. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 421126] New: Securities Dialog "Market" field not populated with existing data on edit
https://bugs.kde.org/show_bug.cgi?id=421126 Bug ID: 421126 Summary: Securities Dialog "Market" field not populated with existing data on edit Product: kmymoney Version: 5.0.5 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kmymoney-de...@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY When editing / updating a Security, the Market field (which I use to store Country & Sector codes) is not populated with any existing data although changes are stored. Only a small drop-down list of possible markets is shown although the field seems able to store any string value. STEPS TO REPRODUCE 1. Open a Security record using the Edit button 2. 3. OBSERVED RESULT The "Market" field is blank EXPECTED RESULT The "Market" field should be populated with any data currently stored iin the field so it can be edited SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Opensuse Leap 15.1 (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.55.0 Qt Version: 5.9.7 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 421126] Securities Dialog "Market" field not populated with existing data on edit
https://bugs.kde.org/show_bug.cgi?id=421126 --- Comment #2 from JAH --- Thanks for the tip re: .kmy files being compressed XML - I didn't know that. Yes I'm sure the field has been populated in my database (even though it has no default value as you point out). To test for yourself: 1. Populate the field with one of the Market codes from the drop down box. This code will persist through successive edits. 2. Populate the field with anything else. It will be saved correctly first time but it will NOT persist through an edit of that field. Since existing market codes DO survive persistent editing, I wondered if this behaviour is by design as a way of validating entries against the drop-down list but that would seem to be unnecessarily proscriptive - precluding the entry of any market codes now or in the future that are not already in the list. Furthermore validation does not explain how ad-hoc entries survive being stored in the first place. It seems that when selecting the TradingMarket field in the Security > Edit dialog, the first entry in the drop-down list is blank and if left unchanged, any existing data is over-written with NULL when the record is saved. I believe more normal behaviour would be for the first item in the drop down list to be populated with any existing data in the record thus ensuring that, without further action, the existing entry/data is preserved. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 421126] Securities Dialog "Market" field not populated with existing data on edit
https://bugs.kde.org/show_bug.cgi?id=421126 --- Comment #5 from JAH --- Thank you for reviewing this issue and providing a fix. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 419519] New: Reports: Base Currency Conversions Incorrect
https://bugs.kde.org/show_bug.cgi?id=419519 Bug ID: 419519 Summary: Reports: Base Currency Conversions Incorrect Product: kmymoney Version: 5.0.8 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: reports Assignee: kmymoney-de...@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY When reporting foreign currency transactions with the flag "Convert to Base Currency" ticked kmymoney calculates the wrong value for base currency STEPS TO REPRODUCE 1. Create a dividend for a security denominated in a foreign currency 2. The transaction is correctly converted to a base currency value in the brokerage account 3. Report the transaction and tick "Convert to base currency" OBSERVED RESULT The reported "base currency" value does not match that in the base currency brokerage account. REMOVE the "Convert to base currency" flag and the report DOES convert the value into the base currency value (& CORRECTLY!) but precedes it with the foreign currency code (expected). It seems to me that with the "Convert to base Currency" flag: UNTICKED: kmymoney converts the values to base currency anyway (but accurately). TICKED : kmymoney does the conversion TWICE over by the same rate (by my calculation) EXPECTED RESULT UNTICKED: kmymoney should NOT convert foreign currency values to base currency at all. TICKED : kmymoney should convert foreign currency values base currency accurately SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE 15.1 (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.550 Qt Version: 5.9.7 ADDITIONAL INFORMATION Also a problem in kmymoney 5.0.5 -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 418479] Historical Investment Transactions causes crash
https://bugs.kde.org/show_bug.cgi?id=418479 --- Comment #8 from JAH --- Created attachment 127384 --> https://bugs.kde.org/attachment.cgi?id=127384&action=edit Anonomised data in support of bug description Apologies for the delay in submitting this data -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 419519] Reports: Base Currency Conversions Incorrect
https://bugs.kde.org/show_bug.cgi?id=419519 JAH changed: What|Removed |Added CC||vanques...@gmail.com --- Comment #2 from JAH --- Created attachment 127387 --> https://bugs.kde.org/attachment.cgi?id=127387&action=edit Anonmised data in support of bug In this anonomysed version of my data the Report 20 exemplifies the error I reported. Under the report sub-section A000150: A000151 the last transaction is denominated in Euros and has the following characteristics: With the "Convert to base currency" flag OFF: DateAccount Memo Action Amount 02/03/2020 A000150: A000151A000208 T004300/S0002 DividendEUR 3,347.60 DateAccount Memo Action BaseCurrency Value 02/03/2020 A000150: A000151A000208 T004300/S0002 Dividend 2,173.06 If you drill through the report to the original transaction account A000113 the Euro Amount should be Eur 5,157 And drill though to the base currency brokerage account A000114 the correct base currency value shows as GBP 3,347.6 Thus When the report is set to show the Foreign Currency value it instead shows Base Currency value (but preceded by the correct Foreign Currency Symbol) When the report is set to show the Base Currency Value it instead shows a completely wrong value (which seems to me to be the original Foreign Currency but "exchanged" twice i.e. compound exchange rate ^2) I hope this clarify the problem I encountered. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 419519] Reports: Base Currency Conversions Incorrect
https://bugs.kde.org/show_bug.cgi?id=419519 JAH changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #3 from JAH --- Forgot to set flag to reported with submission of anonomyzed data. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 403608] New: SaveAs defaults to "wrong" file path
https://bugs.kde.org/show_bug.cgi?id=403608 Bug ID: 403608 Summary: SaveAs defaults to "wrong" file path Product: kmymoney Version: 5.0.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: file Assignee: kmymoney-de...@kde.org Reporter: vanques...@gmail.com Target Milestone: --- SUMMARY: When using "File > SaveAs" the offered path defaults to the last location a file was saved to even if that path has nothing to do with origins of the currently open file. STEPS TO REPRODUCE 1. Open file /home/Jack/MyCash1.kmy 2. Save file 3. Open file /home/Dad/PaCash2.kmy 4. Use File > SaveAs OBSERVED RESULT The SaveAs path defaults to /home/Jack/ EXPECTED RESULT The SaveAs path should default to /home/Dad/ (which is the origin of the currently open file and the standard GUI behaviour). SOFTWARE/OS VERSIONS Linux/KDE Plasma: Opensuse 15.1 with Plasma 5 (available in About System) KDE Plasma Version: 5.12.6 KDE Frameworks Version: 5.45.0 Qt Version: 5.9.4. ADDITIONAL INFORMATION This exceptional behaviour is contrary to standard behaviour of SaveAs in other desktop applications and consequently makes it easy to inadvertently write the file to the wrong location (potentially overwriting identically named files irrevocably). -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 403608] SaveAs defaults to "wrong" file path
https://bugs.kde.org/show_bug.cgi?id=403608 --- Comment #2 from JAH --- Thank you for such a prompt fix to this excellent application. I'm grateful for the time and dedication the team put into maintaining and developing it and have donated via KDE accordingly. -- You are receiving this mail because: You are watching all bug changes.
[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-de...@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 watching all bug changes.
[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-de...@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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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 watching all bug changes.
[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-de...@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 watching all bug changes.
[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-de...@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 watching all bug changes.
