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.
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
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
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.
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".
Created attachment 87749 [details] Import without creating the account first The account is missing that's why the transaction shows up as erroneous.
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.
Created attachment 87751 [details] Import after creating the account and the brokerage account The transaction looks OK and does not show as erroneous.
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.
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.
(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.
(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.
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.
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).
(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.
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?
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
(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.
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
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 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.
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
(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
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
(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
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
(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
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.
(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
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.
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.
(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.
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'.