Screen shot of Lot-Matching window. I enlarged the window, but only the first five (5) lots are displayed. My guess is that there is a bug that computes the number of lines to display based on the original display area (which is shorter.) Changing the window dimensions does cause the information to be re-displayed, but probably the calculation for the number of items is not correctly updated. Also, normally when there are more items to be displayed that will not fit, scroll bars would normally appear. (I used to be a programmer and back-line support at Sun Microsystems.)
Securities Detail correctly displaying all transactions:
I will attach screen shots rather than add them in line. Well, I guess the e-mail client still inserts rather than append.
I added a bunch of spurious "sell" transactions. Note that there are ten (10) available lots to match.
The default-size Lot-Matching window does indeed display scroll bars for both the sell transactions and the available lots.
If I scroll the available lots, only 5 are displayed even though there are actually ten (10). You can get an idea of how many transactions there are by the length of the darker area in the scroll-bar. The "shares sold" scrolls correctly to display all of the transactions.
When I enlarge the window to accommodate additional transactions, here is the result:
All of the sell transactions are displayed, but only the first five (5) of the available lots are displayed. In case this shot does not appear in the e-mail, here is another of the same thing:
I have a suspicion that the maximum number of available lots display will not exceed five (5). The "Total" and "Shares Remaining" parts of the window allocate space on the window.
To reproduce the problem, add or duplicate a number of available lots ("buys") so that there are more than five (5). Try re-sizing the Lot-Matching Window and watch how the window is re-drawn, including the scroll bars.
I agree that if I select (click) on the last "sell" txn listed in the left column of the Lot-Matching Window, then all of the available unassigned lots prior to 08.07.2012 SHOULD be offered. The following screen shot indicates that is not the case. Note that I have enlarged the default window in order to display all of the transactions without the need for scroll bars.
There is no way to have more than five (5) available lots to be offered. As I previously wrote, to reproduce the problem, add or duplicate a number of available lots ("buys") so that there are more than five (5). Try re-sizing the Lot-Matching Window and watch how the window is re-drawn, including the scroll bars.
I can't say for certain but this behavior may be due to creating
the unrealistic situation of owning negative shares.
Those last 8 spurious Sell txns do just that.
What lots are displayed when you click on the 8,519.032 Sell txn
I did a lot of research and found that when I set up a separate test account and entered all of the transactions and everything was OK. So I went back to my real account and deleted the two "Sell" transactions. I then re-entered the first sale and allocated the shares successfully. I then re-entered the second sale and this time all of the "buy" (actually dividend reinvestment) transactions were displayed in the Lot-Matching Window. I was then able to successfully enter the all of the amounts and the window "cleared" correctly.
So I think the root problem was that all of the transactions up to July of last year were actually imported from a Quicken file. That included a number of "buys" before and after a single "sell". Normally when a "Sell" transaction is entered, the Lot-Matching Window appears. Of course in this case that was "old" imported data so no window appeared. Entering the second "Sell" transaction this year is when the problem occurred.
If this problem re-occurs, I know what to do: delete all the "Sell" transactions and then re-enter them in chronological order. Each time the transaction is re-entered, properly allocate the shares. I think other people who import old Quicken files which have a mix of buy/sell transactions, but still have some shares remaining might run into the same problem that I did when at a later date they sell more shares.
You had piqued my interest with this issue. I too created a test
data file with your exact entries and like yourself, was able to
successfully lot match the Sells to all the Buys.
I think that we can chalk this up to the nefarious .QIF file
format. From what I've read on these forums, the .QIF file format
was never intended for data transfer. It was a troubleshooting tool
for Intuit techs. There are variable standards for creating them
which exacerbates the problem.
With so many different .QIF variations to contend with, I doubt
that this is a solvable dilemma. It's something that will have to
be logged and looked out for.
Thanks for posting back with your findings.
As the OP, you can close the thread by clicking the 'Close this
Discussion' link in the upper right-hand corner of this thread.
I think that you should put in the knowledge base for those who import Quicken (.QIF) files to manually check for buy/sell share transactions. The US no longer allows the "averaging" method for computing income taxes, only the lot-matching method. People may have old data that needs examining. (Like I did.)
It is easy to look at the "security detail" to view all of the transactions for a particular security. With a screen snapshot of the details, Delete the "sell" transactions and re-enter them one-by-one, each time going through the Lot-Matching Window. Trust me, when you have 20 such transactions it seems like a daunting task. But in reality it is easy to rectify.
I think that you should put in the knowledge base for those who
import Quicken (.QIF) files...
I agree wholeheartedly that there should be a knowledge base
article that points out the quirks, problems, errors, etc that
having different variants of .QIF file format can cause.
The extent of this problem runs deep in that different versions
of Quicken create different versions of .QIF files. Someone like
yourself who may have imported from Quicken 2008 may experience the
problem that you encountered whereas someone who imported from
Quicken 2005 or 2010 may not. It's a bit of a crap shoot when it
comes to .QIF files.
Full disclosure: I have no affiliation to Moneydance, Moneydance
Support or help.infinitekind.com. These forums although actively
monitored by the MD Support Staff are also home to a knowledgeable
user base. I humbly include myself in the latter. :)
If I may make a suggestion, you should post to the 'Suggestions'
forum and link to this thread to point out that there is yet
another issue created by .QIF and that there should be a huge
mention of the problems related to .QIF files in the knowledge