[Kmymoney] Investment accounts

[aga]

On Wed, 31 Aug 2011 13:30:01 -0700
Konstantin Svist <fry.kun at gmail.com> wrote:

> On 08/31/2011 12:25 PM, aga wrote:
> > On Wed, 13 Apr 2011 17:01:54 -0700
> > Konstantin Svist<fry.kun at gmail.com>  wrote:
> >
> >> Hi Allan,
> >>
> >> I'm attaching an example CSV from Schwab.
> >> I've replaced account numbers with 1234... still, please don't
> >> publish it anywhere :)
> >>
> >> CSV importing would probably sound a lot better if it didn't
> >> require extra steps (log in to website, go to account history,
> >> download, open with KMM...)
> >>
> >> Hope it helps

Yes, the OFX procedure works much better, when it works!

> > Hi Konstantin
> >
> > I'm looking at the csv file you sent and am wondering how to deal
> > with it.  Up to now, with investments, I've had fairly simple
> > formats to deal with, involving a single stock, etc.  With brokers,
> > though, things obviously can become more intricate.  Knowing what
> > you later said, that related items of a single transaction can be
> > shown separately, how can the csv importer plugin know which are
> > and which are not, related?
> >
> > Ideally, of course, the file should be importable as received, but
> > if this turns out to be infeasible, might it be acceptable for a
> > user to do minimal editing, like inserting a marker character/line
> > between 'groups' (as in qif files)? Bearing in mind that, again
> > ideally, any grouping method needs to work for other users.
> >
> > I'd appreciate any ideas.
> >
> > Allan
> 
> Well, the way KMM OFX import deals with it is simply treating each
> line as a separate transaction - that's obviously an easy starting
> point. It looks like you'll need to parse the Description field to
> get any meaningful data out of this, since it doesn't seem to like
> listing actions other than buy and sell... On the bright side, the
> Description field is fairly consistent:
> * if it's a buy or sell transaction, description is a full security 
> name. Those list fees & commissions in the appropriate column and
> don't need to be grouped.
> * otherwise, it always has a "type: ..." suffix which you could set
> your parser to check for. Grouping within multiple security-related 
> transactions is then by date + security name part of description
> * for interest and transfers it's obviously a little more complicated 
> since it doesn't involve a security - but those don't need to be
> grouped...
> 
> I can explain each transaction in more detail if that would help -
> let me know which ones you're not sure about.
> 
> 
> HTH,
> Konstantin
> 

I have your file importing now, at least to line 55, where a date of
"07/24/2009 as of 07/20/2009" causes it to expire.

Apart from the split I queried, the 10 straight investment items are
correctly handled, and the remainder go to a checking/brokerage
account, although I need to look still at their categories.  The split
doesn't have either an investment action type, or a 'type:'
description, so they too go into brokerage.

Cheers

Allan