Re: Investment Addon

[Chris Travers <..hidden..>]

On Tue, Aug 9, 2011 at 9:33 PM, Luke <..hidden..> wrote:

> Yes, although potentially non-face-value bonds might fall under this as
> well, short or long term.  I shouldn't have included CDs in the list though,
> as they can probably be tracked by conventional means, by just a transaction
> to record the interest, one-time.

That's a decent point, but CD's are not that different from
longer-term face-value bonds, really.

> Don't know.  They are basically individuals, and unless they are very good
> at keeping things separate, there is often a lot of overlap in personal and
> business finances.  Although, maybe this could at least help, even if it
> doesn't cover the whole picture.

Ok, my point is this:  there's a business asset/equity tracking issue
here and there's a sale value tracking issue.  The sale value is
separate.  It doesn't affect the books until a sale is made, then you
account for the capital gain or loss.  Tracking this for an individual
investor is really less of an important issue on a day-to-day basis
*if* the individual is not concerned with creating balance sheets for
him/herself.....

>
>> Well, the concerns of an individual might be different.  An individual
>> might want to sell stocks that are higher-priced and buy ones that are
>> believed to be undervalued.  I don't think this affects the accounting
>
> That is not a desire limited to individuals.:)

Of course.  Just the idea of a useful balance sheet and assets owned
is going to differ between whether you are trying to do serious
business accounting and whether you just want to know what you can get
for what you have.

>>
>> * Enter company info, positions purchased, position type, total stock
>
> What do you mean by type?

For example, preferred vs common stock, vs bond.
>
>> issued by firm, relevant gl accounts, and cost.  On sale enter
>
> I'm not even sure you need the total stock issued data in the most basic
> version.  It is not a fixed number anyway.

true.
>
> Cost does not always stay the same--splits, dividends, and selling covered
> calls can change original cost basis, so that needs to be updatable.

How do dividends affect cost basis?  I can't find any information on
that.  I would think that dividends (being drawing instead of capital
investment) would not affect cost basis.  I see some notes that they
do but I can't see anything about how or why.

(Equity accounting is different, in the sense that you are recording
your share in the company's balance sheet and so dividends get tracked
along with income and expense.)

However in all cases, you want to track changes on an on-going basis,
not update data currently stored in the database.

>
> It should provide, either initially or eventually, for recording:
> * Dividends
> * Selling covered calls

At first (with cost-method) I would expect dividends to be recorded
through the GL.  This could be integrated into the module later.  I'd
have to look up more about covered calls.
>
> (Both are pretty common for income investors.)
>
> That does not yet account for dedicated short transactions:
> * short sales
> Should be simple enough - that's really just an inversion of the buy and
> sell dates; cost basis, at least in the U.S., is calculated on closing.
> * selling puts which cause long stock positions to open upon assignment
> (I would like to be able to manage that some how, as I do it several times a
> year:))
>
> It would eventually need to provide for option transactions which do not
> involve the stock directly.  So even if those can't be handled right away,
> the design should be able to expand to it.  That is why I suggest what I do
> below--it does not actually require owning the underlying stock to work.
>
> The method I was trying to develop, was something along the lines of
> creating a position in a security as you described, and then having a
> per-security transaction ledger, which could account for all of those kinds
> of transactions I spoke of, and others which are combinations of those.  It
> would also allow for multiple positions in a single security, such as buying
> a stock and then adding to the position later at a different price.
> The database would record all the relevant information, along with the
> security identifier to allow grouping and sub-ledgers per security.
>
> I have done partial work on figuring out how that might look from a UI
> prospective, to see what might need to be tracked, but haven't finished.
>
> That will cover ETFs/mutual funds as a subset, and probably bonds as long as
> you can change the interest/dividends income account.
>
> Anyway, that's what I was thinking.  Don't know how useful the advanced
> functionality is to anyone other than me.
> Clearly it's more difficult and problematic than what you were thinking, but
> I see several immediate cases that would be difficult to manage through the
> design you suggest.

Still not sure.  I think you'd have to track all the things that could
happen to the stock so that a paper trail would be preserved.  So
there might need to be some additional elements like split tracking.

>
>> * Allow a simple report of investments and their purchase price.
>
> Purchase price is sometimes irrelevant--you want cost basis, or both.
> See: http://www.investopedia.com/ask/answers/05/costbasis.asp

>
>> Equity accounting and additional reports could be added later.
>
> Yes.
>
>> Also there are several ways such a module could be made to happen.
>> One would be through sponsored development, and the other could be
>> through coordinated contributions of code.  Right now I am busy enough
>> getting 1.3 out the door that I'd just as soon get code contributions
>> than financial ones (need not be Perl, since 90% of the work is likely
>> to be db design and stored procedures so anything which gets us closer
>> to those is helpful).
>
> I could start coming up with database elements as soon as we agree on the
> nature of what we need to track.
>
> I am toying with the idea of writing my own UI in PHP, in order to develop
> and test the database routines.  PHP, because I can do it from extant
> knowledge, without having to research how to do it in PERL, which I haven't
> done in ten years or so, and because it can be simpler than what the real UI
> would need for LSMB.

We can trade ideas back and forth between TT and PHP.  No problem.  If
this was done right, the actual UI templates and db layer would be 90%
of what's done.  The actual PHP logic code and the Perl code would be
pretty thin glue and pretty interchangeable.

The big differences between TT and PHP are likely to be the way we
handle inputs.  We have utility functions that generate them in a
consistent way to help ensure better HTML.  This is not hard to
convert though back and forth.

Best Wishes,
Chris Travers