Implementing proper cost basis tracking for shares
31 Oct 2000 08:57:25 -0600
Dave Peticolas <firstname.lastname@example.org> writes:
> So we would have a 'long' name and a 'nickname'?
Sure, though in my original incarnation, I was thinking of an
potentially limitless number of nicknames depending on the view that
the account was in. In fact the name would be a part of the view
(basically the path through the tree (GList of GLists) that you took
to get to the account, not a field in the account itself.
i.e. Income:Consulting:GreatEnterprises might refer, in a given "view
tree" to the account whose "true name" was "GreatEnterprises
Consulting Payments". The name Income:Consulting:GreatEnterprises is
just the set of names you hit when you go down a particular "view
tree" to get to this account.
(("Income" . #f)
(("Consulting" . #f) ...
(("GreatEnterprises" . Account*0xF4423A)
A name with a #f just means that it doesn't have any associated
account, though one could be added later. Also, I'm just using
scheme-notation for illustration. As I mentioned, I would plan on
implementing this in glib.
> Do you mean ditching engine-cached subtotalling? We should probably
> get rid of that, as the issues with currency translation are going
> to make it a bit complicated, but we should still display subtotals
> in the hierarchy.
Mostly what I meant is that in some hierarchies, subtotalling's not
going to make any sense, at least in certain parts of the heirarchy,
so perhaps it should be a per-level option, or perhaps it should only
become active if all the sub-account types match properly, or both...
Rob Browning <email@example.com> PGP=E80E0D04F521A094 532B97F5D64E3930