Import of QM2007 Investment Transactions - Marcus Please Consider Fixing
Unknown
Member
I recently purchased QM 2018 and imported my data, including investment transactions, from QM2007. The account balances in almost all investment accounts did not match between the QM2007 and QM2018 files after import. I investigated, and determined that there is an inconsistency in the way data is handled that is causing this problem. Please let me explain.
When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.
I don't know why QM2007 doesn't consistently update the share price field, but it doesn't always happen. A better way to do the import is to import and use the QM2007 shares/$/commission fields and then calculate the share price. This method would eliminate the possibility of a faulty QM2007 share price from initiating this problem.
One workaround, of course, is to edit the transaction $ value in QM2018 after import, but in 20 years of QM2007 data, just finding all of these instances is a very large task.
Please review this issue and then consider revising the import code to eliminate the problem. The transaction amount needs to remain sacrosanct so that the cash balance is maintained. Thanks!
When entering QM2007 investment transactions, there are four fields that are entered in the register - number of shares, $ amount of transaction, commission, and share price. The share price is back-calculated from the first three parameters. Occasionally if one of the first three fields is edited during the transaction entry, the share price does not get updated properly and the transaction ends up being entered with this field having an incorrect value (i.e. it is not consistent with the shares/$/commission fields). This is no big deal because this share value doesn't seem to be used for much in QM2007.
However, when importing this faulty transaction into QM2018, the total transaction cost is calculated from the number of shares, commission, and the (possibly incorrect) share price. This results in the transaction $ amount being incorrect, and the account cash balance starts to diverge from that in the QM2007 register.
I don't know why QM2007 doesn't consistently update the share price field, but it doesn't always happen. A better way to do the import is to import and use the QM2007 shares/$/commission fields and then calculate the share price. This method would eliminate the possibility of a faulty QM2007 share price from initiating this problem.
One workaround, of course, is to edit the transaction $ value in QM2018 after import, but in 20 years of QM2007 data, just finding all of these instances is a very large task.
Please review this issue and then consider revising the import code to eliminate the problem. The transaction amount needs to remain sacrosanct so that the cash balance is maintained. Thanks!
Tagged:
2
Comments
-
Thanks for the suggestion.
Quicken user since Q1999. Currently using QW2017.
Questions? Check out the Quicken Windows FAQ list0 -
Thanks for the feedback. I hope that this can be corrected, since it really messes up imported account registers for investment accounts. Who wouldn't want the old and new balances to match? I have no idea if the Quicken folks will see this and act on it - I have posted it several times without any feedback, but I'm pretty sure thy would agree that how this works right now is not correct and should be fixed. The key is getting it to their attention, especially considering all of the other bugs and improvements vying for their time and attention. Fingers crossed...0
-
I'd argue that this is a bug more than it is a feature request -- and as such, it deserves to be reported to the developers, and fixed irrespective of the number of votes. Of course there are a dwindling number of Quicken 2007 users, and it feels like the developers are trying to out-wait those users so they don't have to devote time to an issue that affects a shrinking number of users. I'd argue that among those users are some of Quicken's most loyal users, who would love to update to the current Quicken Mac if only the developers removed some obstacles -- like this one -- which are holding them back from making the switch.
@Quicken_Natalie, rather than removing this "idea" post, it would be great if the moderator team could forward this to the developers. It's likely a fairly easy issue to fix, and would make upgrading to modern Quicken Mac one step easier for those who are still waiting.Quicken Mac Subscription • Quicken user since 19930 -
Agreed. Please fix.
Have Questions? Help Guide for Quicken for Mac
FAQs: Quicken Mac • Quicken Windows • Quicken Mobile
Add your VOTE to Quicken for Mac Product Ideas
Object to Quicken's business model, using up 25% of your screen? Add your vote here:
Quicken should eliminate the LARGE Ad space when a subscription expires(Now Archived, even with over 350 votes!)
(Canadian user since '92, STILL using QM2007)0 -
Hello All,
Thank you for taking the time to provide your feedback regarding this.
I have gone ahead and changed this Idea post into a Discussion, as it is technically not a feature request, but an issue that @Scott Schmidt1 personally experienced.
In order to get this reported as a bug for the developers to review, we would need to obtain replicable data displaying this specific behavior.
If anyone has anything to provide, please let us know!
Thank you,
Quicken Natalie
0 -
@Quicken_Natalie I'm a little confused by what you are asking for, as what Scott reported accurately describes a difference between the way Quicken 2007 and Quicken 2020 calculate the total cost of an investment transaction.
Are you saying you need an example of a Quicken 2007 transaction where the share price was not updated properly during transaction entry, and Quicken 2020 now uses the slightly incorrect share price to calculate a slightly different total cost of the transaction?
Here's one I was able to quickly find in my data. Here's a transaction in Quicken 2007:
It shows 712.61 shares at $17.07 with a cost of $12,164.26. (That's actually not quite right, mathematically; if you do the math, you'd come up with $12,164.2527)
Here's the way that transaction imported into Quicken 2020:
Notice that the new Quicken Mac kept the same number of shares, used a slightly different share price, and calculated a total cost of $12,164.25 which is off by 1¢ from the cost in Quicken 2007. As a result, my register in Quicken 2020 shows a 1¢ balance going forward from this date, where my Quicken 2007 register shows a $0 balance going forward.
Does that help?
I have a few other examples like this in my data, but because it's fewer than a dozen transactions, I think, it's not too hard for me to find and clean up when I import. But I don't as many investment accounts and transactions as some users do.
Maybe @Scott Schmidt @Scott Schmidt1 will see this and can come up with additional examples of a Quicken 2007 transaction differing in cost from the same transaction imported into Quicken 2020.
Quicken Mac Subscription • Quicken user since 19930 -
Hello @Jacobs,
Thank you for providing additional information and some examples regarding this issue.
If you'd like to assist in getting this potentially reported as a bug, we'd be happy to have you send us a few pieces of information that will allow us to provide the developers with replicable evidence of the way Quicken is processing this data during the conversion.
We would need an unconverted copy of a 2007 data file, as well as a copy of the converted data file, highlighting the specific transactions that the problem is occurring with.
Please let us know if this is something you'd like to help out with!
Thank you,
Quicken Natalie
0 -
@Quicken_Natalie I'd be happy to send both files and identify a few transactions where this happens during importing. I may not have time to get to it right away, but let me know how you want those files submitted and documented.Quicken Mac Subscription • Quicken user since 19930
-
Hello @Jacobs,
Thank you for your willingness to assist with this!
Once you have everything ready to go, you can either upload the files via a private message to me here on the Community, or I can email you a link for our Secure File Exchange.
Just let me know how you'd like to proceed!
Thank you,
Quicken Natalie
0
This discussion has been closed.