Manually entering starting positions - advice please!

[tjhughes72]

Hello Mark,

I'm tracking several portfolios (some of which have investments in multiple currencies) using FM Pro v11 and I'd like to get your advice on how best to enter starting positions.

It isn't going to be feasible to build the portfolios up from the very first transaction; some of them are years old and have hundreds if not thousands of transactions (I have the gimp's job...). I'd like to just enter the current holdings - so current holdings of cash, stocks, bonds and so on.

I'm using your "Transfer In" dialog box a lot. I'm using today's date as the transferred in date and entering X number of shares. I haven't bothered with a market value as I'm figuring that the sstem can work this out from an up to date price.

What should I do about OOP Cost Value? I don't understand how this will be used. Also on the Tax Cost Basis section - I'm entering the book cost of the investment but I am leaving the date as of today.

For example: let's take BHP Billiton (BLT.L)
- I have 1,550 shares - so I'm entering in 1,500 shares transferred in on 10 May 2011.
- I have left Market Value and OOP Cost Value blank.
- In the Tax Cost Basis section I am putting in 10 May 2011 for Date Acquired and £29,837.66 in Value.

I also update the Price with today's price: so £24.49 per share.

This seems to show all the right numbers - so I have 1,550 shares worth £37,959.50 with an unrealised gain of 27.22%

But I'm a bit worried that in the future I'll wish I had somehow worked something out for OOP Cost, Market Value etc. and put in the correct dates (although not always possible for investments built over time in more than one transaction).

Could you please let me know if my approach is basically OK and what are the shortcomings?

Many thanks,

Tom.

[Mark]

Hi Tom,

By leaving the Market Value and OOP Cost blank, you are entering them as 0. This means that if you want to report back to the date of this transfer, your starting points will be 0. For instance, the ROI uses the market value of your transfer in to determine your return. If you just do an ROI for a starting term after the transfer, it won't matter, but if you want it to include the date of the transfer, it will matter. Your ROI will look very high, since you started with 0. Similarly for OOP, if you report on OOP gain since inception, your OOP cost is 0, so your gain will be very high. By leaving the tax cost basis date set to today, the only problem with that is if you want to determine long/short for your capital gains. This long/short determination is based off the sell date, and the acquisition date, which you're setting to today. Since you are entering your tax cost value, your capital gain/losses amounts will be fine, but they may be incorrectly reported as short term, since you are entering today's date instead of the actual date they were purchased.

[tjhughes72]

Hi Mark,

Many thanks - both for the reply and the speed at which you replied!

OK, I think I understand the limitations of what I've done. It sounds as if reports on performance on or before the transfer in dates won't make sense as, understandably, there's no accurate cost data or dates. Am I right in thinking though that for dates going forward I should be OK?

I am running Excel spreadsheets in parallel to summarise historic performance so hopefully I should be OK....

Finally I don't "get" OOP calculations - I don't see why this is different from actual cost base. If you could enlighten me on that I'd be very grateful (or should I post this as a new topic in a new thread?).

Thanks,

Tom.

[Mark]

Hi Tom,

Yes, as long as you don't care about performance on/before the transfer in dates, going forward you would be fine. You own the correct number of shares.

OOP stands for "Out Of Pocket", and is similar to your tax cost basis, but it differs in that received distributions lower your OOP cost basis, but not your tax cost basis. The OOP basis is meant to help you understand your overall break-even point. You might want to read this:

http://www.fundmanagersoftware.com/help/def_oop.html

[tjhughes72]

Thanks for confirming that my calculations should be fine going forward.

Thanks too for letting me know about OOP.

Cheers,

Tom