Home Quicken for Mac Product Releases and Announcements: Mac

Quicken for Mac 2018 v5.4.x Released

1457910

Comments

  • RickORickO SuperUser ✭✭✭✭✭
    edited December 2017
    rangersix said:

    I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

    image

    Count me as three. Leave it as it is. If I was inadvertently not sorted by date and relied on the running balance to make a decision about spending, it could lead to an overdraw disaster.
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • Snoopy FCSnoopy FC Member ✭✭✭✭
    edited December 2017
    Just downloaded 5.4.4.  No issues so far.  Just waiting for more updates on issues I've raised previously.  
    QMac Subscription - iMac - Quicken Mac user since 1995
  • Snoopy FCSnoopy FC Member ✭✭✭✭
    edited January 2018
    jacobs said:

    I'm happy to see the ongoing incremental improvements in reports, but I continue to be frustrated with the report architecture that displays/prints subtotals on TOP of the data it totals. This is unlike any financial software I've ever used, and the reports are therefore unlike any financial reports I've ever read. Marcus, I hope moving subtotals below data (or at least an option to do so) is on your development roadmap. 

    Amen! Amen! Amen!
    QMac Subscription - iMac - Quicken Mac user since 1995
  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Interesting times with the release of the Canadian version...Thx.

    I posted the following questions here (before these notes), but you have more or less answered the first 2 from that list in your notes. I am posted the rest of them here:

    • 2. So essentially the CA version is just the US version with US specific features turned off, based on the Home Currency? Or is there more to it?
    • 3. Does the CA "version" of QM2018 include the ability to download from US FI/Banks?
    • 4. The US version of QM2018 includes ability to download from CDN FI/Banks. Will this continue to be true?
    • 5. The footnotes indicate that Quicken Mobile only works in Canada. Is this a unique version for Canada? Does it not link to US accts?
    • 6. I also see that Quicken Mobile is listed to only work with QM2017 and later but the US site lists it as working will all versions of QMac...is there a different versions of QMobile to work with QM2015 and QM2016?
    • 7. Is Premium support not available for QM2018 CA like it is for the US? After all, they are effectively the same product (the CA version having reduced functionality)?
    Thanks so much for the clarifications. And it is very good news that 2) is being preserved for both countries in one product.

    Sounds like the direction you are leaning regarding US vs CA features is to turn on all for US or only a subset for CA based on initial default, then allow user to turn on ALL if they so choose. I suggest another option would be to default features based on original country but then allow turning on other features one at a time on a needs basis. Consider that some user's needs change...start in one country then move to another for a period (or indefinitely) and so their needs may vary over time...Not sure if this option is better or not...just food for thought.

    There are not that many features that are unique to Canada: account types (many mostly just in name), tax categories, but the biggest difference is around taxes themselves...category links to tax lines, the way gains and loss are tracked and/or calculated, and mortgage calculations.
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • jacobsjacobs SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.The key thing is that the way Quicken 2007 works doesn’t create problems with my investment data, where Quicken 2015-2018 does. A transaction confirmation or monthly statement from my financial institution tells me the number of shares, share price, and total dollar amount of every transaction. The modern Quicken accounts for rounding by changing the share price based on the total cost and number of shares. So the share price is *wrong*. It’s only off a tiny bit, but it’s wrong. I didn’t have this problem in Quicken 2007, because I could use the commission field when needed to account for the penny or two of rounding, instead of Quicken making up a bogus share price.
    QMac 2007 & QMac Subscription • Quicken user since 1993
  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Ultimately, one of the fields HAS to be made wrong to account for rounding issues but price is a real thing determined by the markets and should not be the one...I agree that using the commission field has worked well in being the least of evils while at the same time preserving the accuracy of the shares and account balance.
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • UnknownUnknown Member
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.So how can we get Quicken to change something so that the QM2007  transaction total is respected?  I have no idea how to bring this to their attention, and I won't start using QM2018 until this is fixed.
  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Well, at the moment, there is this thread that seems to still be monitored by Quicken Marcus. Then there are the avenues I mentioned above at this post.
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • RickORickO SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.@smayer97... I disagree. Price is the dependent variable of the three. You spend X dollars to buy Y shares of the stock. X and Y are fixed amounts. The price is X/Y, is a derived value at the transaction level. (It does not have to be exactly the same number as the market. In fact, the price on the market varies continuously throughout a day.) This is not to be confused with Market Value, which also a derived variable, the product of shares owned times Market Price. Bottom line, don't confuse Market Price with Purchase Price. They are two different things. The former is a primary variable, the latter is a derived/dependent variable.
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Ok...I can see your point...but does QM2018 preserve buy and sell price to accurately calculate gains/losses or are these also rounded?

    Of course, the greater issue is how do users migrate their data over from QM2007 with the current set-up as it is triggering changes in the account balance and therefore creating discrepancies?
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.To add to that, how would reinvested dividends reported by brokerages be handled (or other similar situations), because this affects cost basis, based on the brokerage's reported price? Unless QM2018 has a way to handle this while preserving the reported price?
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • RickORickO SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Last one first: price has nothing to do with basis. Basis is the dollars spend for the stock. Here again, price is the dependent variable and price per share is not relevant to cost basis.

    On the earlier point, gains/losses, market price is relevant to unrealized gains/losses, which are only an estimate based on whatever time that market price was captured. IOW, unrealized gain/loss is market price times shares minus total cost. Note that there is no price involved in the 2nd part of that formula. 

    Realized gains/losses on the other hand have nothing to do with price. Realized gain/loss is proceeds minus cost. No price involved at all.

    As far as why things get messed up in the conversion from QM07 to QM18, I don't have any idea. 
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Am I missing something? Is TOTAL COST an entered value in QM2018? If so, then I see the disconnect...because in QM2007 TOTAL COST is a CALCULATED field based on PRICE, therefore, preserving PRICE becomes hugely important to get the correct TOTAL COST/PROCEEDS, which affects all the other values...cost basis, realized gain, etc. If it is calculated, which is what I believe, this means the problem is in how QM2018 calculates it...

    The problem with import is summarized in Scott Schmidt's post:
    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    So, does QM2018 have a commission field or are there only the 3 fields, price # shares, total cost?
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • UnknownUnknown Member
    edited December 2017
    rangersix said:

    I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

    image

    Hi Marcus,
    I'm not sure what you mean by the sort order. I can sort by date and yes the column does appear in the header. The one user who stated "if it ain't broke don't fix it". It's broke! I enter all my transactions in my checking account and I put in future reminders for bills coming up for the next month. The balance is important because I need to  know how much money I"ll need to pay bills in the future. I was using a calculator which is ridiculous.  I have 6 other checking accounts and all the balances show. I've been using Quicken since 1994. I recently changed to Mac this year. There are other problems that I'm not going to mention. The copy and paste problem is a pain because I have to duplicate the transaction then I have to drag it into another account which is more clicks and movements compared to copy and boom paste. One movement instead of 5.
    Also, when I reconcile my checking account it doesn't ask for interest for the month and it doesn't have a box for bank fees so there's a balance adjustment and the end of the reconciliation instead of interest for the month.  There are other issues. The program is not near as refined as the windows program. I updated from windows 2013 and that program doesn't have a cl itch  in it. I use to be able to search reports in a second by going into "memorized transactions". Now creating a report is laborious to say the least. I'm sticking with this program because Mac computers blow away PCs. Bill Gates just never figured it out regarding viruses and windows slowing down because of malware etc. Then you put a virus program in your computer and it turns into a snail but I appreciate the response. I opened a new checking account and the balance works in that one as it should so I'm good. If by chance you find out why this happened it would be great but it's broken and needs to be fixed. It's only with one checking account. All my other accounts work so maybe it was the conversion process when I switched over to mac from a PC. Cheers!
  • jacobsjacobs SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Yes, there is a commission field. But using it isn’t as useful as it was in QM2007. In 2007, entering a penny or two as commission got the total cost field to the correct value, but there was still some hidden fractional rounding taking place. In QM2015-2018, you can add or subtract a penny of commission, but the share price is still going to be calculated to 6 decimal places, even though the FI only may show 3.


    RickO: you’re right about intraday stock prices, but rhat’s not the case with mutual funds. If Vanguard says I bought or sold a fund at $30.25, that should be what I record in Quicken, not the calculated $30.249326 that Quicken might show.


    Further, while I agree with you about cost, not price, being used for calculating gain/loss when selling a specific lot of a stock, I wonder how Quicken calculates average cost per share when selling shares otherwise; are you sure the purchase/sale share price is never used in any calculation anywhere?
    QMac 2007 & QMac Subscription • Quicken user since 1993
  • ZoolookZoolook Member ✭✭✭
    edited January 2018
    When are you going to fix the multi-currency migration issue we spoke about at launch, and when is Quicken Mac going to have useful reporting? It’s a very expensive product to only have basic list reports - almost every other Mac based financial management application has far superior reporting.
  • brucelbrucel Member ✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Cost basis, including commission, and total number of shares are all that matter for tax filing regardless of the equity type (stock, mutual fund, etc).  Capital gain/loss = total sale price - total cost.  So I enter the exact total cost and the exact total number of shares for a trade and let Quicken solve for the per-share share price.  The slightly arithmetically adjusted per-share price is benign to the accuracy required for gain/loss analysis and tax filing because you use total cost and total shares per lot to report cost basis.  I have been tracking trades like this in Quicken for Mac since 1991 without any tax filing issues or performance analysis issues.
  • RickORickO SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.@brucel... exactly!

    @smayer97... YES, total cost is an entered value in QM18. So is number of shares. The price is calculated from these (and commission). In my view, this is the only way it should be done. As I've been saying, price is the dependent variable and just doesn't matter. It can float around and does not affect basis, or realized gain/loss. 

    If QM07 did it a different way (with Cost as the dependent variable), I don't remember. After all, it's been 3+ years since I used QM07 and I barely remember what I had for breakfast. :-) But I would have to say that if that's how it did it, no wonder there are rounding issues that come up.

    Here's an example from QM18. Note that the Price field is grayed out. You cannot enter it; it is calculated for you. $100 dollars of cost divided by 5 shares results in a price of $20 per share. (That price does get saved in the price history for the stock when the transaction is saved.)

    image

    Now if we add a $5 commission, that means that we actually only spent $95 ($100 minus $5) on the stock, and therefore the calculated share price is $19 ($95 divided by 5):

    image
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • ConcordmanConcordman Member ✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.That is exactly the way I see it, I enter the total cost of the transaction , then number of shares, & the commission. QM then calculates the price of the purchase which matches what my Fi shows for the share price.
  • RickORickO SuperUser ✭✭✭✭✭
    edited January 2018
    rangersix said:

    I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

    image

    Paul, the discussion above is about whether the balance column should be populated when the register is not sorted by date. Our position is that the balance column should be blank when the register is not sorted by date, because really, the balance is not meaningful in that case. 

    For example, what if I sort the register by check number? Then I look at the balance next to the last check I wrote. Does that balance have any resemblance to how much money I have in the account on that date? NO, it does not. Why? Because there may be other transactions in the register interpreted chronologically that don't happen to have check numbers. Therefore, the balance column is essentially nonsense when the register is not sorted by date.

    So when we say "if it ain't broke, don't fix it", we mean that the existing rule that the balance column is blanked out if the register is not sorted by date should remain in effect.

    ===============================

    Now, about your specific issue. You say you have one checking account that has a blank balance column. I will ask:

    1) Have you selected that one, and only one, account is the sidebar? (Not a group account, such as "Cash" or "Banking".)

    2) Is the Balance column displayed (menu View > Columns)?. I believe you said above that it is.

    3) Are the filters at the top of the register set to All Dates, Any Type, Any Status? You should not see a Clear Filters button at the top of the register.

    4) Is the search field (upper right) empty? You should not see the small X at the right end as shown here (if you do, click the X):
    image

    5) Is the register sorted by Date? You should see a small triangle next to the word Date in the date column header:
     image

    If all five of these conditions are met, and the balance field is still blank, then there is certainly something broken with that one account in your particular file. Why, I don't know. It is certainly not something that is pervasive as yours is the only such report I've seen. And if it was a glitch in your file, you fixed it by creating a new account: problem solved. Probably not worth Quicken spending a lot of time investigating. But if they get more of the same reports, then I'm sure they will. 

    ================================

    And about copy/paste:

    Your method: 
    1) select the transaction
    2) menu Edit > Copy (or Command-C)
    3) click the destination account in the sidebar
    4) menu Edit > Paste (or Command-V)

    Four steps.

    My method:
    1) select the transaction
    2) menu Transactions > Duplicate Transaction (or Command-D)
    3) drag the already selected transaction to the other account
    4) click the other account in the sidebar (your cursor is already there).

    Hmmm, let's see... four steps. They are the same.

    Really not something to get very excited about for a task that you really shouldn't be having to do that often. There are so many other things that the developers can spend time improving other than this.

    And, by the way, if you want an even easier method... select the group register in the sidebar that contains both accounts. Then duplicate the transaction and change the account in the Account column from the source to the destination account.
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • RickORickO SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.
    RickO: you’re right about intraday stock prices, but rhat’s not the case with mutual funds. If Vanguard says I bought or sold a fund at $30.25, that should be what I record in Quicken, not the calculated $30.249326 that Quicken might show.
    @jacobs... Say you have a transaction for a fund where your account's cash balance was debited $3,100.00 for the buy. In that transaction, you acquired 105.0000 shares of the fund. The calculated share price is 29.523809524 (rounded to nine decimal places). Vanguard might report to you that you bought at a share price of $29.52, but that was not the real (exact) price per share. If it were, then your account should only have been debited $3,099.60, not $3,100.00. What I'm saying is that the cost and the shares are fixed at the transaction. The price reported has to end up getting rounded at some level, but it just doesn't matter how the price is reported if the other two are correct.
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • UnknownUnknown Member
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.Total amount of the investment transaction and the total shares are the only amounts that really matter...and it's been that way in Quicken for almost forever.

    Even in Quicken Windows (and Quicken Mac), you should always let Quicken calculate the price per share...always enter the total cost and number of shares.

    Rarely does Quicken's price, expanded to eight or nine places, coincide with my investment company's statement.  And that's not Quicken's fault.  Even my investment companies round their price per share (or price per unit) so that it rarely agrees 100% with Quicken's calculation.

    Personally, I don't really care.  The following day when prices get entered, the total is usually within a few cents of what's really there (most days it's spot on).

    And since most of us use our investment companies 1099's for tax reporting anyways, what difference does it make?
  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited January 2018
    rangersix said:

    I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

    image

    @Paul Treppedi re: 
    ...when I reconcile my checking account it doesn't ask for interest for the month and it doesn't have a box for bank fees...
    You can add your VOTE to Add ability to add service charge or interest during start-up.

    First, click on the underlined link above to go there, then click VOTE at the top of THAT page, so your will vote count for THIS feature and increase its visibility to the developers by seeking to have the features you need or desire end up in the latest version.

    While you are at it, you may want to add your VOTE to related IDEAS found on the Click on each underlined link, then follow the instructions to add your vote to more related ideas. Your VOTES matter!

    (If you find this reply helpful, please be sure to click "Like", so others will know, thanks.)
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.The issue is not so much about how QM2018 does it but rather what the OP has raised...how to migrate reconciled and balanced amounts from QM2007 into QM2018. As it stands, discrepancies result due to the differences, at least for this user. 
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • smayer97smayer97 SuperUser ✭✭✭✭✭
    edited December 2017

    Can this be FIXED soon?

    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.
    You are correct. But it doesn't take an "incorrect" share price to trigger the problem.

    When entering investment transactions in Quicken 2007, number of shares, share price, commission, and total cost are equally important. Enter any three numbers and Quicken will calculate the other value. 

    And, Q2007 will accept a transaction if the math works with rounding. For example, consider a mutual fund purchase of $5,000, where the closing NAV was $48.74. The mutual fund company will take $5,000 divided by $48.74 equals 102.5851, which the fund company rounds to 102.585 shares. Quicken would allow the transaction to be entered as Buy 102.585 shares at $48.74, for $5,000 total.

    In Quicken 2016 and later, the share price is a derived field: transaction cost divided by number of shares gives the share price, to 6 decimal places, far more than the stock market actually supports. In Quicken 2018 you can't even enter the share price in a transaction. If the above transaction were originally entered in Q2018, it would calculate $5,000 cost divided by 102.585 shares equals $48.740069 share price.  

    What is happening on the import is bizarre:
    1. The import completely ignores the total transaction cost that was entered in Q2007.
    2. It calculates a new, bogus total transaction cost: number of shares times the share price that was in the Q2007 transaction.
    3. Then it takes the total transaction cost that it fabricated, which may not match the actual transaction, and uses that to derive a new share price: total transaction cost divided by number of shares, to 6 decimal places.
    In the example above, it would first calculate a transaction cost of 102.585 shares times $48.74 equals $4,999.99. Then use that to derive new price: $4,999.99 divided by 102.585 is $48.739972. Which isn't even the share price that the same transaction would calculate if it were originally entered in Q2018!

    The major error here is that Quicken is forgetting that total cost should be sacrosanct on the import, since that's what determines your cash balance. So if you have an account with a lot of history, the errors accumulate, until the account balance is wildly off.

    I have reported this bug to Intuit, and now Quicken, on every beta test since the new Quicken started supporting investment transactions. It is one of many data loss issues that are blocking me from upgrading.@RickO
     ...and I barely remember what I had for breakfast...
    lol...so true sometimes...
    Have Questions? Check out these FAQs:COMPLETE list of Product Ideas - Quicken for Mac to VOTE on

    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


    (
    Canadian Q user since '92, STILL using QM2007)

  • John MorrowJohn Morrow Member ✭✭
    edited April 2018
    I can't figure out how split works. I've read the manual, I think I understand the theory, but in practice it seems to work in creative ways whose logic I cannot understand.

    EXAMPLE 1
    1. Create a new transaction
    2. Enter a category, for example Gift (this is the season) and an amount, for example -100,60
    3. Click Split
    4. Go to the second split line (it is empty)(the first line is the Gift of -100,60)
    5. Enter a category, for ex. Transfer, then an amount, for ex. -39
    6. The total is changed to -139,60, WHICH IS NOT want I want or assumed. My expectation is the total would keep constant and the first Split line would become -61,60

    7. If I delete the first Split line, or the Second, or both, things get weirder. Sometimes QM asks me if I want to adjust the total, sometimes not. I cannot understand the logic between the two different behavior. 

    So I tried this instead:

    EXAMPLE 2
    1. Create new transaction
    2. Don't enter a category or amount, but to directly to the Split screen
    3. Enter Transfer and -39 on the first Split line
    4. Go to the second Split line. But I know only the total of -100,60, NOT the difference (-61,60) ! (and I don't want to compute it)

    The behavior that I am expecting is as follows:
    1. Create a new transaction, enter the total (which I know from the receipt), for example -100,60
    2. Go to the first Split line, enter an amount, for ex. -39 (which I read from the receipt also)
    3. Go to the second Split line, enter a second amount, for example -10 (which I read from the receipt also)
    4. Automatically, the third Split line is changed to -51,60 (= -100,60 - 39 - 10) (which I don't know for the receipt because it is a sum of many small items, which I don't want to compute manually. Using the diff is much faster)
  • UnknownUnknown Member
    edited January 2018
    rangersix said:

    I just upgraded to Quicken for Mac 2018 v5.4.x and now I get this error all the time. This account does not to be updated it's just the value of my house and I input that manually.

    image

    Oh! I fixed it:)

    My account was sorted by date but the balance still wasn't showing so I removed it from the columns by clicking it in the "show registry columns". Then I clicked sort again in the date column and re-entered it in the "show registry columns" WHALA! It's working. Thanks guys. I truly appreciate your help.
    On another note: It would be great if you could put the "memorized transactions" back in there. For me, it was the easiest way to search reports. I know there are other ways to search but it was really easy when I was able to go into memorize transactions and scroll in alphabetical order to a company and click REPORT! If not, I'll get use to this version.

    Happy Holidays!
  • John MorrowJohn Morrow Member ✭✭
    edited April 2018
    Reconcile no longer works for Credit Card accounts.

    STEPS TO REPRODUCE:
    1. Download transactions
    2. Reconcile
    3. Transactions just downloaded and cleared DO NOT appear in the reconcile window.

    This happens for 2 different Credit Card account. This used to work as of a few days ago. There is no such issue for Checking accounts. I am using QM 2018 5.4.4

    CREDIT CARD ACCOUNT:
    image

    RECONCILE WINDOW:
    image

    4 transactions are missing and cannot be reconciled.
  • UnknownUnknown Member
    edited December 2017

    Reconcile no longer works for Credit Card accounts.

    STEPS TO REPRODUCE:
    1. Download transactions
    2. Reconcile
    3. Transactions just downloaded and cleared DO NOT appear in the reconcile window.

    This happens for 2 different Credit Card account. This used to work as of a few days ago. There is no such issue for Checking accounts. I am using QM 2018 5.4.4

    CREDIT CARD ACCOUNT:
    image

    RECONCILE WINDOW:
    image

    4 transactions are missing and cannot be reconciled.

    Reconcile for credit cards works just fine.  I have zero problems with any of my credit cards reconciling in Quicken Mac.

    Try finding the missing transactions.  Or...the date of your statement ending date is incorrect.  What happens if you change it to 12/13/2017?
  • Quicken HaroldQuicken Harold Alumni ✭✭✭✭
    edited December 2017

    Reconcile no longer works for Credit Card accounts.

    STEPS TO REPRODUCE:
    1. Download transactions
    2. Reconcile
    3. Transactions just downloaded and cleared DO NOT appear in the reconcile window.

    This happens for 2 different Credit Card account. This used to work as of a few days ago. There is no such issue for Checking accounts. I am using QM 2018 5.4.4

    CREDIT CARD ACCOUNT:
    image

    RECONCILE WINDOW:
    image

    4 transactions are missing and cannot be reconciled.

    Splitting from a different topic.


    Please reference the new conversation here: Credit Card Reconcile Issues
    Quicken Harold
    Community Moderator
This discussion has been closed.