Le 2023-04-24 à 08 h 24, Thomas Baumgart via KMyMoney-devel a écrit :
On Montag, 24. April 2023 00:38:27 CEST Jack via KMyMoney-devel wrote:
For Jonatan's loan case, it is used as a placeholder in the principal and
interest splits of a scheduled loan repayment transaction. They should
be replaced with the actual values when the scheduled transaction is
entered. Maybe something failed at that point and the value got into
a real transaction unchanged. For the test file scenario one probably
needs to have a KMM file with a loan, a scheduled repayment transaction
which is due and an import file that contains that transaction. Then
importing the file should show the problem. I expect this to happen
somewhere in the match of scheduled transactions in

https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/converter/mymoneystatementreader.cpp#L1361-L1369

which calls ScheduledTransactionMatchFinder::findMatchInMatchCandidatesList

https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/converter/scheduledtransactionmatchfinder.cpp#L28-L44

which then calls KMyMoneyUtils::scheduledTransaction()

https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/kmymoneyutils.cpp#L340-L355

and that should take care of calculating the distribution using 
calculateAutoLoan() at

https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/kmymoneyutils.cpp#L270-L277

using MyMoneyForecast::calculateAutoLoan() at

https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/mymoney/mymoneyforecast.cpp#L1612-L1683


Using the original data and a bit of debugging would be the easiest to find
out what is going on. Not sure if Jonatan is capable of doing that.

@Jonatan: if possible, keep a copy of the KMM file and the imported statement
aside from your real data so that you can always re-run this.

Ok that took a bit of effort being able to (almost) debug c++ again. Here are my finding. Not sure how clear my idea ares thougth.

in https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/converter/mymoneystatementreader.cpp#L1361-L1369

before calling handleMatchingOfScheduledTransaction

matchedSplit has m_value matching the loan periodicPayment

matchedSchedule.m_transaction has 3 split:
    0  "Amortization"    matching the loan periodicPayment
    1  "Amortization"    LLONG_MIN
    2  "Interest"              LLONG_MIN

transactionUnderImport has 3 split
    0  "Amortization"    matching the loan periodicPayment
    1  "Amortization"    matching the principal paid
    2  "Interest"              matching the interest paid

That transactionUnderImport seems to be the one properly calculated within calculateAutoLoan

Then within handleMatchingOfScheduledTransaction, it seems to save schedule which is matchedSchedule with some missing info.

Now where I'm unsure. is it inside handleMatchingOfScheduledTransaction that the wrong data is used, or should matchedSchedule also contain the rigth info.


I could give another shot at debugging it if you need more info. I can also open a bug now that it's confirmed if you want to continue in the bug tracker.

Last thing, I tried reproducing it in a clean file, but I cant make the transaction match thus it's hard for me to provide a way to reproduce it on your end. I could provide the ofx file thought and some info from my .kmy save if it can be usefull.

Thanks for the info you did provide it did get me looking in the rigth area.

Jonatan Cloutier

Reply via email to