Well, I am curious as to what you thought of the meta engine question in
my last email...I know it rambled a bit, but check it out if you have
the time and patience...
Onward...
[EMAIL PROTECTED] wrote:
>
> It's been rumoured that Matt Sisk said:
> > 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.
>
> as far as gnucash is concerned, this is *two* transactions.
>
> A transaction is 'atomic', i.e. is indivisible, and always has a value
> of zero: thus:
>
> jaunuary 23 12:05:43 (gnucash actually records nanoseconds)
> -$1000 (withdraw from bank abc)
> +$1000 (buy 100 shares at $10/share, deposit into brokerage def)
> (gnucash records both price & amt)
> ------
> $0.0000
>
> the above is considered to be a single transaction, with two 'entries'
> in it (the withdraw from bank ABC, and the deposit into stock acct DEF)
Yes, this I realized. However, for the sake of the accounting engine not
having to worry about things such as splits, why not specify the +$1000
as "buy 100 shares for $10,000" -- that way you do two things. The
engine never cares about stock splits, because the total price of the
transaction is intrinsically captured. There is never a discrepancy over
whether you have used the historical or adjusted stock price, because
you don't need the stock price for the accounting. The historical and
adjusted prices are only useful for stock analysis functions, which
should probably be occurring somewhere else in gnucash other than the
core engine.
> What may or may not happen at a later date is *entirely* independent of
> what happened in that 'nanosecond'. Its also independent of tax laws,
> accounting practices, etc. Its simply a record, an unarguable 'fact'.
>From a cash transaction standpoint, this is entirely correct...I agree,
so long as the "fact" is unambiguous. When you get into higher level
analysis of stocks, such as portfolio performance tracking, it is useful
to consider the daily fluctionations in relation to the starting
point...my only point being that the core accounting engine is not
necessary for anything other than providing the starting (and finishing,
if applicable) points for this sort of analysis. I'm not implying that
it is currently used this way -- just wondering whether the starting and
finishing transactions could be expressed in a more precise fashion.
>
> > the number of shares do not fluctuate minute by minute, the nevertheless
> > possibly fluctuate due to splits/joins.
>
> This should get stored as follows:
>
> april 23 12:05:43
> -$5000 (withdraw 100 shares at $50/shr from broker DEF)
> +$5000 (deposit 200 shares at $25/shr at brokerage DEF)
> (gnucash records both price & amt)
> ------
> $0.0000
>
> This transaction, just like the last one, happened 'instantly'.
> The value of your brokerage account did not change.
So if the initial transactions were specified in terms of shares and
total value, this adjustment transaction would be unnecessary. I guess
this is what it really boils down to. Which way is better? This seems to
be a question more appropriately phrased as "what is the scope of the
core accounting engine"? Is stock analysis part of the scope?
> what you cal an 'event' is what we call a 'transaction'. It always
> happens 'instantly', without time delay, so we don't have to think
> of things like interest rates, etc.
Understood. I have no problem with this language, so long as we agree on
the words!
> It must necessarily be simple; if its complex, then its unauditable,
> unverifieable, etc. simple == good.
I would argue that the shares and total value method is simpler from a
gross accounting perspective. Let's hear about the scope of the engine.
> Under the covers, transactions are all that there is. Everything else
> is 'just' GUI or 'just' a report. We generate guis & reports on the
> fly. But the actual financial data, the records that must never be lost
> or mangled or accidentaly mashed, are the 'transactions'; they're
> what's permanent.
With stocks, if you have the initial ("buy") and final ("sell")
transactions in terms of the total amount (and the ticker symbol, of
course), everything else can be reconstructed using historical
(adjusted) quotes, or daily current quotes if you are storing the values
as you go along.
Do the daily quotes get stored in the transaction log, or somewhere
else?
> > For my own purposes, I would eventually like to see VPS abilities built
>
> what's VPS?
Value Per Share accounting. You treat a stock portfolio like you would a
mutual fund, including your cash on hand. You assign a number of shares
and an (arbitrary) share price when you create the portfolio. The VPS is
the "share price" of your portfolio -- all of the holdings (based on the
closing prices for that day) plus your cash on hand are added together
and divided by the number of shares. This is the VPS. If you deposit
money, or withdraw (such as for capital gains taxes), this is reflected
in the number of shares you hold. The total value of the account may
increase or drop based on withdrawals and deposits, but the VPS does not
change. You can then compare the VPS performance of your holdings with
other indices, such as the NASDAQ, S&P500, DJIA, etc.
Of course, in order to do this with absolute accuracy, you either need
to grab current quotes on a daily basis, or have access to historical
quote data. Otherwise you have to interpolate between the "quote gaps".
VPS accounting is what the Port Trak spreadsheet from the Motley Fool
does...in fact, that's where I learned about the method. The spreadsheet
requires daily quotes. In the quote gaps, it simply repeats whatever the
last known value for the VPS was until it hits the new data. This is
fine, but the pictures aren't as pretty. ;-)
For gnucash, I think this sort of analysis (and there are other methods
to be sure besides VPS) should be performed in a dedicated module --
only the cash transactions should be absolutely necessary in the core
accounting engine.
Matt
[EMAIL PROTECTED]
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
