Bug 337251 - Can't save until default is touched
Summary: Can't save until default is touched
Status: RESOLVED LATER
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.6.4
Platform: Fedora RPMs Linux
: NOR minor
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-08 22:31 UTC by george
Modified: 2014-08-06 19:34 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
QIF file that enlists the bad edit behavior (222 bytes, text/plain)
2014-07-15 21:30 UTC, george
Details
Import without creating the account first (112.13 KB, image/png)
2014-07-16 05:56 UTC, Cristian Oneț
Details
Import without creating the account first (119.34 KB, image/png)
2014-07-16 05:57 UTC, Cristian Oneț
Details
Import after creating the account and the brokerage account (118.74 KB, image/png)
2014-07-16 05:58 UTC, Cristian Oneț
Details
screen shot (135.73 KB, image/png)
2014-07-16 06:34 UTC, george
Details

Note You need to log in before you can comment on or make changes to this bug.
Description george 2014-07-08 22:31:36 UTC
If I try enter a new stock a window is put up with defaults filled in for "Fraction".  If I enter, in this order, the "Identification" field, and then the "Trading symbol" the "Next" button fails to light until I change "Fraction" (even if the change is to replace a 0 with a 0).

Likewise, after a QIF import, if I try to fix missing "category" errors on stocks by editing the entry, a default is filled in, but the "Enter" button is not "lit" until I modify that default.

Reproducible: Always

Steps to Reproduce:
1. See above.
2.
3.


Expected Results:  
The code should treat its default filling of fields as if the user had filled them and not require modification in order to allow saving the entry.
Comment 1 Cristian Oneț 2014-07-12 11:30:01 UTC
Git commit e92a54ec93fcee846dcd1af35de170e9fbd146bf by Cristian Oneț.
Committed on 12/07/2014 at 11:26.
Pushed by conet into branch 'master'.

Fix investment details completion signalling.

Completion should be checked on the QLineEdit::textChanged(QString)
signal instead of the QLineEdit::selectionChanged() signal.

M  +3    -3    kmymoney/wizards/newinvestmentwizard/kinvestmentdetailswizardpage.cpp

http://commits.kde.org/kmymoney/e92a54ec93fcee846dcd1af35de170e9fbd146bf
Comment 2 Cristian Oneț 2014-07-12 11:30:43 UTC
Git commit 653016a7b69e83f13deef9aa9f5e5c023b389725 by Cristian Oneț.
Committed on 12/07/2014 at 11:26.
Pushed by conet into branch 'frameworks'.

Fix investment details completion signalling.

Completion should be checked on the QLineEdit::textChanged(QString)
signal instead of the QLineEdit::selectionChanged() signal.
(cherry picked from commit e92a54ec93fcee846dcd1af35de170e9fbd146bf)

M  +3    -3    kmymoney/wizards/newinvestmentwizard/kinvestmentdetailswizardpage.cpp

http://commits.kde.org/kmymoney/653016a7b69e83f13deef9aa9f5e5c023b389725
Comment 3 Cristian Oneț 2014-07-12 11:32:41 UTC
The fix is only for the investment editor. I could not reproduce the second report since I didn't manage to setup qif import that will give me missing category errors and when editing have all fields filed in.
Comment 4 george 2014-07-15 21:30:07 UTC
Created attachment 87747 [details]
QIF file that enlists the bad edit behavior

This QIF file will create a new investment account with one entry which will have a cat error.  The edit will fill in the correct answer but will not allow saving until that entry is "touched".
Comment 5 Cristian Oneț 2014-07-16 05:56:00 UTC
Created attachment 87749 [details]
Import without creating the account first

The account is missing that's why the transaction shows up as erroneous.
Comment 6 Cristian Oneț 2014-07-16 05:57:01 UTC
Created attachment 87750 [details]
Import without creating the account first

Editing the transaction does not fill any default value for the account so I don't see why 'Enter' should be enabled until an account is selected.
Comment 7 Cristian Oneț 2014-07-16 05:58:12 UTC
Created attachment 87751 [details]
Import after creating the account and the brokerage account

The transaction looks OK and does not show as erroneous.
Comment 8 Cristian Oneț 2014-07-16 05:59:42 UTC
I still didn't manage to create a situation in which the transaction is edited and should already be ready to be entered without filling in any further information. See the attachments and comments that I've added.
Comment 9 george 2014-07-16 06:34:37 UTC
Created attachment 87752 [details]
screen shot

Here is what I did.  The account was not created, but is this not the way most folks move from one program (Quicken in my case) to KMM?  In that case what happens if you ask to edit the transaction?

Still, when I tested the QIF I attached, I made an error which caused the accounts to be created, and after fixing, it the I got the same result.  In fact, I just created a new QIF for the same account and had the same thing happen. See image.  Just to make sure, I am using Version 4.6.4 here.
Comment 10 george 2014-07-16 06:44:27 UTC
(In reply to Cristian Oneț from comment #5)
> Created attachment 87749 [details]
> Import without creating the account first
> 
> The account is missing that's why the transaction shows up as erroneous.

I am not sure what you mean by "the account is missing".  The import is just as Quicken would write the QIF (or, likely any other accounting program that used single account investment accounts).  Granted adding an L[...] record fixes the problem, but I think that the import code knows what the account should be and should just fill it in.
Comment 11 Cristian Oneț 2014-07-16 07:12:21 UTC
(In reply to george from comment #10)
> (In reply to Cristian Oneț from comment #5)
> > Created attachment 87749 [details]
> > Import without creating the account first
> > 
> > The account is missing that's why the transaction shows up as erroneous.
> 
> I am not sure what you mean by "the account is missing".  The import is just
> as Quicken would write the QIF (or, likely any other accounting program that
> used single account investment accounts).  Granted adding an L[...] record
> fixes the problem, but I think that the import code knows what the account
> should be and should just fill it in.

I mean that the account is missing in the transaction editor (the field is empty). This happens if the investment account is not created with a brokerage account before importing the qif file. The import does not seem to create the brokerage account. But I've seen this on git master.

Just tried 4.6.4 which indeed does create the brokerage and exhibits the behavior described by you. So I'll reopen this to fix both issues:
1. That git master does not create the brokerage account on import
2. That the transaction shows up as erroneous even when it should not, the editing is not an issue since it should not be necessary at all.
Comment 12 Cristian Oneț 2014-07-17 06:21:35 UTC
So the brokerage account is not automatically created because of this commit https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/06493e0c02f7e6467f5b7d98724f0864c289b500 which seems to fix the "creation unneeded brokerage accounts", seems like the fix went too far.
Comment 13 Cristian Oneț 2014-07-17 07:02:12 UTC
The brokerage account is not created in master due to a fix for BUG 213250 (I've added the comment to link the two issues).
Comment 14 allan 2014-07-17 17:36:10 UTC
(In reply to Cristian Oneț from comment #12)
> So the brokerage account is not automatically created because of this commit
> https://projects.kde.org/projects/extragear/office/kmymoney/repository/
> revisions/06493e0c02f7e6467f5b7d98724f0864c289b500 which seems to fix the
> "creation unneeded brokerage accounts", seems like the fix went too far.

Please refer to https://git.reviewboard.kde.org/r/107797/.

Master works the way I indicated - that is a Brokerage account is created during import only if no transfer account name is provided.  That is, there is an 'X' suffix (eg., BuyX) and either no 'L' record or an empty one, ('L[]') or ('L'). 

The code in 4.6.x didn't check if the transaction referenced a transfer account, but automatically created a Brokerage account, and others, even if not wanted.
Comment 15 Cristian Oneț 2014-07-17 18:21:46 UTC
Indeed if the 'Buy' is replaced with a 'BuyX' in the attached Qif file the brokerage account is created as expected and the transaction does not need to be touched. Does this mean that the application works as expected and this can be closed? I there a specification for investments in the QIF format somewhere?
Comment 16 allan 2014-07-17 21:12:22 UTC
On 17/07/14 19:21, Cristian Oneț  wrote:
> https://bugs.kde.org/show_bug.cgi?id=337251
>
> --- Comment #15 from Cristian Oneț <onet.cristian@gmail.com> ---
> Indeed if the 'Buy' is replaced with a 'BuyX' in the attached Qif file the
> brokerage account is created as expected and the transaction does not need to
> be touched. Does this mean that the application works as expected and this can
> be closed?

I think it best to wait a bit for any comment from the poster.

  I there a specification for investments in the QIF format somewhere?
>

Not specifically for investments, just as part of the overall 
description.  I think perhaps 
http://en.wikipedia.org/wiki/Quicken_Interchange_Format is most useful 
as it has a number of hints, links and references.  One of these is useful -
http://web.archive.org/web/20100222214101/http://web.intuit.com/support/quicken/docs/d_qif.html 
.

Allan
Comment 17 george 2014-07-19 00:49:17 UTC
(In reply to allan from comment #16)
> On 17/07/14 19:21, Cristian Oneț  wrote:
> > https://bugs.kde.org/show_bug.cgi?id=337251
> >
> > --- Comment #15 from Cristian Oneț <onet.cristian@gmail.com> ---
> > Indeed if the 'Buy' is replaced with a 'BuyX' in the attached Qif file the
> > brokerage account is created as expected and the transaction does not need to
> > be touched. Does this mean that the application works as expected and this can
> > be closed?
> 
> I think it best to wait a bit for any comment from the poster.
> 
>   I there a specification for investments in the QIF format somewhere?
> >
> 
> Not specifically for investments, just as part of the overall 
> description.  I think perhaps 
> http://en.wikipedia.org/wiki/Quicken_Interchange_Format is most useful 
> as it has a number of hints, links and references.  One of these is useful -
> http://web.archive.org/web/20100222214101/http://web.intuit.com/support/
> quicken/docs/d_qif.html 
> .
> 
> Allan

This seems strange.  BUY would be what Quicken puts out from a combined account (i.e. security/brokerage in one account).  I is my impression that the "X" suffix ishttp://www.respmech.com/mym2qifw/qif_new.htm used if the security is paid for from another (Quicken) account.  In my full QIF dump of 7 or 8 security accounts I only see BUYX in the Prices data.

Here is a reference to BUYX: http://www.respmech.com/mym2qifw/qif_new.htm

That said, the issue I submitted this bug report for was what was happening when I imported a Quicken QIF and found "missing cat" errors on all the security transactions. And then when I tried to fix it, the edit routine produced the Brokerage account as a default, which should have allowed me to just push the "Enter" button, but it was greyed out. 

Even this is a lot of work given that we are "traders" and have a LOT of transactions to process.

Given all this, I have written a script to pre-process the QIF.  Should I be replacing all the BUYs with BUYX??

Given that QIF is (in my opinion) the best way to move to a new accounting program and that KMM does not handle all actions I think it would be nice if the KMM project posted the QIF spec it is implementing.
Comment 18 allan 2014-07-19 10:48:03 UTC
On 19/07/14 01:49, george@wildturkeyranch.net wrote:
> https://bugs.kde.org/show_bug.cgi?id=337251
>
> --- Comment #17 from george@wildturkeyranch.net ---
> (In reply to allan from comment #16)
>> On 17/07/14 19:21, Cristian Oneț  wrote:
>>> https://bugs.kde.org/show_bug.cgi?id=337251
>>>
>>> --- Comment #15 from Cristian Oneț <onet.cristian@gmail.com> ---
>>> Indeed if the 'Buy' is replaced with a 'BuyX' in the attached Qif file the
>>> brokerage account is created as expected and the transaction does not need to
>>> be touched. Does this mean that the application works as expected and this can
>>> be closed?
>>
>> I think it best to wait a bit for any comment from the poster.
>>
>>    I there a specification for investments in the QIF format somewhere?
>>>
>>
>> Not specifically for investments, just as part of the overall
>> description.  I think perhaps
>> http://en.wikipedia.org/wiki/Quicken_Interchange_Format is most useful
>> as it has a number of hints, links and references.  One of these is useful -
>> http://web.archive.org/web/20100222214101/http://web.intuit.com/support/
>> quicken/docs/d_qif.html
>> .
>>
>> Allan
>
> This seems strange.  BUY would be what Quicken puts out from a combined account
> (i.e. security/brokerage in one account).  I is my impression that the "X"
> suffix ishttp://www.respmech.com/mym2qifw/qif_new.htm used if the security is
> paid for from another (Quicken) account.  In my full QIF dump of 7 or 8
> security accounts I only see BUYX in the Prices data.
>

I have several Quicken files which contain BuyX lines, but generally I 
used defined transfer accounts

> Here is a reference to BUYX: http://www.respmech.com/mym2qifw/qif_new.htm
>

This does not exist.

> That said, the issue I submitted this bug report for was what was happening
> when I imported a Quicken QIF and found "missing cat" errors on all the
> security transactions. And then when I tried to fix it, the edit routine
> produced the Brokerage account as a default, which should have allowed me to
> just push the "Enter" button, but it was greyed out.
>
> Even this is a lot of work given that we are "traders" and have a LOT of
> transactions to process.
>
> Given all this, I have written a script to pre-process the QIF.  Should I be
> replacing all the BUYs with BUYX??
>
> Given that QIF is (in my opinion) the best way to move to a new accounting
> program and that KMM does not handle all actions I think it would be nice if
> the KMM project posted the QIF spec it is implementing.
>

KMM's QIF processing started life some years before I came on the scene, 
and I have no KMM spec, but where necessary I've tried to follow Quicken 
documentation, augmented where that is too loose.

I think the point in question refers particularly to transfers.  In 
general, these are defined by 'L' lines defining the account to use.  If 
there is no 'L' line, or it is empty, then BuyX is taken as indicating a 
transfer and an existing brokerage account is used, or one is created. 
If there is neither an 'L' line nor an 'X' activity suffix, KMM does not 
know which account to use so leaves the account field empty.  The 
imported transaction is flagged as missing a category assignment.  Then, 
all that is necessary is for the user to select the appropriate account. 
  Here, I don't  see "...the edit routine
> produced the Brokerage account as a default, which should have allowed me to
> just push the "Enter" button, but it was greyed out."  I'm using the development branch.  The enter button gets enabled as soon as an account is selected.

Allan
Comment 19 Cristian Oneț 2014-07-28 14:26:35 UTC
Should this bug be closed with the conclusion that BuyX should be used instead of Buy?

As I said I see no way for the edit disabled bug to appear when the transaction is complete (all data is filled in).
Comment 20 george 2014-07-28 16:43:23 UTC
(In reply to Cristian Oneț from comment #19)
> Should this bug be closed with the conclusion that BuyX should be used
> instead of Buy?
> 
> As I said I see no way for the edit disabled bug to appear when the
> transaction is complete (all data is filled in).

In my humble opinion the Buy vs BuyX issue is more a question of what sort of QIF files are being processed.  I.e. most folks have to use what Quicken spits out, which, in my experience is not BuyX.  Likewise, my Quicken (version 2011) does not supply "L" records.
Comment 21 allan 2014-07-28 21:13:18 UTC
On 28/07/14 17:43, george@wildturkeyranch.net wrote:
> Quicken (version 2011)
> does not supply "L" records.

I want to be clear about this point.  Are you saying that it doesn't 
*ever* produce "L" records, or that is doesn't the way you use it?  For 
instance is there any difference between how it exports a transaction 
that has a category, or how it exports a transaction that does a 
transfer to/from another, named account, or how it handles a transaction 
from an investment account having a brokerage account?

QIF is a very loose 'standard', but Quicken itself has documented the 
use of "L" records, so it would be surprising if it has just dropped 
them altogether.  If KMM tries to cope with such a change, then the full 
picture will be needed.

Allan
Comment 22 george 2014-07-29 15:38:35 UTC
(In reply to allan from comment #21)
> On 28/07/14 17:43, george@wildturkeyranch.net wrote:
> > Quicken (version 2011)
> > does not supply "L" records.
> 
> I want to be clear about this point.  Are you saying that it doesn't 
> *ever* produce "L" records, or that is doesn't the way you use it?  For 
> instance is there any difference between how it exports a transaction 
> that has a category, or how it exports a transaction that does a 
> transfer to/from another, named account, or how it handles a transaction 
> from an investment account having a brokerage account?
> 
> QIF is a very loose 'standard', but Quicken itself has documented the 
> use of "L" records, so it would be surprising if it has just dropped 
> them altogether.  If KMM tries to cope with such a change, then the full 
> picture will be needed.
> 
> Allan

I am only talking about the unified investment account transactions where you will find 'L' records for transfers but not for the investment transactions.

By the way, my filter supplies these and also separates investment accounts into two accounts to match KMM.  Only problem I see is the DIV transactions end up with the 'L' record taken as both a transfer and a cat.  Not sure what is happening here. 

-- 
George
Comment 23 allan 2014-07-29 16:45:18 UTC
On 29/07/14 16:38, george@wildturkeyranch.net wrote:
> https://bugs.kde.org/show_bug.cgi?id=337251
>
> --- Comment #22 from george@wildturkeyranch.net ---
> (In reply to allan from comment #21)
>> On 28/07/14 17:43, george@wildturkeyranch.net wrote:
>>> Quicken (version 2011)
>>> does not supply "L" records.
>>
>> I want to be clear about this point.  Are you saying that it doesn't
>> *ever* produce "L" records, or that is doesn't the way you use it?  For
>> instance is there any difference between how it exports a transaction
>> that has a category, or how it exports a transaction that does a
>> transfer to/from another, named account, or how it handles a transaction
>> from an investment account having a brokerage account?
>>
>> QIF is a very loose 'standard', but Quicken itself has documented the
>> use of "L" records, so it would be surprising if it has just dropped
>> them altogether.  If KMM tries to cope with such a change, then the full
>> picture will be needed.
>>
>> Allan
>
> I am only talking about the unified investment account transactions where you
> will find 'L' records for transfers but not for the investment transactions.
>
> By the way, my filter supplies these and also separates investment accounts
> into two accounts to match KMM.  Only problem I see is the DIV transactions end
> up with the 'L' record taken as both a transfer and a cat.  Not sure what is
> happening here.
>

What has been the 'standard', up to now, is that in 'L' records, if the 
'L' is followed with a name in brackets [], then the name is an account, 
whereas 'L' followed by a name with no brackets, then that is a category.

If your original Quicken file follows that, but gives a problem, then 
I'd need to look at that with your file.

So far as the 'X' issue is concerned, I *could* make a change to cope 
with that, but I'm fearful that earlier files from other users would 
then give trouble.

Allan
Comment 24 george 2014-07-30 21:53:06 UTC
(In reply to allan from comment #23)
> On 29/07/14 16:38, george@wildturkeyranch.net wrote:
> > https://bugs.kde.org/show_bug.cgi?id=337251
> >
> > --- Comment #22 from george@wildturkeyranch.net ---
> > (In reply to allan from comment #21)
> >> On 28/07/14 17:43, george@wildturkeyranch.net wrote:
> >>> Quicken (version 2011)
> >>> does not supply "L" records.
> >>
> >> I want to be clear about this point.  Are you saying that it doesn't
> >> *ever* produce "L" records, or that is doesn't the way you use it?  For
> >> instance is there any difference between how it exports a transaction
> >> that has a category, or how it exports a transaction that does a
> >> transfer to/from another, named account, or how it handles a transaction
> >> from an investment account having a brokerage account?
> >>
> >> QIF is a very loose 'standard', but Quicken itself has documented the
> >> use of "L" records, so it would be surprising if it has just dropped
> >> them altogether.  If KMM tries to cope with such a change, then the full
> >> picture will be needed.
> >>
> >> Allan
> >
> > I am only talking about the unified investment account transactions where you
> > will find 'L' records for transfers but not for the investment transactions.
> >
> > By the way, my filter supplies these and also separates investment accounts
> > into two accounts to match KMM.  Only problem I see is the DIV transactions end
> > up with the 'L' record taken as both a transfer and a cat.  Not sure what is
> > happening here.
> >
> 
> What has been the 'standard', up to now, is that in 'L' records, if the 
> 'L' is followed with a name in brackets [], then the name is an account, 
> whereas 'L' followed by a name with no brackets, then that is a category.
> 
> If your original Quicken file follows that, but gives a problem, then 
> I'd need to look at that with your file.
> 
> So far as the 'X' issue is concerned, I *could* make a change to cope 
> with that, but I'm fearful that earlier files from other users would 
> then give trouble.
> 
> Allan

The 'L' record in non-investment accounts seems fine.  I don't see 'L' records in investment accounts except in transfer entries, e.g.:

D4/28' 6
NDiv
YFDRXX FIDELITY CASH RESERVES
CR
U180.05
T180.05
MDIVIDEND RECEIVED
^
If I add (in my 'filter') something like:

L[FIDELITY (Brokerage)]

The entry shows up in the KMM FIDELITY (Brokerage) account as I think it should, however in the KMM FIDELITY account in the 'Edit' window it shows FIDELITY (Brokerage) as the entry in both the Account and the Interest field.

Should I also add an 'L' record such as:
LDiv
?

Is it OK to have two 'L' records?

-- 
George
Comment 25 allan 2014-07-30 23:37:52 UTC
On 30/07/14 22:53, george@wildturkeyranch.net wrote:
> https://bugs.kde.org/show_bug.cgi?id=337251
>
> --- Comment #24 from george@wildturkeyranch.net ---
> (In reply to allan from comment #23)
>> On 29/07/14 16:38, george@wildturkeyranch.net wrote:
>>> https://bugs.kde.org/show_bug.cgi?id=337251
>>>
>>> --- Comment #22 from george@wildturkeyranch.net ---
>>> (In reply to allan from comment #21)
>>>> On 28/07/14 17:43, george@wildturkeyranch.net wrote:
>>>>> Quicken (version 2011)
>>>>> does not supply "L" records.
>>>>
>>>> I want to be clear about this point.  Are you saying that it doesn't
>>>> *ever* produce "L" records, or that is doesn't the way you use it?  For
>>>> instance is there any difference between how it exports a transaction
>>>> that has a category, or how it exports a transaction that does a
>>>> transfer to/from another, named account, or how it handles a transaction
>>>> from an investment account having a brokerage account?
>>>>
>>>> QIF is a very loose 'standard', but Quicken itself has documented the
>>>> use of "L" records, so it would be surprising if it has just dropped
>>>> them altogether.  If KMM tries to cope with such a change, then the full
>>>> picture will be needed.
>>>>
>>>> Allan
>>>
>>> I am only talking about the unified investment account transactions where you
>>> will find 'L' records for transfers but not for the investment transactions.
>>>
>>> By the way, my filter supplies these and also separates investment accounts
>>> into two accounts to match KMM.  Only problem I see is the DIV transactions end
>>> up with the 'L' record taken as both a transfer and a cat.  Not sure what is
>>> happening here.
>>>
>>
>> What has been the 'standard', up to now, is that in 'L' records, if the
>> 'L' is followed with a name in brackets [], then the name is an account,
>> whereas 'L' followed by a name with no brackets, then that is a category.
>>
>> If your original Quicken file follows that, but gives a problem, then
>> I'd need to look at that with your file.
>>
>> So far as the 'X' issue is concerned, I *could* make a change to cope
>> with that, but I'm fearful that earlier files from other users would
>> then give trouble.
>>
>> Allan

Hi
Comments interspersed below.

> The 'L' record in non-investment accounts seems fine.  I don't see 'L' records
> in investment accounts except in transfer entries, e.g.:
>
> D4/28' 6
> NDiv
> YFDRXX FIDELITY CASH RESERVES
> CR
> U180.05
> T180.05
> MDIVIDEND RECEIVED
> ^
> If I add (in my 'filter') something like:
>
> L[]
>
> The entry shows up in the KMM FIDELITY (Brokerage) account as I think it
> should, however in the KMM FIDELITY account in the 'Edit' window it shows
> FIDELITY (Brokerage) as the entry in both the Account and the Interest field.
>
> Should I also add an 'L' record such as:
> LDiv
> ?

If I create a QIF file with your data exactly as you show, it doesn't 
import as an investment, but as a checking transaction.

If I precede it with "!Type:Invst", then it imports.  The activity shows 
as Dividend, as does the category, and the transfer account as FIDELITY 
(Brokerage).  There is a split showing the Dividend category and amount. 
  In FIDELITY (Brokerage), initially, the Details first line shows the 
security name, suffixed (Dividend), the second line shows Investment 
transaction, and the Memo shows DIVIDEND RECEIVED.  If I now double 
click it, and accept the warning, Split transaction now shows, with two 
lines - investAccount:FDRXX  FIDELITY CASH RESERVES, with amount zero, 
and the second line shows Dividend and the amount, both with the memo.

So, that seems to show as I would expect, and without any 'L' record. 
That is because if no account is specified, the brokerage account is 
used automatically, being created if it doesn't exist.

It doesn't seem to be as you say, unless you do also have the 
"!Type:Invst" line but didn't mention it.

I'm using the development version, and I know some changes have been 
made in the last few months, which may not all be in 4.6.4.

> Is it OK to have two 'L' records?
>

I would say that that would result in unspecified results!

Allan
Comment 26 george 2014-08-05 23:26:05 UTC
(In reply to allan from comment #25)
> On 30/07/14 22:53, george@wildturkeyranch.net wrote:
> > https://bugs.kde.org/show_bug.cgi?id=337251
> >
> > --- Comment #24 from george@wildturkeyranch.net ---
> > (In reply to allan from comment #23)
> >> On 29/07/14 16:38, george@wildturkeyranch.net wrote:
> >>> https://bugs.kde.org/show_bug.cgi?id=337251
> >>>
> >>> --- Comment #22 from george@wildturkeyranch.net ---
> >>> (In reply to allan from comment #21)
> >>>> On 28/07/14 17:43, george@wildturkeyranch.net wrote:
> >>>>> Quicken (version 2011)
> >>>>> does not supply "L" records.
> >>>>
> >>>> I want to be clear about this point.  Are you saying that it doesn't
> >>>> *ever* produce "L" records, or that is doesn't the way you use it?  For
> >>>> instance is there any difference between how it exports a transaction
> >>>> that has a category, or how it exports a transaction that does a
> >>>> transfer to/from another, named account, or how it handles a transaction
> >>>> from an investment account having a brokerage account?
> >>>>
> >>>> QIF is a very loose 'standard', but Quicken itself has documented the
> >>>> use of "L" records, so it would be surprising if it has just dropped
> >>>> them altogether.  If KMM tries to cope with such a change, then the full
> >>>> picture will be needed.
> >>>>
> >>>> Allan
> >>>
> >>> I am only talking about the unified investment account transactions where you
> >>> will find 'L' records for transfers but not for the investment transactions.
> >>>
> >>> By the way, my filter supplies these and also separates investment accounts
> >>> into two accounts to match KMM.  Only problem I see is the DIV transactions end
> >>> up with the 'L' record taken as both a transfer and a cat.  Not sure what is
> >>> happening here.
> >>>
> >>
> >> What has been the 'standard', up to now, is that in 'L' records, if the
> >> 'L' is followed with a name in brackets [], then the name is an account,
> >> whereas 'L' followed by a name with no brackets, then that is a category.
> >>
> >> If your original Quicken file follows that, but gives a problem, then
> >> I'd need to look at that with your file.
> >>
> >> So far as the 'X' issue is concerned, I *could* make a change to cope
> >> with that, but I'm fearful that earlier files from other users would
> >> then give trouble.
> >>
> >> Allan
> 
> Hi
> Comments interspersed below.
> 
> > The 'L' record in non-investment accounts seems fine.  I don't see 'L' records
> > in investment accounts except in transfer entries, e.g.:
> >
> > D4/28' 6
> > NDiv
> > YFDRXX FIDELITY CASH RESERVES
> > CR
> > U180.05
> > T180.05
> > MDIVIDEND RECEIVED
> > ^
> > If I add (in my 'filter') something like:
> >
> > L[]
> >
> > The entry shows up in the KMM FIDELITY (Brokerage) account as I think it
> > should, however in the KMM FIDELITY account in the 'Edit' window it shows
> > FIDELITY (Brokerage) as the entry in both the Account and the Interest field.
> >
> > Should I also add an 'L' record such as:
> > LDiv
> > ?
> 
> If I create a QIF file with your data exactly as you show, it doesn't 
> import as an investment, but as a checking transaction.
> 
> If I precede it with "!Type:Invst", then it imports.  The activity shows 
> as Dividend, as does the category, and the transfer account as FIDELITY 
> (Brokerage).  There is a split showing the Dividend category and amount. 
>   In FIDELITY (Brokerage), initially, the Details first line shows the 
> security name, suffixed (Dividend), the second line shows Investment 
> transaction, and the Memo shows DIVIDEND RECEIVED.  If I now double 
> click it, and accept the warning, Split transaction now shows, with two 
> lines - investAccount:FDRXX  FIDELITY CASH RESERVES, with amount zero, 
> and the second line shows Dividend and the amount, both with the memo.
> 
> So, that seems to show as I would expect, and without any 'L' record. 
> That is because if no account is specified, the brokerage account is 
> used automatically, being created if it doesn't exist.
> 
> It doesn't seem to be as you say, unless you do also have the 
> "!Type:Invst" line but didn't mention it.
> 
> I'm using the development version, and I know some changes have been 
> made in the last few months, which may not all be in 4.6.4.
> 
> > Is it OK to have two 'L' records?
> >
> 
> I would say that that would result in unspecified results!
> 
> Allan

Yes, of course this is an investment transaction and the "!Type:Invst" is there.

Now, to expand on this issue of the "Bad Editor"...
I have moved my accounts to KMM and I just got brave enough to down load from Fidelity.  KMM seems to have completely forgotten that it is dealing with linked accounts.  Every transaction has the ! diamond and a missing account field. 

AND again, when I try to edit the entry, the editor supplies the missing account field with the "Enter" button grayed out.  

And then, when I fudge the editor to enter the transaction, the result in the (Brokerage) account shows a category of "Investment transaction" which I might accept for buy and sell actions but for Div transactions, I think a different category should be used.  

I suggest that the account information be expanded to include:
Default linked (Brokerage) account name
Default Category for Div translations
Default Category for Int transactions 
and that these be used for downloaded (imported) transactions.

I am using KMM 4.6.6 now.

-- 
George
Comment 27 allan 2014-08-06 10:29:57 UTC
This problem has been fixed in the development version.  Work is proceeding on the next stable release, which will be available in the next month or so.

If you are able to build from source, then that will resolve your problem.
Comment 28 george 2014-08-06 13:39:52 UTC
(In reply to allan from comment #27)
> This problem has been fixed in the development version.  Work is proceeding
> on the next stable release, which will be available in the next month or so.
> 
> If you are able to build from source, then that will resolve your problem.

I am trying to 'git' (git clone git://anongit.kde.org/kmymoney) but it has been here:
Cloning into 'kmymoney'...
remote: Counting objects: 9256  

for a really long time now.  
Is there another way to get the next source?

-- 
George
Comment 29 allan 2014-08-06 16:24:56 UTC
Not that I'm aware of, I'm afraid.

However, I've just tried and it took only a few seconds to finish.  It does sometimes seem to get very busy, and I just try again a bit later.
Comment 30 allan 2014-08-06 16:43:30 UTC
Let me know ASAP if you still have a problem.  As I've just done a fresh pull, I can send it to you, which should help.
Comment 31 george 2014-08-06 18:09:26 UTC
(In reply to allan from comment #30)
> Let me know ASAP if you still have a problem.  As I've just done a fresh
> pull, I can send it to you, which should help.

I have it.  Deleted the 'Update' from Fidelity I did yesterday and tried again.  Ever so much better.

Still everything is 'category' "investment transaction" in the Brokerage account, but I will file another report for that.

Thanks for all your help.
Comment 32 allan 2014-08-06 19:34:01 UTC
Good!

> Still everything is 'category' "investment transaction" in the Brokerage
> account, but I will file another report for that.
> 
> Thanks for all your help.

I thinh perhaps ypu are being misled here.

From Comment #25 -
"
In FIDELITY (Brokerage), initially, the Details first line shows the 
security name, suffixed (Dividend), the second line shows Investment 
transaction, and the Memo shows DIVIDEND RECEIVED.  If I now double 
click it, and accept the warning, Split transaction now shows, with two 
lines - investAccount:FDRXX  FIDELITY CASH RESERVES, with amount zero, 
and the second line shows Dividend and the amount, both with the memo.
"
So, try opening the transaction in the Brokerage account, then the split.  You should see the categories I think you are expecting.  The 'Investment 
transaction' you see initially, is not the category, but, I think , is just information on the nature of the transaction, like 'Detail'.