Implementing proper cost basis tracking for shares

Richard -Gilligan- Uschold uschold@cs.ucf.edu
Mon, 30 Oct 2000 18:10:34 +0000


--------------A451B23A5C2463BD8B1E7051
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 Rob Browning wrote:

> 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
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

This sounds very interesting!  I haven't been able to come up with a
'best' way to hierarchicalize (is that a word) my accounts.

If this were implemented, would this mean that in each hierarchical view,
we would get different totals for the non-leaf accounts?  (Which would be
quite useful!)

I've also thought, that for some account types, such as income and
expense in particular, it might be nice not to total the entire account
history, but perhaps only year to date, or some other selectable figure.
This would almost be a kind of generic report in the main gnucash window
and would eliminate going to an actual report for a lot of simple
questions.

--

Gilligan            |                    __o           .oooO
                   /|                  _ \<,_          (   )
                  /p|\                (_)/ (_)          \ (   Oooo.
                 /  | \             ------------         \_)  (   )
                ========                                       ) /
                 ========       gilligan@mpinet.net           (_/
             ~~~~~~~~~~~~~~~~   uschold@cs.ucf.edu



--------------A451B23A5C2463BD8B1E7051
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 Rob Browning wrote:
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

_______________________________________________
gnucash-devel mailing list
gnucash-devel@lists.gnumatic.com
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

This sounds very interesting!  I haven't been able to come up with a 'best' way to hierarchicalize (is that a word) my accounts.

If this were implemented, would this mean that in each hierarchical view, we would get different totals for the non-leaf accounts?  (Which would be quite useful!)

I've also thought, that for some account types, such as income and expense in particular, it might be nice not to total the entire account history, but perhaps only year to date, or some other selectable figure.  This would almost be a kind of generic report in the main gnucash window and would eliminate going to an actual report for a lot of simple questions.

-- 

Gilligan            |                    __o           .oooO
                   /|                  _ \<,_          (   )
                  /p|\                (_)/ (_)          \ (   Oooo.
                 /  | \             ------------         \_)  (   )
                ========                                       ) /
                 ========       gilligan@mpinet.net           (_/
             ~~~~~~~~~~~~~~~~   uschold@cs.ucf.edu
  --------------A451B23A5C2463BD8B1E7051--