On Mon, Oct 30, 2000 at 03:51:13PM +1100, Robert Graham Merkel wrote:
> Rob Browning writes:
> > 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
Rob Browning writes:
> Clinton Popetz <[EMAIL PROTECTED]> writes:
>
> > But it has to have some underlying structure somewhere, right? By
> > that I mean someplace to store the list of accounts contained within
> > it, and possibly a pointer to its parent account. So then it looks
> > like a "c
Clinton Popetz <[EMAIL PROTECTED]> writes:
> But it has to have some underlying structure somewhere, right? By
> that I mean someplace to store the list of accounts contained within
> it, and possibly a pointer to its parent account. So then it looks
> like a "container account." I guess it's
Rob Browning writes:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > This example raises some questions about non-leaf accounts.
> >
> > Right now, every node in the hierarchy is one account. With
> > multiple views, it seems we would have to relax that restriction,
> > or eliminate non-leaf
On Wed, Nov 01, 2000 at 05:00:35PM -0600, Rob Browning wrote:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > To use the example above, Where are the 'Insitution',
> > 'Institution:MegaBank' and 'Institution:Fidelity' accounts?
> >
> > Does 'Liabilities:CreditCards' include both 'MegaBank' an
Dave Peticolas <[EMAIL PROTECTED]> writes:
> To use the example above, Where are the 'Insitution',
> 'Institution:MegaBank' and 'Institution:Fidelity' accounts?
>
> Does 'Liabilities:CreditCards' include both 'MegaBank' and 'Fidelity'?
I realized I didn't actually address your specific examples
Dave Peticolas <[EMAIL PROTECTED]> writes:
> This example raises some questions about non-leaf accounts.
>
> Right now, every node in the hierarchy is one account. With
> multiple views, it seems we would have to relax that restriction,
> or eliminate non-leaf accounts.
>
> To use the example a
Rob Browning writes:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > Having more than one nickname could get pretty confusing, especially
> > if you always use the same nickname and expect the 'others' to
> > change when you change any one of them.
>
> Well, the problem is that in the way I w
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Having more than one nickname could get pretty confusing, especially
> if you always use the same nickname and expect the 'others' to
> change when you change any one of them.
Well, the problem is that in the way I was envisioning it (with
multiple vi
Rob Browning writes:
> Dave Peticolas <[EMAIL PROTECTED]> 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 nam
Richard -Gilligan- Uschold <[EMAIL PROTECTED]> writes:
> 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 total
Dave Peticolas <[EMAIL PROTECTED]> 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
(basi
Rob Browning writes:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > I agree, but I think I would miss the ability to have short account
> > names. Couldn't we let the user choose a 'Default View' that
> > performs the same function as the current hierarchy?
>
> What I had been thinking about
Dave Peticolas <[EMAIL PROTECTED]> writes:
> I agree, but I think I would miss the ability to have short account
> names. Couldn't we let the user choose a 'Default View' that
> performs the same function as the current hierarchy?
What I had been thinking about was that by default, the official
Rob Browning writes:
> Robert Graham Merkel <[EMAIL PROTECTED]> writes:
>
> > > 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 t
Rob Browning wrote:
Clark Jones <[EMAIL PROTECTED]> 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
Clark Jones <[EMAIL PROTECTED]> 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
Rob Browning wrote:
>
> Robert Graham Merkel <[EMAIL PROTECTED]> writes:
>
> > > 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
Robert Graham Merkel <[EMAIL PROTECTED]> writes:
> > 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 l
Rob Browning writes:
> Robert Graham Merkel <[EMAIL PROTECTED]> writes:
>
> 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
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
>
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 th
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Robert Graham Merkel writes:
> > As I understand it, you don't have to *always* use LIFO
> > or FIFO or some fixed rule for doing this - you can pick and choose,
> > and as I understand things you can pick an arbitrary division for any
> > particular
Robert Graham Merkel writes:
> As I understand it, you don't have to *always* use LIFO
> or FIFO or some fixed rule for doing this - you can pick and choose,
> and as I understand things you can pick an arbitrary division for any
> particular share sale - and people do, because it can have subsant
Dave Peticolas writes:
> Robert Graham Merkel writes:
> > A while ago (check the mail archives), we had a discussion on
> > share reporting, and specifically, calculating share cost basis.
> > The upshot was that we need to track which parcel of shares a share
> > sale comes from. With the
Robert Graham Merkel writes:
> A while ago (check the mail archives), we had a discussion on
> share reporting, and specifically, calculating share cost basis.
> The upshot was that we need to track which parcel of shares a share
> sale comes from. With the new file format and hash store now
> a
an example.
>
> I apologise if I'm a little slow today :)
>
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf
> Of Robert
> > > Graham Merkel
> > > Sent: Thursday, October 19,
From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
> > Graham Merkel
> > Sent: Thursday, October 19, 2000 10:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: Implementing proper cost basis tracking for shares
> >
> >
> > The
Are you looking at a new account for each parcel of shares?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
> Graham Merkel
> Sent: Thursday, October 19, 2000 10:35 AM
> To: [EMAIL PROTECTED]
> Subject: Implement
A while ago (check the mail archives), we had a discussion on
share reporting, and specifically, calculating share cost basis.
The upshot was that we need to track which parcel of shares a share
sale comes from. With the new file format and hash store now
available, it's time to think about doin
30 matches
Mail list logo
