Rob Browning writes:
> Robert Graham Merkel <[EMAIL PROTECTED]> writes:
>
> > As far as I can see, all we need is for each share account to store
> > a table with the details of the currently owned parcels, and each
> > "sell" transaction to contain the details of which parcels have been
> > sold.
>
> I'm not fully versed in all the financial ramifications, but I left
> that discussion thinking that practically speaking, we could really
> only track the events (buys/sells/splits/etc.) as the "facts", and
> needed to leave the computation of cost-basis, etc. up to a separate,
> and more flexible, "computation" process that would run later.
>
Correct. We only need to record which shares are sold - the
computation of costs is done at the reporting stage.
> Another thing I recall is that whatever we do, we need to be very
> careful to make sure we can unambiguously reconstruct what happened -
> we have to be able to tell which transaction splits are purchases,
> which are commisions, which are stock splits, etc. I'm not sure we
> ever determined whether or not we could always do that implicitly, or
> whether or not we were going to need to start using special "tags" for
> each type of thing...
>
I'm not sure on the stock splits issue. Maybe I should re-read some
of the archives on that.
> Finally, if I'm understanding your question about using multiple
> accounts correctly, then I think that's *exactly* what the QIF
> importer does, and is probably the right thing, at least given our
> current setup. i.e. if you have a stock/mutual-fund, you'll probably
> also need a parallel income account for dividends, etc. We might even
> want to make creating any parallel accounts part of the "Buy stock"
> helper process, as an option that's enabled by default.
>
Yep.
> Having several accounts of various types associated with every
> security is currently a little awkward for people who'd rather see all
> their stock-related stuff together, given our soemwhat primitive
> "chart of accounts", but we can change that later.
>
Yeah.
> Dave, do you recall what conclusion we came to, if any when we were
> musing about the possibility of (internally) killing off the account
> heirarchy altogether? ISTR we talked about the possibility of just
> having one large flat account list, and then representing heirarchical
> organizations of these accounts as trees containing pointers into the
> global list. In this setup we could relax the type relationships --
> and even show multiple different organizations of the accounts.
>
> You might want one view that organizes by type, with all the income
> accounts together, all the expense accounts together, etc. You might
> want another that organizes by institution, with all your Fidelity
> accounts/stocks/etc together, all your MegaBank accounts together, and
> all your credit union accounts together....
>
> I don't really know how much flexibility we'd want to allow initially,
> but changing the internals at some point might make accomodating
> various different schemes easier.
>
I dunno if you saw the discussion I was having on the list a while ago
about being able to do this, but only for reports. If we generalised that to
*everything*, it would be an interesting possibility :)
------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
------------------------------------------------------------
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
