Implementing proper cost basis tracking for shares

Rob Browning rlb@cs.utexas.edu
30 Oct 2000 10:08:08 -0600


Clark Jones <jones@inficad.com> writes:

> I'm sorry, I'm not familiar with GLists or GSLists, but the comment
> about "'bottoms out' in Account*'s" makes me a bit nervous that it
> would only allow entries into the "leaf" accounts.  There are times
> when it is convenient to put some entries into a given "level", and
> others into a "sublevel", e.g., I might have
> "autos->pickup->maintenance" that catches most of the costs, but if
> I wanted to keep track of, say, tires, these might go into
> "autos->pickup->maintenance->tires".

Good point, but I wasn't planning to preclude that.  At each level,
the account "view"'s list would be a possible mixture of sub-lists and
actual account pointers like this:

  (("autos" . guid-331)
   (("clunker" . guid-443))
   (("pickup" . guid-683)
    (("maintenance" . guid-4392)
     (("tires" . guid-342)
      ("electrical" . guid-9221)
      ("fuzzy-dice" . guid-113)))))

Which is equivalent to:

  autos
    clunker
    pickup
      maintenance
      tires
      fuzzy-dice

Whether or not we'd use actual Account*'s or guids is debatable...
Also (see below), some of the names in the "view" might not even have
associated accounts.

(GLists are glib's doubly linked list, and GSLists are singly linked,
 and more accurately match the semantics of scheme lists.)

> I hope that you're just using the space delimiter in "MegaBank
> Savings" as an arbitrary name.  One of the nifty things about
> gnucash as opposed to Quicken is that I don't have to replace spaces
> in the account names with underscores... (and I also don't have to
> stop at some tiny number [16?]  of characters!)

The name "MegaBank Savings" would be the "true name" of the account,
but it might be referred to from a variety of "view" structures.

The idea is that with these "views" you can organize your accounts in
*ways* (not just one fixed way) that make sense to you.  It's also a
machinery that we, as the programmers, can use to collect and display
your accounts in various meaningful ways.

For example, presume the actual account named "MegaBank Savings" had a
guid of ABCDE, then you might have:

  Institution
    MegaBank
      checking -> BCEF
      savings -> ABCDE
      visa -> 4EFA
      brokerage
       clearing -> CCFD
       securities
         IBM -> FF61
         GNU -> FA0B
         SuperFund -> EF11
    SuperUnion
      checking -> 5651
      visa -> 7790

(note that the Brokerage doesn't have an associated account because
 it's just a placeholder organizing all the stock bank and fund
 accounts that together represent all your holdings in the brokerage.
 Same goes for the "securities" name.)

and perhaps

  Assets
    MegaBank
      checking -> BCEF
      savings -> ABCDE
      brokerage ...
    SuperUnion
      checking -> 5651
  Liabilities
    MegaBank
      visa -> 4EFA
    SuperUnion
      visa -> 7790

And maybe another flatter one by type:

  bank accounts
    MegaBank checking -> BCEF
    MegaBank savings -> BCEF
    SuperUnion checking -> 5651
    MegaBank brokerage clearing -> CCFD
  credit cards
    MegaBank visa -> 4EFA
    SuperUnion visa -> 7790
  securities
    MegaBank IBM -> FF61
    MegaBank GNU -> FA0B
    MegaBank SuperFund -> EF11
    Fid Retirement SuperFund -> AADF
    ET brokerage DFFO -> AADF

All of the names in these views were assigned when the views were
created, but the underlying unique accounts still have their own
"official names", and somewhere, we'd have a view that let you look at
the official flat list of all your accounts, probably sorted
alphabetically...

  MegaBank brokerage clearing -> CCFD
  MegaBank checking -> BCEF
  MegaBank savings -> BCEF
  MegaBank visa -> 4EFA
  SuperUnion checking -> 5651
  SuperUnion visa -> 7790
  
This is the pool from which you'd draw when creating "views", and it's
the only place you'd be guaranteed to find *all* your accounts.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930