Stock trades and realized gains/losses

[Matthew Vanecek]

--=-407LB+SJx3eYeAzq4cZB
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2003-01-09 at 11:23, Derek Atkins wrote:
> Matthew, Conrad,
>=20
> First, I should point out that it was Linas that first suggested Lots,
> and indeed, Linas wrote the (current) code for Lots.  I'm just the
> only one using them -- indeed I use them to track A/R and A/P.  An
> invoice is put into a lot, and then payments are applied to that lot.
> In this manner I can tell when an invoice has been paid.  But credit
> should go to Linas, not I, for Lots.

Indeed.  OK.  Well, they are *still* a great idea! ;)  With a little
extension, perhaps, they would be even more useful.

>=20
> Matthew Vanecek <mevanecek@yahoo.com> writes:
>=20
> > come to as well.  That conclusion is that we should be tracking the
> > dollar amounts of securities, relegating the quantities to an ancillary
> > position (e.g., part of a Lot).
>=20
> There is a clear tradeoff here.  Which do you want to be easier to
> see, the current dollar-value of your holdings or your realized
> gains/losses?  The problem is that when you track the dollar-amount of
> stock transactions you have to perform a lot of work to determine how
> many shares you currently own.  That means calculating Current Net
> Worth is a lot of work.
>=20

I want to have a clear view of realized gains (loss) in my accounts.=20
The current dollar value of my holdings fluctuates hourly, in the
current economy.  Sometimes minutely.  Current value of securities
should be calculated in a report.  Recorded value of securities should
be fairly static.  Except in the case of other than temporary changes in
value, of course, in which case an adjustment should be made and the
offset recorded in UN-realized gains/losses.  The value of a purchase
should never change in the account itself, without an adjusting
transaction.  That's just wrong on one hand, and violates GAAP on the
other.

> Also, Matthew, I think you misunderstand how LOTs work.  Lots just
> link a set of transactions (actually a set of Splits) together.  There
> is no additional data in the Lot (amounts, values, etc).  A Lot
> consists of a list of splits..  That's all.  Also, LOTs enable more
> than just FIFO -- because you can (with the right interface)
> specifically state which set of shares you are selling.
>=20

There's nothing to stop us from adding attributes, though.  At the very
least (and I think this is a preaching/choir moment) an interface is
needed to edit the relationships.  And I thought I mentioned specific
selection of Lots as a way to reduce realized gains...
Also, I do recall asking if Lots were an entity that would need to be
recorded in the back-end.  You answered quite positively. :)

> > My proposal is this: track the *number* of shares in the Lot, and the
> > *dollars* of shares in the Stock account.  This will allow proper
> > accounting of the money trail, while also tracking numbers of shares.=
=20
> > It has the side benefit of *not* backtracking to the 1.6.x model of a
> > Security and Currency per account.
>=20
> You again misunderstand how Lots currently work -- there is no data in
> a Lot -- it's all in the splits.  This does not mean that it cannot
> change to meet your request, but what you are asking for is a HUGE
> architectural change in the way ALL transactions are handled.
>=20

Lots have to have attributes; otherwise, there is no way to relate the
Splits in a single lot. At the very least you have to have an identifier
and a list of Splits.

> Now, let's assume that we change how "stock" accounts work such that
> we now track both a commodity and a currency (again).  This means we
> would necessarily need to keep TWO balances, a balance of "amount"
> (i.e. shares) and a balance of "value" (i.e. dollars).  At least
> internally that's what we would need to do, but "externally" I think
> the user always wants to see the "current value" of the account, which
> means the share-balance * current-price-from-pricedb.
>=20

I would rather calculate the number of shares dynamically, and keep the
purchase value of the stocks in the account (the 'value' field).  Note
that there is no requirement to constantly update the balance of the
investment account.  Indeed, the value shouldn't be changed except via a
properly formatted adjusting transaction.  Current values should only be
only be on "how much is this stock worth right now" reports.  Which,
looking at it, isn't very far removed from the current implementation.

> > Assets
> >     Cash
> >     COI
> >=20
> > Income
> >     RG(L)
> >=20
> > Account         Debit   Credit      Bal
> > ------------------------------------------
> > Cash                    100         100
> > COI             100                 100    <--- 10 shares @ $10
> > ------------------------------------------
> > RG(L)                   100         100
> > Cash            200                 100    <--- 10 shares @ $20
> > COI                     100         0
> >=20=20
> > In the above, the number of shares and the price/share is ancillary
> > information, and properly belongs in the Lot attributes.  Therefore, in
> > our "Stock" accounts, we should be tracking the currency amount instead
> > of the number of shares.  And you can use just one COI account for many
> > different stocks.
>=20
> The problem with this model is that while you can easily track the
> gains/losses, you cannot track the "current value" of your holdings.
> At no time can you easily determine "I own N shares of XXXX", because
> that information is stored throughout the dataset.  The other problem
> is that LOTS tie splits together in an account, but in this particular
> case the "account" for the "associated" splits are different, making
> it even more difficult to track your current holdings.  As I said
> at the beginning -- tradeoffs.

This is true.  Unfortunately, the above is the true and correct model
for investment accounting, albeit somewhat simplified.

I do seem to recall seeing, however, a complaint in a comment somewhere
about not being able to use C++, but the author was still intent on
proper opacity of object. =3DP   There really isn't a reason we couldn't
subclass the Split entity into a StockSplit entity, or similar.  That
would provide one direction of change to help track quantities in a
cumulative balance.

Another possibility is to calculate checkpoints much as the the PG
back-end does. Or extend the Lot instead of the Split (probably an
easier direction, but I haven't looked at it too hard).  Create a
StockLot, and InventoryLot, etc.  The Lot has some basic functionality:
extend it.  That's one of the key principles in OO A & D.

>=20
> > Now, from an implementation perspective, it certainly makes sense to
> > follow the generally accepted accounting principles.  To track the
> > dollar amount *instead* of number of shares alleviates the current
> > multi-currency issues with stock accounts.  It makes life somewhat
>=20
> It alleviates the gain/loss issue.  It exacerbates the
> current-holdings (net worth) issue.  To-MAY-toe, To-MAH-toe.
>=20

I wouldn't say "exacerbates", but I look at it differently than it seems
you do.  The values used in net worth should be based on the recorded
purchase cost, plus or minus any adjusting transactions for unrealized
gains (loss).  The value of a given stock *today* should not be used,
unless *today* is the day you decide the security has had an other than
temporary change in value, and record the adjustment appropriately.

> Similarly, what you are asking for necessarily requires you to define
> a common currency for ALL your accounts.  The reason is that you are
> now requiring all your transfer to be in a common currency (you need
> this in order for all your books to balance).  Any account that wants
> to track a "holding" in another commodity/currency necessarily needs
> to be a stock/currency account.  You cannot have "bank" accounts in
> multiple currencies, nor could you track income or expenses in
> multiple currencies, because you'd lose your gain/loss information if
> you ever made a transfer across currencies.
>=20

You could have an account per exchange, I guess, and record figures in
the currency of the exchange.  Multi-currency will always be an issue
regardless of the discussion at hand.  I had thought that there was some
effort being put toward a way to transfer money between accounts of
different currencies.  Perhaps I thought wrong...in any case, we will
always have to deal with cross-currency transactions.

> Sure, you could apply logic so that you can only apply a transaction
> across accounts of similar currency, and then you have special stock
> and currency accounts to perform the proper commodity transfers.  But
> we're now back to the 1.6 dual-commodity (at least for Stock, MMF, and
> Currency accounts).  Not that I'm against this concept, mind you --
> I'm just pointing it out.
>=20

> It means you have a "can't get there from here" issue, which means the
> register would have to be currency-aware and only allow you to make
> transfers across a common currency.  A Currency account would be
> "special", in that the transaction can be denominated in "either"
> currency.  A stock account would still only be allowed to have
> transactions denoted in its currency.
>=20

Which is really how it should be anyhow, IMO.  My Ameri-centric
understanding is that when you buy stock from an exchange you pay for it
in the exchange's currency.

> > easier when generating reports--there is no longer a need to run through
> > many Lots to get a total of realized gains/losses for a period.  You can
> > see at a glance the dollar amounts for gains/losses and current invested
> > amount.  Net worth calculations are also simpler to implement.  Also,
>=20
> Ok, I'll bite.  How are net worth calculations simpler to implement?
> Right now all you need to do is get a current price on all your
> commodities and then perform a multiplication across all your
> accounts.  How does your method make it any easier to track net worth?

Net worth is not calculated based on the current value of shares across
accounts, but rather it is based on the purchase cost +/- adjustments
(i.e., the running balance of the asset account, same as in other
accounts).  You don't have to do the price retrieval, nor the
multiplication.  There could be an option, perhaps, allowing for use of
current price.

I'm not opposed to having an account per security--mainly because I
don't have enough to make it annoying.  That rapidly becomes unscalable,
though, which is why I would prefer to be able to enter investment
purchases in a single account, or an account per exchange.  It's
probably simpler to (re)implement it as a stock-per-account, though,
because with the addition of 1 field (stock balance) and a few methods,
we can track both the share balance *and* the purchase balance.  Which
is what I had in mind when I suggested a StockSplit subclass above...

> > Accountants generally are more interested in dollar amounts, not number
> > of shares (I've seen many questions from Gnucash users about how to get
> > info in a form appropriate for Accountants).  And to retrieve the number
>=20
> Well, sure, the Accountants want this information..... once a year!
> The rest of the year I want to know "how well is my portfolio doing,
> and what is it worth?"  Shouldn't we optimize for the "likely"
> operation, not the once-a-year operation?
>=20

If you want to know how your portfolio is doing today, you bring in the
current price and run a report.  If we're able to subclass Split, the
point is moot.

I myself would prefer to adhere to GAAP as closely as possible.  I feel
it gives me a better grip on my finances and one less thing to worry
about in today's economy.  Others may not be so stringent. *shrug* life
choices.  I believe we can accommodate both sides, though, and make
*most* people happy.

> > of shares and other Lot information, all you have to do is add the
> > Transaction GUID to the GUID list in whatever Lot, or possibly more
> > appropriately, add the GUID of the Lot as an attribute of the
> > Transaction (foreign key, as it were).
>=20
> > I don't know how far Derek has gotten on the Lot development.  I
>=20
> Well, Linas had lot's "done" for a while.  I fixed a couple of bugs in
> them, but they are there and have been for a while.  They just aren't
> being used by anything except A/R and A/P invoice/payment tracking.
>=20
> > able to do so.  We would want to record the number of shares in the Lot,
> > of course, but that is a required interface in any case.  The security
>=20
> No, lots tie splits together.  There is no "share" information in a
> Lot.  You determine the number of shares by looking at the "first"
> Split->amount in the lot.
>=20

> > mnemonic could also be stored in the Lot, which would allow us to
> > combine security investments in one account, instead of a separate
> > account for each security.
>=20
> This _sounds_ like a good idea, but it makes account valuation HARD.
> As conrad says, this might be a good way to hand Inventory, but a
> stock portfolio is NOT inventory.  With inventory you want to know how
> much you paid for your assets, and subtract out depreciation.  But
> that's NOT what you want to know about your stock holdings.
>=20

Actually it is.  You want to maintain a static balance, and create
adjusting transactions when the value as apparently permanently changed.

Current values should be calculated on the fly and relegated to a
report.  The reports, of course, help you decide when to make adjusting
transactions.

> But let's assume for a moment that we do store the stock commodity in
> the Lot instead of the Account -- you still cannot store the number of
> shares in the Lot.  The reason is that there is not a 1:1 mapping of
> purchases and sales.  I could have a Lot that contains the following
> Splits (note that I'm leaving out the date, and the "account" is
> assumed)):

Yeah, you may be right, if we don't extend Lots.  I realized that, and
came up with the above StockSplit idea.


>=20
> > In the current register, as far as I can tell, the only immediate change
> > that should be made is to record a dollar amount in Balance instead of a
> > number of shares.  That's the first step torwards aligning with
> > accounting practices.  Derek's work with Lots will go a long way to
> > making this a reality, if he agrees with my assessment (well, he *is*
> > the one writing the code!).
>=20
> What it sounds like you REALLY want (and you don't need Lots to do
> this), is a DOUBLE BALANCE.  You want to accumulate a balance in
> SHARES as well as a balance in VALUE.  But that is still not
> sufficient to do what you are asking.  The problem is still that you
> need to balance each transaction.

Each transaction should be balanced monetarily.  This is possible if you
track the balance in currency instead of shares, and track the purchase
cost vs. today's volatile market price.  Record the number of shares and
price as we do now, and offer a warning if price * share !=3D
debit/credit.  Assuming no value adjustments, though, the amount of a
credit should equal the original purchase price, with the rest of the
money (or lack thereof) being recorded in realized gains (loss).


> Now, let me show you how this looks from the LOT view.  In paricular
> the Lot view has the following splits:
>=20
> (type)	amt	val	(amt-bal)       (val-bal)
> buy     10      $100	10              $100
> sell    -5      -$150   5               -$50
> (gain)  0       $100    5		$50
>=20
> The (new) invariant of a Lot is that it is "closed" when both the
> sum-of-amount _AND_ sum-of-value is zero.  That way you know it is
> closed when you've accounted for all the shares _AND_ all the
> gain/loss.
>=20
> If we do it this way, then:
>=20
> a) you get your gain/loss split
> b) I get my "net value" and holdings balance
> c) it does not require a major architectural shift in the way gnucash wor=
ks.
>=20
> This would require two minor change to lots.  First, you need to
> enforce that all transactions within the lot are denoted in the same
> currency.  Second, it would also require a change to how
> gnc_lot_is_closed() works.
>=20

Well, the entire goal is to be able to record a gain/loss amount in a
Split under a gain/loss Income account.  I would prefer that Stock
accounts be tracked in monetary terms, too, if possible.  Maybe there's
a way to do both...

> Unfortunately it also would mean that any multi-curency transaction
> would need a lot as well (for the same reason -- to track gains/losses
> in currency transfers).  But I'm not convinced this is a bad thing. ;)
>=20

This will always be a problem, at least until *everybody* is using the
same currency *everywhere*.

> I certainly don't have all the answers, but I don't see Gnucash as a
> tool for accountants -- I see it as a tool for PEOPLE.  Interfacing to
> accountants should be a secondardy goal, not a primary goal.  I think
> I've shown how we can do both.

It's definitely important for the average Joe to be able to adapt
Gnucash to personal needs.  I've seen enough questions about how to
export data to this or that format, or provides thus-n-such a report, in
a format for the accountant, that I believe maintaining tight
compatibility is very important.  Not only that, but the compatibility
really *does* help provide a clearer financial picture.

Please understand I'm not suggesting we should provide a tool suitable
for use only by accountants.  Where possible I think we should provide
as simple an interface as possible, while still maintaining the (hidden)
data in an accounting-suitable format.  I also think that we should
provide the capability for an accomplished accountant to dive right in
and start using Gnucash with minimal fuss.  Perhaps a pipe dream--but a
worthwhile goal nonetheless.

I think I've used my quota of college words for the day, so I'm gonna
stop now...

--=20
Matthew Vanecek
perl -e 'print $i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
***************************************************************************=
*****
For 93 million miles, there is nothing between the sun and my shadow except=
 me.
I'm always getting in the way of something...

--=-407LB+SJx3eYeAzq4cZB
Content-Type: application/DEFANGED-58115; name="signature_asc.DEFANGED-58115"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA+HmaRi/CNzDSN0RIRAg5lAJ48wVa+VrineEMXS/NOpejjROgjqgCgkIey
ytDRqm3qiNFLgk4SG+uZVUI=
=t02v
-----END PGP SIGNATURE-----

--=-407LB+SJx3eYeAzq4cZB--