Problem with share values/cost in transactions
I manually enter transactions into MD.
First off, prices are automatically downloaded when I open
MD.
Here is an example:
Automatic download of price shows Royce Premier Fund on 11/18/2011
as $20.04
My transaction data from the brokerage firm shows:
Purchase 1.888 shares
Cost $37.84
When I enter 1.888 shares and Amount is $37.84 the Price per share changes to 20.04237288 (mathematically correct but incorrect to price the value for reporting). If there is any money needed or too much money shown as spent then that amount should be automatically calculated and listed in the Fee cell. It is important to note that if one changes the price per share back to $20.04 then the amount invested changes (and is now incorrect). In this case that Fee should have been 0.004479997 (i.e. 1.888 X 0.00237288). Once all of the purchases are entered, these + and - values should equal to 0 (at least Quicken handled it this way).
One may say it doesn't matter. However it causes a significant problem as the erroneously calculated price is added to the Current Price field in the Securities information and thus is the price used for reporting.
Support Staff 2 Posted by Tom Freeman on 21 Nov, 2011 04:17 PM
Which version of Moneydance are you using. in Moneydance 2011 v 803, the price is set at the 20.04 and the current value carried out as such. Which is different from a current price of 20.04237. I've attached a screen shot illustrating such.
If you are using an older version of Moneydance please let me know and I will confirm on that version.
Tom
3 Posted by rgwilson on 21 Nov, 2011 05:23 PM
using MD 2011 803 on a Mac
I didn't check that window. I was looking at the at the other security window where one can see the dates and pricing (currently at work so I can't tell you how to get there).
At any rate, you did not purchase the shares for $20.042373 per share which shows up in the Current Price window in the other securities edit window. The price that shows up in the Securities edit window is supposed to be the price used for reports per another thread here:
http://help.infinitekind.com/discussions/bugs/399-incorrect-current...
I assume the screen shot you posted is using the Historic price which would be 20.04 (downloaded price). Per the thread above Historic price and current price can be 2 different values and may be why some users are seeing different values on different reports.
Support Staff 4 Posted by Tom Freeman on 21 Nov, 2011 05:35 PM
I am going to query the lead developer about decimal placement and its relation to reports. I know this has come up in on a variety of issues.
Tom
5 Posted by rgwilson on 21 Nov, 2011 05:57 PM
That won't really help. It needs to be consistent at using Current Price and Current Price needs to be actual price for the day not the calculated or discounted purchase price.
I have some stocks that I purchase at a discount (ex. Daily stock price downloaded $7.00 but purchase at $6.50). If the Current Price in the other securities window is set to the $ amount I bought the stock at then the reports will be wrong because the shares are actually worth more.
For the previous example the $ per share for Current Price and Historic Price should be $20.04 and any rounded amount should be credited to "Fee" so that when all of the transactions are entered the Fee will total to 0 and all the shares would be purchased at the correct price and the Current and Historic prices will match.
6 Posted by rgwilson on 26 Nov, 2011 03:18 PM
Did anyone read / note my comment above?
7 Posted by zeke on 28 Nov, 2011 01:10 AM
Hi
I'm not really clear on the issue. If I buy shares w/ a given amt of money I want the share amounts as reported by the seller and money spent to be correct. If those quantities are forced to be exact there will almost always be round-off effects in the calculated share price. This is inevitable when you carry only a fixed number of decimal places in calculations. This is the same behavior that occurs in quicken to my recollection.
8 Posted by rgwilson on 28 Nov, 2011 02:33 AM
When you purchase shares of several stocks/funds say in a 401K, the broker will use exact cents (rounded to .01) to purchase the shares at the share price (also exact to 2 decimal places). However they will sell you shares at up to 3 or 4 decimal places (1.888 as noted above). When all of your different funds are purchased, the cents over and under will equal a total of 0.
Quicken handled this by using the exact amount per share as shown on your statement and the exact number of shares from your statement but the extra cents were either + or - in the Fee column which will add to 0 when all purchases were entered so you really didn't pay a fee and did purchase the number of shares the statement indicated at the total cost the statement stated.
At any rate, MD uses the calculated cost (20.04237288 in the example above) as the Current Price of the shares. Current Price is used for reports so if you want the total value the day you purchase, it will multiply the number of shares by the incorrect price of 20.04237288 .
Likewise, using the price you enter at time of purchase for a stock bought at discount ($6.50 in the example above) as the Current Price will cause your report for that day to show all shares are valued at $6.50 instead of the $7 market value that was downloaded. At least in my data file it works this way.
9 Posted by zeke on 29 Nov, 2011 12:22 AM
rgwilson
I'm not sure what Quicken an/or your broker are doing, but putting round-off errors into an artificial "Fee" is basically using a fudge factor to make things "look right". I buy mutual funds directly from the source, and in your example, the fund company would charge me exactly $37.84 to buy exactly 1.888 shares. So in actual fact the "correct" price/share is $20.04237288 (actually this is a round-off too) for that transaction. This is the kind of number I remember when entering such transactions in Quicken, but maybe it treats mutual fund accounts and broker accounts differently. That being said, it does not seem correct that MD should simply grab that price to use in a report of value, since as I think you said, prices are only quoted to the penny, and you're not going to get that $20.04237288 for your shares. I think MD probably uses the exact price (i.e. $20.04237288 in your example) of the last transaction when calculating value if that is the last price it sees (i.e. if you haven't downloaded another price or manually entered one). I agree (If I understand your argument!) that MD should always round the price/share in reporting value.
10 Posted by rgwilson on 29 Nov, 2011 01:15 AM
MD shouldn't round prices for reporting - it should use the downloaded price which is always to 2 decimals. If the above calculation came to $20.0450009 it would incorrectly round to $20.05.
We are talking about small values here. However, I still think that if the statement says 1.888 shares at $20.04 was the cost, then MD should agree and show 1.888 shares and $20.04. The Fee column could house the fractions of a cent (+ or -) to keep the total invested and price per share correct. This Fee column in MD correlates to the Commission column in Quicken. This transaction in quicken shows 1.888 shares, $20.04 per share, cost $37.83, Commission -0.01 (Still $37.84 spent) but the shares and cost per share matches the statement. Other transactions show + & - 0.01 but when all transactions are entered the cash balance is 0 because the cents add to 0 thus also indicating that there wasn't a commission.
My point was that if MD needs to use the price when shares are purchased to determine prices for reporting then the price should be correct and if necessary do as Quicken does and manipulate the excess or shortage since the $ spent should match the broker statement.
I still have an issue with using the purchase price in the account register for reporting since shares bought at a discount cause further issues and those reports are way off.