Bug 341562 - When importing a QIF file containing an intinc transaction, the interest income gets imported into the ledger as a fee, and the checking account is debited instead of being credited.
Summary: When importing a QIF file containing an intinc transaction, the interest inco...
Status: REPORTED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: git (master)
Platform: Mint (Ubuntu based) Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-04 23:30 UTC by allan
Modified: 2021-03-10 00:16 UTC (History)
0 users

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description allan 2014-12-04 23:30:40 UTC 
When importing a QIF file containing an intinc transaction, the interest income gets imported into the ledger as a fee, and the checking account is debited instead of being credited.

Reproducible: Always

Steps to Reproduce:
1.Import a QIF file which contains an IntInc transaction.
2.The ledger shows the income as an expense.
3.

Actual Results:  
As above.

Expected Results:  
Income should show as income not a fee/expense.

I'll send a sample file later.
Comment 1 allan 2014-12-05 18:44:51 UTC 
Advice/opinions  needed, please.

This behaviour appears to be the result of this code snippet  ( circa line 795 in mymoneystatementreader.cpp) -
"
if (statementTransactionUnderImport.m_strInterestCategory.isEmpty())
  s1.setAccountId(d->interestId(thisaccount));
else {//  Ensure category sub-accounts are dealt with properly
  s1.setAccountId(d->interestId(statementTransactionUnderImport.m_strInterestCategory));
}"

It seems that, in spite of the actual imported activity type, this code knows better and decides on the basis of the sign of the amount.

I'm not sure that's such a good idea, apart from causing head-scratching, i might wish to import a negative fee, to offset a previous error, or similarly for a dividend.

Any thoughts, please?
Comment 2 allan 2014-12-05 19:18:50 UTC 
Apologies - missed line off.
if (statementTransactionUnderImport.m_strInterestCategory.isEmpty()) 
  s1.setAccountId(d->interestId(thisaccount));
else {//  Ensure category sub-accounts are dealt with properly
  if (statementTransactionUnderImport.m_amount.isPositive())
    s1.setAccountId(d->interestId(statementTransactionUnderImport.m_strInterestCategory));
  else
    s1.setAccountId(d->expenseId(statementTransactionUnderImport.m_strInterestCategory));
}
Comment 3 Jack 2014-12-05 20:57:47 UTC 
I can't really comment on the code or this particular case, but I certainly have had cause to enter negative amounts for both fees and dividends to enter a correcting transaction.  I'd hate to have to use a "wrong" category, just to be able to enter a transaction that is needed for such purpose.
Comment 4 allan 2014-12-05 21:23:41 UTC 
(In reply to Jack from comment #3)
> I can't really comment on the code or this particular case, but I certainly
> have had cause to enter negative amounts for both fees and dividends to
> enter a correcting transaction.  I'd hate to have to use a "wrong" category,
> just to be able to enter a transaction that is needed for such purpose.

I was going to say you can't actually use a "wrong" category, as that gets chosen by the sign of the amount.

However, it has just dawned on me that this 'feature' is invoked only on imports.  So, there is no problem doing manual corrections and having them correctly recorded.

In a way, that reinforces my doubt about imports working the way they do, even if the use is very infrequent.
Comment 5 Justin Zobel 2021-03-10 00:16:24 UTC 
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.