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
