Bug 494072 - Foreign Dividends - Exchange Rates Incorrectly Recorded on Duplicates
Summary: Foreign Dividends - Exchange Rates Incorrectly Recorded on Duplicates
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: database (other bugs)
Version First Reported In: 5.1.3
Platform: Appimage Linux
: NOR major
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-03 23:14 UTC by JAH
Modified: 2024-11-16 14:47 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 5.2
Sentry Crash Report:


Attachments
Zip file of test results (81.14 KB, application/zip)
2024-11-06 15:01 UTC, JAH
Details

Note You need to log in before you can comment on or make changes to this bug.
Description JAH 2024-10-03 23:14:39 UTC
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
Comment 1 Thomas Baumgart 2024-10-19 16:30:51 UTC
> Data maintained in XML file but saved and examined in SQLite database

That maybe part of the problem. For your understanding, kmmSplits.valueFormatted and kmmSplits.sharesFormatted only exist in the DB backend for external queries and are not used otherwise by KMyMoney. They are the numeric representation of kmmSplits.value and kmmSplits.shares. However, this does not mean that they should not be correct.

There is a similar bug entry in bug 478386 which took care of the price problem. Does it also fix the sharesFormatted problem? Also, trimming of this information should be based on the settings of the security (fraction). Since you report this on an appimage version, can you try if the development version fixes the problem and report back?
Comment 2 Bug Janitor Service 2024-11-03 03:46:25 UTC
🐛🧹 ⚠️ 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!
Comment 3 JAH 2024-11-06 15:01:45 UTC
Created attachment 175584 [details]
Zip file of test results

compressed with zip
Comment 4 JAH 2024-11-06 15:05:58 UTC
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.
Comment 5 Thomas Baumgart 2024-11-16 14:47:59 UTC
Git commit be93df7881ae747c1b150a11539a326a0f84715f by Thomas Baumgart.
Committed on 16/11/2024 at 14:47.
Pushed by tbaumgart into branch 'master'.

Allow to override foreign total of investment transaction

In case an investment is denominated in one currency and the brokerage
account is denominated in another currency, it was not possible to
adjust the exchange rate for the two in the total amount widget.

This change allows to override the foreign amount of the total amount
widget.
FIXED-IN: 5.2

M  +11   -0    kmymoney/views/investtransactioneditor.cpp
M  +28   -4    kmymoney/widgets/amountedit.cpp
M  +14   -0    kmymoney/widgets/amountedit.h

https://invent.kde.org/office/kmymoney/-/commit/be93df7881ae747c1b150a11539a326a0f84715f