OFX import issue: Was: Is ofx import buildable in master?

[Jonatan Cloutier]

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