[EMAIL PROTECTED] wrote:
>
> It's been rumoured that Matt Sisk said:
> > The accounting engine, after all, is counting cash, not shares.
>
> strictly speking, not true. in a stock account, the total number of
> shares is the invarient quantity. The dollar value fluctuates
> minute by minute, the number of shares you own does not. ergo,
> the engine counts shares, not dollars.
I understand what you are saying here; this could be a discrepancy of
perspective. I am trying to reconcile my intuition with the way the
"real accounting world works" since I don't normally deal with this sort
of stuff in daily life. So, I am not at odds here; I'm interested in
exploring this.
For the sake of clarity, let's assume a single, symmetric stock
transaction. You buy X number of shares, and at some later date you sell
X number of shares.
In the intervening time period, there are numerous things that could be
affecting your stocks. As you point out, the price fluctuates. Although
the number of shares do not fluctuate minute by minute, the nevertheless
possibly fluctuate due to splits/joins. My intuition says that from the
perspective of the bottom line, the only thing that is important about
the process is the total amount of the purchase and the total amount of
the sale; in that sense, perhaps the "transaction" should not be
considered complete until you have sold the X shares. (is there any
utility in modeling a double-entry transaction with sub-transactions,
each of which also happen to be double-entry?).
I understand that there are statements you would like to make about
those X shares of stock along the way, such as "how much is it worth
today"...but even though there is a real world worth to the shares, it
might as well be virtual unless you sell at that time.
This of course is more complicated if the entire set of transactions of
X shares of stock involve a many-to-one or one-to-many symmetry, but
other than connecting the dotted lines for tax purposes is not all that
much different.
> > 1) The number of shares can be retroactively altered, but the
> bad idea as you later point out.
Hmmm...I pointed out that it had certain drawbacks; I'm still searching
for a "best" method of dealing with it. The other methods I've seen have
drawbacks as well -- so far it's been like squeezing a balloon -- where
do you want the bulge (complexity) to be?
> > Again, the most important piece of information is the
> > total value of the transaction *at the time it occurred*.
> > The number of shares can (and will) pivot.
>
> Right. And in gnucash, the value of all transactions is *always*
> zero (at least when you have double-entry enabled). That's how
> books are made to always balance: they balance by definition.
I understand this. I've been trying to figure out how a "stock
transaction", in the sense of purchase, hold, and sell, maps into this.
Obviously, with two accounts (portfolio account, plus an account for a
stock, or however you model it), the purchase is a double-entry
transaction, and so is the sell. I don't see how the core engine is
concerned with what happens in between (I'm hoping to have it easy here
and get an explanation from *you guys* rather than grok the code! ;-)
> > 4) regarding the accounting engine of gnucash, it should not
> > even *see* particular stock transactions unless there
>
> striclty speaking, not true. The engine records 'transactions'
> which are events that occur at a certain time. These events
> may or may not transfer value between different accounts. If its not
> recorded, there is no way to display it, to talk about it, to
> save it to a file. In that sense, transactions are fundamental.
I guess we should be careful about what we mean by a "transaction" when
we're discussing these things. I saw an earlier note pointing out the
difference between a "real world, financial transaction" and the
"internal transactions" that take place in the engine. Now I'm bandying
about phrases such as "stock transaction" where I mean the whole arc
involved with owning and selling a stock, which is not as granular.
So, okay, partly I was not aware that the accounting engine was so
intimately involved with "event logging" as well as actual transfer of
value between accounts. I also do not yet know what the engine accepts
as parameters for an "event"; in this sense I am handicapped in
discussing whether things should be visible or not to the accounting
engine.
Is there room in the model for meta-engines? By this, I mean have a
dedicated engine that tracks things particular to an activity such as
stocks/commodities, and notifies a central accounting engine when
necessary, ie, value moves across accounts? Then you could ask the
meta-engine such questions as "what was my portfolio potentially worth
at time T" and the central accounting engine would not have to worry
about the details of that market, nor the answer to that type of
question. In that sense, the accounting engine would have an API of
sorts, with the dual-entry system intact, and you could plug all sorts
of other crazy event models into it. Just for kicks, let's say we're
talking about an investment in rabbits. The central accounting engine
should really only be concerned with transactions involving a) cost of
initial rabbits, supplies, maintenance, and b) proceeds from rabbit
sales. It really doesn't need to be able to make statements about how
many rabbits you own at any given time, or the worth of all of your
rabbits at that time, or rabbit losses from rabbit plagues or
neighborhood dogs; the "rabbit accounting engine" should take care of
those messy details.
> all the perl quote modules are on sourceforge now, see
> https://sourceforge.net/project/?group_id=4232
>
> insofar as you have a way of dealiong with historical (not just current)
> stock data, I think you will want to see if you can join forces with
> that effort.
I have been discussing this with Paul; currently, as you can see, I am
endeavoring to understand gnucash a bit more properly to see what sort
of role and interface I would be dealing with.
For my own purposes, I would eventually like to see VPS abilities built
in to gnucash, which not suprisingly involves historical quotes. There
are other, probably simpler, ways of tracking portfolios as well. VPS is
very accurate if you happen to have access to a good event log and
historical prices, though. It makes pretty pictures, anyway!
Thanks,
Matt Sisk
[EMAIL PROTECTED]
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
