[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Investment Addon

On Tue, 9 Aug 2011, Chris Travers wrote:


On Tue, Aug 9, 2011 at 1:13 AM, Luke <..hidden..> wrote:

On Mon, 8 Aug 2011, Chris Travers wrote:


1)  What segments of users are most likely to benefit from this?


Interesting.  I'm not sure, actually.  Not even sure how you define
segments, but I'll take a stab.

Any business that stores standby capital in trackable security
instruments, be they stocks, bonds, mutual funds, or even CDs.
Basically, anyone who stores money or invests money, in a way which can
not be tracked by holding it in a cash account (savings, money market),
and applying interest to some income account.


Ok, so basically we are talking about any business which stores money
which are not cash equivalents (i.e. very short-term bonds would be
cash equivalents, ones maturing after 30 days or more would not be).
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. 


To my knowledge, which is admittedly limited, the methods discussed in the
article I referenced (cost or equity), only apply if you are some sort of
corporation or corporate-like entity.  It may be that individuals,
partnerships, and soul pros would have to handle this differently, and
this would not be a useful module for that class of user, except as a
tracking device.  I.E. the tracking of events or values might be useful,
but the resulting asset account would not.


I can't imagine it being different for sole proprietorships.
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. 


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.:)


side, but it means additional functionality in tracking market prices
might need to be added at some point.
I had assumed that somewhere down the road, that might be a good idea, although I'm not sure what free data feed services would be available. 


Here is my thinking:

Absolute minimum:

* Enter company info, positions purchased, position type, total stock


What do you mean by type?


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

It should provide, either initially or eventually, for recording:
* Dividends
* Selling 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. 


* 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. 

Luke