Record Vesting event always shows 0 net shares in R48.15
1) 'Net shares' is always 0
2) 'Account to receive shares' is a blank list
I am using R48.15, and this is the first time attempting a vest since the latest update. It worked fine in the previous version.
Any ideas?? I can manually work around it by entering the MiscInc, MiscExp, and XOut entries, but this is obviously not ideal
Comments
-
Yes, that one was driving me nuts, especially since I hadn't finished data entry on my historical RSU vesting after swapping everything over to use the feature (… right after it was released, then later removed from the base version, forcing an upgrade to home and business).
The workaround I was able to identify was locating the 45.18 patch and using it to downgrade my Quicken installation. I then performed the required RSU vests on my current dataset, and let Quicken upgrade itself once again. I'm hoping I won't need to repeat this experience by the next vesting date, but we'll see…
Searching Google for "quicken canada mondo patches" finds the download on an unofficial site, however after download you can click into the file properties to verify that the digital signature is official, with company name = Quicken Inc and the digital signature's timestamp lining up with when the 45.18 version was released.
1 -
Ah, cool, thanks -- glad I am not the only one! I will give that a try on next vesting event, as for now I did a manual entry. I located the files and checked the sigs for downgrading, which I assume is just running the prior 45.18 patch and it just overwrites everything?0
-
Have you used the Report a Problem feature that is built into Quicken to report this issue and/or discussed it with phone support? Occasionally the forum moderators will inform the development team of an issue discussed here, but you can't rely on that happening. Issues are more likely to get attention if there are many Report a Problem problem reports received.
1 -
Yes, @Arctic Hare I have reported it through "Report a problem" in Quicken. They won't respond individually of course, which is why I came here to see if I was the only one or not. Hopefully others are also reporting the issue, and that it will get fixed in the next release!1
-
Yes.
I'm not sure this method is safe or particularly likely to work for very long, but in this case going backward and forward a single version seemed to be fine with no apparent incompatibilities in the data.
I was reluctantly prepared to accept a few weeks of re-classifying transactions by restoring an older backup to get my last few years of RSU vesting all caught up but did not need to, in the end.
0 -
Still broken in r50.9.1
