Hi folks,
I am relatively new to the list. And as a caveat, let me say that I am
pretty unfamiliar with the internal workings of the gnucash accounting
engines, other than implications based on what I've read on this list.
I've been following the discussion regarding the proper way to handle
stock splits. It seems to me that it all depends on the method of
handling accounting for your portfolio.
Some of the muddle seems to be over what the "value" of stock holdings
are in terms of a per-share basis. This, combined with the nature of the
gnucash accounting engine, might be producing a "wag the dog" effect on
tracking a stock. I understand that stock shares are real-world items
with value, such as apples; however, there is utility in the notion of
such things as "virtual" transactions for things such as a split. Rather
than tracking the per-share value, I think it's more intuitive to track
the total value of a particular transaction (whether that be a purchase
a while back or recently of the same stock). Each transaction has a
starting value, regardless of the number of shares. Assuming the
transaction is a "long buy", there will eventually be one or more sell
transactions to associate with the buy. (I understand that the order of
association is debatable, but that's another issue). Even though a stock
share is property with real value, all of the daily fluctuations in the
value of that original sell transaction are probably best thought of as
"virtual" -- they are the value had you chosen to sell at that time. A
stock split does not change the overall value of the original
transaction, therefore should not be visible to the accounting engine.
The accounting engine, after all, is counting cash, not shares. A split
should be, if anything, a "virtual" transaction behind the scenes. In my
dabblings, I have dealt with this in the following way:
1) The original buy has a total value, plus number of shares.
The number of shares can be retroactively altered, but the
total value remains the same. As has been discussed,
this produces some complications, but this method does not
(and should not) affect what goes on in the accounting
engine. Since your are calculating the share price
from these values, you do lose historical context
for the per share value; this has pluses and minuses,
see below for more.
2) Use floats for the "number of shares" fields. This really
bothered me at first, but the brokers deal with their
client accounts in terms of partial shares all of the
time, especially in cases where dividends are reinvested.
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.
3) Track split information, by float, ratio, or both.
This is not strictly necessary, but might be useful for
reconstructing what occurred.
4) regarding the accounting engine of gnucash, it should not
even *see* particular stock transactions unless there
is some sort of change in total value for the initial
transaction. (as 1 buy might eventually be reconciled
by several sells, so might several buys be reconciled
with a single sell, but in all cases there is a delta
in the total value for the original transaction). Things
such as splits should not be visible to the accounting
engine.
There are pros and cons to point 1, depending on how your portfolio
tracking interracts with the real world. One of the drawbacks of
retroactively altering the number of shares is that you break the
relationship between your accounting transactions and your hard copy
proof of the transactions. This produces a data entry headache. If you
need to verify or correct a past transaction by returning to the
transaction notices from your broker, for instance, you have to mentally
track how many splits have occurred and reconcile this with the
"current" number of shares the transaction represents. This is a pain in
the ass; I am still not sure how to satisfactorily deal with this from
the standpoint of the end user. An extra historical field in the
transaction record noting the original number of shares would help --
used in conjunction with historical split information, the current
number of shares can be calculated, but this requires accurate split
information.
Here are the pros. In the real world, historical stock prices available
at various web sites tend to reflect the adjusted share prices, with all
splits accounted for. Some, such as yahoo, reflect the actual historical
price, plus the adjusted price. But in general, it has been my
experience that what you get is the adjusted price. By tracking each
transaction on a total value basis with a pivoting number of shares, the
adjusted historical quotes can always be used as an applicable data
source.
I am not familiar with all of the portfolio accounting methods that use
this information; I am particularly familiar, however, with the VPS
(value per share) method of portfolio tracking, such as how you might
track the value of a mutual fund. In order to retroactively compute VPS
for a particular portfolio, historical stock quotes are absolutely
necessary (and, possibly, cash-on-hand for that account).
As it so happens, I have some historical quote modules written in perl;
I was planning on asking this list if they could be of use within
gnucash. I'm still cleaning up some pieces of the modules, but I will
send a more detailed note to the list soon. In the meantime, I'm very
much interested in the approach that will be taken for tracking the
evolution of stock transactions in gnucash.
Sorry for the ramble. I am not an accountant; if you see any glaring
snakes in the grass regarding how I was intuiting stock representations,
please feel free to comment.
--
Matt Sisk
[EMAIL PROTECTED]
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
