Bug 283339 - Missing "Pay to" in categories when importing QIF
Summary: Missing "Pay to" in categories when importing QIF
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.5.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-04 19:15 UTC by schlatter@phys.ethz.ch
Modified: 2012-01-21 10:40 UTC (History)
1 user (show)

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


Attachments
Archive containing empyt template .kmy and demonstration .qif file. (5.39 KB, application/x-gzip)
2011-10-04 19:15 UTC, schlatter@phys.ethz.ch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description schlatter@phys.ethz.ch 2011-10-04 19:15:37 UTC
Created attachment 64209 [details]
Archive containing empyt template .kmy and demonstration .qif file.

Version:           4.5.3 (using KDE 4.6.2) 
OS:                Linux

Importing the attached .QIF file results in no "Pay to" information in the category view. However, the same transaction *has* this information in the corresponding account.

Reproducible: Always

Steps to Reproduce:
- Open the attached "Missing PayTo.kmy" (empty template)
- Go to account Asset:Barvermögen:Girokonto
- Enter a new transaction (give it a payee, enter "Lebensmittel" as category, add a memo and an amount
- Import the attached "Missing PayTo.qif" (QIF with a single transaction), date format is %m %d %y, import into Barvermögen:Girokonto



Actual Results:  
- In Barvermögen:Girokonto we now have 2 transactions. Both showing Pay to, Category, Memo, Amount, ...
- In Expense:Lebensmittel we also have 2 transactions. The manually entered one also has all these fields. The one imported from QIF, however, has an empty pay to field

Expected Results:  
All transactions have all fields. In particular, the imported transaction should look exactly the same (apart from the direction of the transfer) in Barvermögen:Girokonto and Expense:Lebensmittel but it does not.

OS: Linux (i686) release 2.6.38-11-generic-pae
Compiler: cc
Comment 1 Thomas Baumgart 2011-10-09 11:18:49 UTC
Note to devs: also applies to SVN trunk
Comment 2 allan 2011-10-09 11:31:27 UTC
(In reply to comment #1)
> Note to devs: also applies to SVN trunk

What happens depends on whether or not the transaction form is being used.
Comment 3 schlatter@phys.ethz.ch 2011-10-30 12:07:42 UTC
I have a humble question: I'm a pretty unexperienced user of this bug tracking system but should the status of the bug not change to "new" or "confirmed" or something similar as soon as one of the developers (such as Thomas Baumgart) has been able to reproduce it?
Comment 4 allan 2011-10-30 12:18:10 UTC
(In reply to comment #3)
> I have a humble question: I'm a pretty unexperienced user of this bug tracking
> system but should the status of the bug not change to "new" or "confirmed" or
> something similar as soon as one of the developers (such as Thomas Baumgart)
> has been able to reproduce it?

You are correct. I think Thomas's and my comments suggest confirmation.  I did look at it initially, but have been otherwise occupied.

I'll look again later and report back.
Comment 5 Thomas Baumgart 2011-10-30 13:42:21 UTC
I verified that the behavior between 4.5.3 and trunk is identical. I did not investigate if this is really a bug or works as designed. Hence I left the state as unconfirmed. Confirmed also means, that we accept it as a bug. Or doesn't it?
Comment 6 allan 2011-10-31 11:18:19 UTC
(In reply to comment #5)
> I verified that the behavior between 4.5.3 and trunk is identical. I did not
> investigate if this is really a bug or works as designed. Hence I left the
> state as unconfirmed. Confirmed also means, that we accept it as a bug. Or
> doesn't it?

Avoiding the question of the meaning of 'Confirmed', I have reclassed it as 'Assigned'.
Comment 7 allan 2011-11-01 21:25:08 UTC
I've had a look at this, and, after meandering around in the code, I found that, if the imported transaction is opened for editing then entered without changing anything, the missing payee gets added to the category, and all appears OK.

So, after initially thinking it could possibly be another issue with widgets not displaying correctly, I found that the second split did not have a payeeId, whereas the manually entered one did.

In the code, in MyMoneyStatementReader::processTransactionEntry(), in 'process splits', I noticed 
if (acc.isAssetLiability()) {
        s2.setPayeeId(s1.payeeId());

Temporarily adding s2.setPayeeId(s1.payeeId()) after this, appears to fix the problem.

A second opinion on this would be appreciated, in case I'm in the wrong place.
Comment 8 allan 2011-11-30 23:48:36 UTC
This problem is still outstanding.

In the absence of contrary opinions, I take it I can go ahead and remove the 'if (acc.isAssetLiability())' statement.
Comment 9 Cristian Oneț 2012-01-21 05:58:45 UTC
Git commit 0552a7a30dcaece836a6ece614cf923b25b1cc5f by Allan Anderson.
Committed on 21/01/2012 at 01:01.
Pushed by allananderson into branch 'master'.

Bug: 283339 Missing "Pay to" in categories when importing QIF.

M  +1    -3    kmymoney/converter/mymoneystatementreader.cpp

http://commits.kde.org/kmymoney/0552a7a30dcaece836a6ece614cf923b25b1cc5f
Comment 10 Cristian Oneț 2012-01-21 05:59:11 UTC
Git commit 2e319aa75812c5d5a07b243c108ffe4870af9910 by Cristian Oneț, on behalf of Allan Anderson.
Committed on 21/01/2012 at 01:01.
Pushed by conet into branch '4.6'.

Bug: 283339 Missing "Pay to" in categories when importing QIF.
(cherry picked from commit 0552a7a30dcaece836a6ece614cf923b25b1cc5f)

M  +1    -3    kmymoney/converter/mymoneystatementreader.cpp

http://commits.kde.org/kmymoney/2e319aa75812c5d5a07b243c108ffe4870af9910
Comment 11 Cristian Oneț 2012-01-21 06:00:03 UTC
I had to manually close the bug since Allan used 'Bug:' instead of 'BUG:' in the commit message.
Comment 12 allan 2012-01-21 10:40:19 UTC
On 21/01/12 06:00, Cristian Onet wrote:
> https://bugs.kde.org/show_bug.cgi?id=283339
>
>
>
>
>
> --- Comment #11 from Cristian Onet<onet cristian gmail com>   2012-01-21 06:00:03 ---
> I had to manually close the bug since Allan used 'Bug:' instead of 'BUG:' in
> the commit message.
>

Thanks, Cristian.  I did have 'BUG:' originally, but something made me 
change it.  I had intended to follow-up after a bit of sleep.

Allan