Re: Investment Addon

[Chris Travers <..hidden..>]

On Tue, Aug 9, 2011 at 1:13 AM, Luke <..hidden..> wrote:
> On Mon, 8 Aug 2011, Chris Travers wrote:
>
>> First I think this is a great idea.  However I have a few questions:
>
> Thanks.:)
>
>> 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).

>
> I think this might also apply to certain non-profits, although I'm not
> sure how big a segment that is for us.
>
> 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.

> Then again, maybe I'm wrong about how such entities handle these
> things--I've never invested as an individual or similar class, but always
> through corporate-like structures.

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
side, but it means additional functionality in tracking market prices
might need to be added at some point.
>
>> 2)  What new markets would we be able to reach by including such a module?
>
> The most honest answer I can give, is probably none.  This is more of a
> value added concept for existing or future users--I don't really see this
> as a decision point feature for someone.
> That said, if it's done well, and the other FOS accounting packages don't
> do something like it, it may be a decision point for someone who
> definitely has the intent to use such a feature extensively.
>
> At the moment, my business, and that of one of my customers, would
> definitely use such a feature, which prompted my proposal of it.

Ok, so along with Alvin's comment that makes three.
>
>  > Also if there are a significant number of users out there who would
>> benefit from it today, it might be possible to spread the effort
>> and/or cost around.
>
> I will be very interested in community response to this--how often do
> users in the SMB space, do any kind of investing with free or dedicated
> capital through their businesses which use LSMB?

I am also going to check with some of my customers when I have the chance.

>
>> If not, then what is the absolute minimum we
>> would need to do to make life just a little easier for folks who need
>> to track this sort of thing?
>
> I have spent the last two hours going through potential ways to answer
> that question.
>
> The problem seems to be that the absolute minimum, while it will work, is
> not scalable, at least not in the versions I've come up with.  By
> scalable, I should say that it can not be enhanced later, without
> requiring the user to re-input all associated data in a new form.

Here is my thinking:

Absolute minimum:

* Enter company info, positions purchased, position type, total stock
issued by firm, relevant gl accounts, and cost.  On sale enter
positions sold. relevant gl account and sellprice.  Generate GL
entries.
* Allow a simple report of investments and their purchase price.

Equity accounting and additional reports could be added later.

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

Hope this helps,
Chris Travers