Implementing proper cost basis tracking for shares

[Rob Browning]

Dave Peticolas <dave@krondo.com> 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 <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930