Quicken Community is moving to Single Sign On! Starting 1/22/21, you'll sign in to the community with your Quicken ID. For more information: http://bit.ly/CommunitySSO

File Validate and Repair Corrupts XIn XOut and BoughtX Investment Transactions

Derek
Derek Member ✭✭
edited January 2019 in Investing (Windows)
Windows Quicken 2017 Home & Business Version R3 Build 26.1.3.4

It would be great if the Validate feature didn't break a functioning
Quicken file and ALSO fixed those files that have been broken by the bug in
the past.

Easy to reproduce.


You should run two Investing Quicken Standard Reports before and after step 4.

A. Investment Transactions Report (Customize and Display Show Columns: All)
B. Portfolio Value and Cost Basis Graph (Customize and Display Interval: Week)


The errors you will observe after corruption are:

I. XIn, XOut, and BoughtX transactions will not show cash values on report A as before.
II. The graph on report B will no longer be zero between 3/12 and 7/30.


Procedure to reproduce:

1. Start with a new quicken file
2. Be sure investing is enabled (create a dummy investing account)
3. Import the QIF file (see below)
    a. <All account>
    b. Include in import: Transactions, Account List, Security List
4. Menu File > File Operations > Validate and Repair ..., check Validate file, and click OK





QIF file for import (here to end)


!Option:AutoSwitch
!Account
NChecking
TBank
^
NBrokerage
TPort
^
!Clear:AutoSwitch
!Type:Security
NCisco Systems Inc
SCSCO
TStock
^
!Option:AutoSwitch
!Account
NChecking
TBank
^
!Type:Bank
D1/01'16
N
U0.00
T0.00
POpening Balance
L[Checking]
^
D1/02'16
N
U10,000.00
T10,000.00
PDeposit
LNet Salary
^
!Account
NBrokerage
TInvst
^
!Type:Invst
D1/01'16
NWithdraw
POpening Balance
L[Brokerage]
^
D1/29'16
NBuyX
YCisco Systems Inc
I23.50
Q100
U2,350.00
T2,350.00
L[Checking]
$2,350.00
^
D2/05'16
NBuyX
YCisco Systems Inc
I23
Q200
U4,600.00
T4,600.00
L[Checking]
$4,600.00
^
D3/04'16
NSellX
YCisco Systems Inc
I26.75
Q300
U8,025.00
T8,025.00
L[Checking]
$8,025.00
^
D8/05'16
NBuyX
YCisco Systems Inc
I31
Q100
U3,100.00
T3,100.00
L[Checking]
$3,100.00
^
D8/12'16
NBuyX
YCisco Systems Inc
I30.85
Q100
U3,085.00
T3,085.00
L[Checking]
$3,085.00
^
D9/16'16
NSellX
YCisco Systems Inc
I31
Q200
U6,200.00
T6,200.00
L[Checking]
$6,200.00
^
D10/01'16
NXIn
PTransfer
U1,000.00
T1,000.00
L[Checking]
$1,000.00
^
D10/05'16
NXOut
PTransfer
U250.00
T250.00
L[Checking]
$250.00
^
D10/20'16
NDeposit
PTransfer
U750.00
T750.00
L[Checking]
^
D10/25'16
NWithdraw
PTransfer
U-500.00
T-500.00
L[Checking]
^
!Type:Prices
"CSCO",18.64,"11/30'11"
^
!Type:Prices
"CSCO",18.08,"12/30'11"
^
!Type:Prices
"CSCO",19.645," 1/31'12"
^
!Type:Prices
"CSCO",19.88," 2/29'12"
^
!Type:Prices
"CSCO",21.15," 3/30'12"
^
!Type:Prices
"CSCO",20.155," 4/30'12"
^
!Type:Prices
"CSCO",16.33," 5/31'12"
^
!Type:Prices
"CSCO",17.17," 6/29'12"
^
!Type:Prices
"CSCO",15.95," 7/31'12"
^
!Type:Prices
"CSCO",19.08," 8/31'12"
^
!Type:Prices
"CSCO",19.095," 9/28'12"
^
!Type:Prices
"CSCO",17.145,"10/31'12"
^
!Type:Prices
"CSCO",18.91,"11/30'12"
^
!Type:Prices
"CSCO",19.6494,"12/31'12"
^
!Type:Prices
"CSCO",20.57," 1/31'13"
^
!Type:Prices
"CSCO",20.855," 2/28'13"
^
!Type:Prices
"CSCO",20.895," 3/29'13"
^
!Type:Prices
"CSCO",20.92," 4/30'13"
^
!Type:Prices
"CSCO",24.115," 5/31'13"
^
!Type:Prices
"CSCO",24.335," 6/28'13"
^
!Type:Prices
"CSCO",25.59," 7/31'13"
^
!Type:Prices
"CSCO",23.31," 8/30'13"
^
!Type:Prices
"CSCO",23.431," 9/30'13"
^
!Type:Prices
"CSCO",22.56,"10/31'13"
^
!Type:Prices
"CSCO",21 1/4,"11/29'13"
^
!Type:Prices
"CSCO",22.43,"12/31'13"
^
!Type:Prices
"CSCO",21.91," 1/31'14"
^
!Type:Prices
"CSCO",21.80," 2/28'14"
^
!Type:Prices
"CSCO",22.415," 3/31'14"
^
!Type:Prices
"CSCO",23.11," 4/30'14"
^
!Type:Prices
"CSCO",24.62," 5/30'14"
^
!Type:Prices
"CSCO",24.85," 6/30'14"
^
!Type:Prices
"CSCO",25.23," 7/31'14"
^
!Type:Prices
"CSCO",24.99," 8/29'14"
^
!Type:Prices
"CSCO",25.17," 9/30'14"
^
!Type:Prices
"CSCO",24.47,"10/31'14"
^
!Type:Prices
"CSCO",27.64,"11/28'14"
^
!Type:Prices
"CSCO",27.815,"12/31'14"
^
!Type:Prices
"CSCO",26.365," 1/30'15"
^
!Type:Prices
"CSCO",29.51," 2/27'15"
^
!Type:Prices
"CSCO",27.525," 3/31'15"
^
!Type:Prices
"CSCO",28.83," 4/30'15"
^
!Type:Prices
"CSCO",29.31," 5/29'15"
^
!Type:Prices
"CSCO",27.46," 6/30'15"
^
!Type:Prices
"CSCO",28.42," 7/31'15"
^
!Type:Prices
"CSCO",25.88," 8/31'15"
^
!Type:Prices
"CSCO",26 1/4," 9/30'15"
^
!Type:Prices
"CSCO",28.85,"10/30'15"
^
!Type:Prices
"CSCO",27.57,"11/20'15"
^
!Type:Prices
"CSCO",27.32,"11/27'15"
^
!Type:Prices
"CSCO",27.48,"12/04'15"
^
!Type:Prices
"CSCO",26.16,"12/11'15"
^
!Type:Prices
"CSCO",26.27,"12/18'15"
^
!Type:Prices
"CSCO",27.38,"12/25'15"
^
!Type:Prices
"CSCO",24.78," 1/08'16"
^
!Type:Prices
"CSCO",23.62," 1/15'16"
^
!Type:Prices
"CSCO",23.37," 1/22'16"
^
!Type:Prices
"CSCO",23.79," 1/29'16"
^
!Type:Prices
"CSCO",22.89," 2/05'16"
^
!Type:Prices
"CSCO",25.11," 2/12'16"
^
!Type:Prices
"CSCO",26.55," 2/19'16"
^
!Type:Prices
"CSCO",26.41," 2/26'16"
^
!Type:Prices
"CSCO",26.80," 3/04'16"
^
!Type:Prices
"CSCO",27.86," 3/11'16"
^
!Type:Prices
"CSCO",28.33," 3/18'16"
^
!Type:Prices
"CSCO",27.96," 3/25'16"
^
!Type:Prices
"CSCO",28.69," 4/01'16"
^
!Type:Prices
"CSCO",27.69," 4/08'16"
^
!Type:Prices
"CSCO",27.90," 4/15'16"
^
!Type:Prices
"CSCO",28.15," 4/22'16"
^
!Type:Prices
"CSCO",27.49," 4/29'16"
^
!Type:Prices
"CSCO",26.53," 5/06'16"
^
!Type:Prices
"CSCO",26.53," 5/13'16"
^
!Type:Prices
"CSCO",27.97," 5/20'16"
^
!Type:Prices
"CSCO",28.92," 5/27'16"
^
!Type:Prices
"CSCO",29.13," 6/03'16"
^
!Type:Prices
"CSCO",29.03," 6/10'16"
^
!Type:Prices
"CSCO",28.95," 6/17'16"
^
!Type:Prices
"CSCO",27 3/4," 6/24'16"
^
!Type:Prices
"CSCO",28.80," 7/01'16"
^
!Type:Prices
"CSCO",29.26," 7/08'16"
^
!Type:Prices
"CSCO",29.82," 7/15'16"
^
!Type:Prices
"CSCO",30.71," 7/22'16"
^
!Type:Prices
"CSCO",30.53," 7/29'16"
^
!Type:Prices
"CSCO",31.04," 8/05'16"
^
!Type:Prices
"CSCO",30.87," 8/12'16"
^
!Type:Prices
"CSCO",30.52," 8/19'16"
^
!Type:Prices
"CSCO",31.35," 8/26'16"
^
!Type:Prices
"CSCO",31.83," 9/02'16"
^
!Type:Prices
"CSCO",30.85," 9/09'16"
^
!Type:Prices
"CSCO",30.84," 9/16'16"
^
!Type:Prices
"CSCO",31.34," 9/23'16"
^
!Type:Prices
"CSCO",31.72," 9/30'16"
^
!Type:Prices
"CSCO",31.47,"10/07'16"
^
!Type:Prices
"CSCO",30.18,"10/14'16"
^
!Type:Prices
"CSCO",30.22,"10/17'16"
^
!Type:Prices
"CSCO",30.44,"10/18'16"
^
!Type:Prices
"CSCO",30.35,"10/19'16"
^
!Type:Prices
"CSCO",30.16,"10/20'16"
^
!Type:Prices
"CSCO",30.15,"10/21'16"
^
!Type:Prices
"CSCO",30.46,"10/24'16"
^
!Type:Prices
"CSCO",30.34,"10/25'16"
^
!Type:Prices
"CSCO",30.55,"10/26'16"
^
!Type:Prices
"CSCO",30.38,"10/27'16"
^
!Type:Prices
"CSCO",30.59,"10/28'16"
^
!Type:Prices
"CSCO",30.68,"10/31'16"
^
!Type:Prices
"CSCO",30.48,"11/01'16"
^
!Type:Prices
"CSCO",30.39,"11/02'16"
^
!Type:Prices
"CSCO",30.32,"11/03'16"
^
!Type:Prices
"CSCO",30.19,"11/04'16"
^
!Type:Prices
"CSCO",30.94,"11/07'16"
^
!Type:Prices
"CSCO",31,"11/08'16"
^
!Type:Prices
"CSCO",31.36,"11/09'16"
^
!Type:Prices
"CSCO",31,"11/10'16"
^
!Type:Prices
"CSCO",31.36,"11/11'16"
^
!Type:Prices
"CSCO",31.37,"11/14'16"
^
!Type:Prices
"CSCO",31.70,"11/15'16"
^

Comments

  • Unknown
    Unknown Member
    edited October 2018
    Very nice bug report.  For what is worth I see the same problem in Quicken 2016 R10.
  • markus1957
    markus1957 SuperUser, Windows Beta Beta
    edited January 2019
    Did the validation error log reference bad transfers that were removed? If so, I recall this was introduced in I think, Q16 R8. I had a dozen or so transfer links removed but I don't recall any issues with cost basis or market value being perturbed. Am I correct that the cost basis and market value of the security is maintained but the cash from the sell remains in the account? I never considered BuyX/SellX impacts of the bug. In my case they were just cash transfers converted to withdrawals and deposits so account balances were not impacted. The link between accounts was just broken/removed.

    Out of curiosity, if you manually re-create the Buy/Sell X transactions and then rerun the validation, are they removed again? My recollection from testing in Q16 R8 was that newly entered transactions survived the validation indicating that there was something in the impacted records which the validation routine did not consider clean.
  • Unknown
    Unknown Member
    edited December 2016

    Did the validation error log reference bad transfers that were removed? If so, I recall this was introduced in I think, Q16 R8. I had a dozen or so transfer links removed but I don't recall any issues with cost basis or market value being perturbed. Am I correct that the cost basis and market value of the security is maintained but the cash from the sell remains in the account? I never considered BuyX/SellX impacts of the bug. In my case they were just cash transfers converted to withdrawals and deposits so account balances were not impacted. The link between accounts was just broken/removed.

    Out of curiosity, if you manually re-create the Buy/Sell X transactions and then rerun the validation, are they removed again? My recollection from testing in Q16 R8 was that newly entered transactions survived the validation indicating that there was something in the impacted records which the validation routine did not consider clean.

    Note the testing is being done in a brand new data file, with the QIF file creating the transactions.  So no there are no reported errors when validation is run.
  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭
    edited May 2018
    In the FWIW column, with QWin2014 R9:
    • The BoughtX and SoldX transactions before and after the validate show $0 values in the Cash column (one line per transaction).
    • The Xin transactions before and after the validate shows blank in the Cash column.
    • The XOut transaction before the validate shows ($250) in the cash column and blank after the validate.  Oddly, the total for the cash column remains at $0.00.
    • The graph is unaffected by the validate.
    After that test, if the XOut transaction is deleted and re-entered manually, the ($250) reappears in the report until the next validate process which reverts that presentation back to blank.  

    So is the premise here that the report should (and does before the validate) show the cash values for the BoughtX and SoldX even though that cash is from a non-investment account?  Because the QWin2014 report was not doing that.  Thus perhaps this bug is also attributable to a report change that might have been made.

    Followup to that aspect:  If the originally imported BoughtX transactions are edited and saved (no data changes), then the report takes on the conventional 2-line presentation with - and + values (-2,350 and +2,350 for the 1/29 BoughtX) in the cash column.  With that corrected presentation, then the post-validate report is changed such that the second line (+2,350) changes to 0.00.  
  • mshiggins
    mshiggins SuperUser ✭✭✭✭✭
    edited December 2016
    q.lurker said:

    In the FWIW column, with QWin2014 R9:

    • The BoughtX and SoldX transactions before and after the validate show $0 values in the Cash column (one line per transaction).
    • The Xin transactions before and after the validate shows blank in the Cash column.
    • The XOut transaction before the validate shows ($250) in the cash column and blank after the validate.  Oddly, the total for the cash column remains at $0.00.
    • The graph is unaffected by the validate.
    After that test, if the XOut transaction is deleted and re-entered manually, the ($250) reappears in the report until the next validate process which reverts that presentation back to blank.  

    So is the premise here that the report should (and does before the validate) show the cash values for the BoughtX and SoldX even though that cash is from a non-investment account?  Because the QWin2014 report was not doing that.  Thus perhaps this bug is also attributable to a report change that might have been made.

    Followup to that aspect:  If the originally imported BoughtX transactions are edited and saved (no data changes), then the report takes on the conventional 2-line presentation with - and + values (-2,350 and +2,350 for the 1/29 BoughtX) in the cash column.  With that corrected presentation, then the post-validate report is changed such that the second line (+2,350) changes to 0.00.  
    So is the issue an artifact of the QIF importing?
    Quicken user since Q1999. Currently using QW2017.
    Questions? Check out the  Quicken Windows FAQ list
  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭
    edited December 2016
    q.lurker said:

    In the FWIW column, with QWin2014 R9:

    • The BoughtX and SoldX transactions before and after the validate show $0 values in the Cash column (one line per transaction).
    • The Xin transactions before and after the validate shows blank in the Cash column.
    • The XOut transaction before the validate shows ($250) in the cash column and blank after the validate.  Oddly, the total for the cash column remains at $0.00.
    • The graph is unaffected by the validate.
    After that test, if the XOut transaction is deleted and re-entered manually, the ($250) reappears in the report until the next validate process which reverts that presentation back to blank.  

    So is the premise here that the report should (and does before the validate) show the cash values for the BoughtX and SoldX even though that cash is from a non-investment account?  Because the QWin2014 report was not doing that.  Thus perhaps this bug is also attributable to a report change that might have been made.

    Followup to that aspect:  If the originally imported BoughtX transactions are edited and saved (no data changes), then the report takes on the conventional 2-line presentation with - and + values (-2,350 and +2,350 for the 1/29 BoughtX) in the cash column.  With that corrected presentation, then the post-validate report is changed such that the second line (+2,350) changes to 0.00.  
    I see two parts with respect to QW2014.  One from the QIF import - the QIF imported transaction is not reported the same as a QFX imported or manually entered transaction.  Second, the validate routine seems to change the reported information for several transaction types (BoughtX, XOut specifically as I see it), regardless of original entry method (not confirmed for QFX imports).   I suspect those two aspects are unrelated.  The fact that the OP cited and provided a QIF file does not seem relevant (to me) to his bug report / observation.  
  • mshiggins
    mshiggins SuperUser ✭✭✭✭✭
    edited December 2016
    q.lurker said:

    In the FWIW column, with QWin2014 R9:

    • The BoughtX and SoldX transactions before and after the validate show $0 values in the Cash column (one line per transaction).
    • The Xin transactions before and after the validate shows blank in the Cash column.
    • The XOut transaction before the validate shows ($250) in the cash column and blank after the validate.  Oddly, the total for the cash column remains at $0.00.
    • The graph is unaffected by the validate.
    After that test, if the XOut transaction is deleted and re-entered manually, the ($250) reappears in the report until the next validate process which reverts that presentation back to blank.  

    So is the premise here that the report should (and does before the validate) show the cash values for the BoughtX and SoldX even though that cash is from a non-investment account?  Because the QWin2014 report was not doing that.  Thus perhaps this bug is also attributable to a report change that might have been made.

    Followup to that aspect:  If the originally imported BoughtX transactions are edited and saved (no data changes), then the report takes on the conventional 2-line presentation with - and + values (-2,350 and +2,350 for the 1/29 BoughtX) in the cash column.  With that corrected presentation, then the post-validate report is changed such that the second line (+2,350) changes to 0.00.  

    I'm trying to decide if I should be really freaked out or not.

    I can definitely see the impact of my last file validation on existing X type transactions. The date of the last validate was 7/3/2016. X transactions prior to that time have $0 in the cash column, X transactions after that date have the $ amount in the cash column.

    What issue does this cause? Odd display of the cash in an investment transaction report? Damaged transactions?

    Quicken user since Q1999. Currently using QW2017.
    Questions? Check out the  Quicken Windows FAQ list
  • Derek
    Derek Member ✭✭
    edited October 2018
    I would not freak out as I believe the integrity of the Quicken file is fine before and after Validate.  This feels to me more like data migration/vestige of some sort, where some reports are slightly behind in the software development cycle and are backward compatible (work fine before Validate), but are not forward compatible (do not work 100% after Validate).  Please keep in mind Memorized Reports too.

    Detailed follow-up, but with respect to Windows Quicken 2017 Home & Business Version R3 Build 26.1.3.4:

    a) I only used QIF to help others reproduce.  You can enter everything by hand and obtain the same effects.  I recommend you do not focus on QIF further.

    b) My premise is Quicken reporting/graphing before running Validate is 100% correct.

    c)
    Validate completes normally and says in the log file that no errors
    were found.  Both behaviors are expected and correct.  However; the side
    effect of running Validate is some subtle, silent change of data in the
    Quicken file, which only causes certain, very specific reports/graphs
    to display incorrect numbers.  I provided two examples.  So much else in
    Quicken appears to be 100% correct before and after Validate.  For
    example, both the Checking and Brokerage Registers, and the Quicken
    Standard Reports, Investing, Investment Performance report, all look
    100% correct in every respect after Validate.

    d) Every time you
    run Validate, even after reentering the errant transactions, the same
    problem reoccurs with XIn, XOut, and BoughtX transactions.  Whatever you
    do to fix the problem will be undone by Validate.  It's deterministic. 
    Withdraw and Deposit transactions (albeit transfers) are not impacted
    (the test case shows this).

    e) I have to delete completely and
    reenter BoughtX transactions to restore correctness.  Any
    kind of editing I devised for BoughtX transactions did not restore the
    prior behavior.  I could, though, change XIn and XOut transactions in bulk
    using Find/Replace... to locate [Brokerage] Category transactions in
    the Checking account, replace the Category with something else (side
    effect to delete Investment transactions in Brokerage), and replace once
    again with [Brokerage] (side effect to recreate the same XIn/XOut
    transactions).

    f) I can find other reports that are impacted by
    this bug, such as those that itemize transfer details into/out of Investment
    accounts.  Another example is the Quicken Standard Reports, Banking,
    Transaction report.  Customize and select Brokerage Account only, and clear
    all Categories except for [Checking].  Run the report.  Notice all the
    zeros now (non-zero before Validate).  Oddly, notice the TOTAL IN/OUT
    FLOWS are correct!  (That is an interesting clue that points to reporting.)  Double-click on the 10/1 XIn $0.00 line on the
    report, and you will see the correct information ($1000.00) in a popup
    dialog window.

    g) If you want me to speculate, I would say this
    problem has to do with
    data migration, where redundant/historic/derived information, which exists
    in a transaction, is removed by Validate.  New transactions entered
    still store data in both the "old" and "new" places, and reports in some
    cases
    still reference (erroneously) the data from the "old" place. 
    If my speculation is correct, the details of a bug fix are with Reporting rather than with Validate.  This is especially true for the
    graph.  But I would fix Validate too, as defensive programming.

    h) I attached before and after graphs below. 
    Notice the second graph (after Validate) is not perfectly zero between
    3/12 and 7/30.  If you want to see something truly bazaar, keep using the
    Quicken file after Validate, add 0.0001 shares of CSCO to Brokerage
    account on 1/2/2016, and rerun the graph.  The "bad after validate
    graph" changes to look like the "good before validate graph."  The
    algorithm in the graph must take a different branch if the share balance
    does not reach zero between the two sets Cisco activity.  Furthermore,
    the algorithm failure only manifests after Validate.


    image


    image
  • Unknown
    Unknown Member
    edited December 2016
    Derek said:

    I would not freak out as I believe the integrity of the Quicken file is fine before and after Validate.  This feels to me more like data migration/vestige of some sort, where some reports are slightly behind in the software development cycle and are backward compatible (work fine before Validate), but are not forward compatible (do not work 100% after Validate).  Please keep in mind Memorized Reports too.

    Detailed follow-up, but with respect to Windows Quicken 2017 Home & Business Version R3 Build 26.1.3.4:

    a) I only used QIF to help others reproduce.  You can enter everything by hand and obtain the same effects.  I recommend you do not focus on QIF further.

    b) My premise is Quicken reporting/graphing before running Validate is 100% correct.

    c)
    Validate completes normally and says in the log file that no errors
    were found.  Both behaviors are expected and correct.  However; the side
    effect of running Validate is some subtle, silent change of data in the
    Quicken file, which only causes certain, very specific reports/graphs
    to display incorrect numbers.  I provided two examples.  So much else in
    Quicken appears to be 100% correct before and after Validate.  For
    example, both the Checking and Brokerage Registers, and the Quicken
    Standard Reports, Investing, Investment Performance report, all look
    100% correct in every respect after Validate.

    d) Every time you
    run Validate, even after reentering the errant transactions, the same
    problem reoccurs with XIn, XOut, and BoughtX transactions.  Whatever you
    do to fix the problem will be undone by Validate.  It's deterministic. 
    Withdraw and Deposit transactions (albeit transfers) are not impacted
    (the test case shows this).

    e) I have to delete completely and
    reenter BoughtX transactions to restore correctness.  Any
    kind of editing I devised for BoughtX transactions did not restore the
    prior behavior.  I could, though, change XIn and XOut transactions in bulk
    using Find/Replace... to locate [Brokerage] Category transactions in
    the Checking account, replace the Category with something else (side
    effect to delete Investment transactions in Brokerage), and replace once
    again with [Brokerage] (side effect to recreate the same XIn/XOut
    transactions).

    f) I can find other reports that are impacted by
    this bug, such as those that itemize transfer details into/out of Investment
    accounts.  Another example is the Quicken Standard Reports, Banking,
    Transaction report.  Customize and select Brokerage Account only, and clear
    all Categories except for [Checking].  Run the report.  Notice all the
    zeros now (non-zero before Validate).  Oddly, notice the TOTAL IN/OUT
    FLOWS are correct!  (That is an interesting clue that points to reporting.)  Double-click on the 10/1 XIn $0.00 line on the
    report, and you will see the correct information ($1000.00) in a popup
    dialog window.

    g) If you want me to speculate, I would say this
    problem has to do with
    data migration, where redundant/historic/derived information, which exists
    in a transaction, is removed by Validate.  New transactions entered
    still store data in both the "old" and "new" places, and reports in some
    cases
    still reference (erroneously) the data from the "old" place. 
    If my speculation is correct, the details of a bug fix are with Reporting rather than with Validate.  This is especially true for the
    graph.  But I would fix Validate too, as defensive programming.

    h) I attached before and after graphs below. 
    Notice the second graph (after Validate) is not perfectly zero between
    3/12 and 7/30.  If you want to see something truly bazaar, keep using the
    Quicken file after Validate, add 0.0001 shares of CSCO to Brokerage
    account on 1/2/2016, and rerun the graph.  The "bad after validate
    graph" changes to look like the "good before validate graph."  The
    algorithm in the graph must take a different branch if the share balance
    does not reach zero between the two sets Cisco activity.  Furthermore,
    the algorithm failure only manifests after Validate.


    image


    image

    Excellent report!  I doubt that I would have every noticed such a problem.
  • mshiggins
    mshiggins SuperUser ✭✭✭✭✭
    edited December 2016
    Derek said:

    I would not freak out as I believe the integrity of the Quicken file is fine before and after Validate.  This feels to me more like data migration/vestige of some sort, where some reports are slightly behind in the software development cycle and are backward compatible (work fine before Validate), but are not forward compatible (do not work 100% after Validate).  Please keep in mind Memorized Reports too.

    Detailed follow-up, but with respect to Windows Quicken 2017 Home & Business Version R3 Build 26.1.3.4:

    a) I only used QIF to help others reproduce.  You can enter everything by hand and obtain the same effects.  I recommend you do not focus on QIF further.

    b) My premise is Quicken reporting/graphing before running Validate is 100% correct.

    c)
    Validate completes normally and says in the log file that no errors
    were found.  Both behaviors are expected and correct.  However; the side
    effect of running Validate is some subtle, silent change of data in the
    Quicken file, which only causes certain, very specific reports/graphs
    to display incorrect numbers.  I provided two examples.  So much else in
    Quicken appears to be 100% correct before and after Validate.  For
    example, both the Checking and Brokerage Registers, and the Quicken
    Standard Reports, Investing, Investment Performance report, all look
    100% correct in every respect after Validate.

    d) Every time you
    run Validate, even after reentering the errant transactions, the same
    problem reoccurs with XIn, XOut, and BoughtX transactions.  Whatever you
    do to fix the problem will be undone by Validate.  It's deterministic. 
    Withdraw and Deposit transactions (albeit transfers) are not impacted
    (the test case shows this).

    e) I have to delete completely and
    reenter BoughtX transactions to restore correctness.  Any
    kind of editing I devised for BoughtX transactions did not restore the
    prior behavior.  I could, though, change XIn and XOut transactions in bulk
    using Find/Replace... to locate [Brokerage] Category transactions in
    the Checking account, replace the Category with something else (side
    effect to delete Investment transactions in Brokerage), and replace once
    again with [Brokerage] (side effect to recreate the same XIn/XOut
    transactions).

    f) I can find other reports that are impacted by
    this bug, such as those that itemize transfer details into/out of Investment
    accounts.  Another example is the Quicken Standard Reports, Banking,
    Transaction report.  Customize and select Brokerage Account only, and clear
    all Categories except for [Checking].  Run the report.  Notice all the
    zeros now (non-zero before Validate).  Oddly, notice the TOTAL IN/OUT
    FLOWS are correct!  (That is an interesting clue that points to reporting.)  Double-click on the 10/1 XIn $0.00 line on the
    report, and you will see the correct information ($1000.00) in a popup
    dialog window.

    g) If you want me to speculate, I would say this
    problem has to do with
    data migration, where redundant/historic/derived information, which exists
    in a transaction, is removed by Validate.  New transactions entered
    still store data in both the "old" and "new" places, and reports in some
    cases
    still reference (erroneously) the data from the "old" place. 
    If my speculation is correct, the details of a bug fix are with Reporting rather than with Validate.  This is especially true for the
    graph.  But I would fix Validate too, as defensive programming.

    h) I attached before and after graphs below. 
    Notice the second graph (after Validate) is not perfectly zero between
    3/12 and 7/30.  If you want to see something truly bazaar, keep using the
    Quicken file after Validate, add 0.0001 shares of CSCO to Brokerage
    account on 1/2/2016, and rerun the graph.  The "bad after validate
    graph" changes to look like the "good before validate graph."  The
    algorithm in the graph must take a different branch if the share balance
    does not reach zero between the two sets Cisco activity.  Furthermore,
    the algorithm failure only manifests after Validate.


    image


    image

    Second that.
    Quicken user since Q1999. Currently using QW2017.
    Questions? Check out the  Quicken Windows FAQ list
  • Unknown
    Unknown Member
    edited December 2016
    Derek said:

    I would not freak out as I believe the integrity of the Quicken file is fine before and after Validate.  This feels to me more like data migration/vestige of some sort, where some reports are slightly behind in the software development cycle and are backward compatible (work fine before Validate), but are not forward compatible (do not work 100% after Validate).  Please keep in mind Memorized Reports too.

    Detailed follow-up, but with respect to Windows Quicken 2017 Home & Business Version R3 Build 26.1.3.4:

    a) I only used QIF to help others reproduce.  You can enter everything by hand and obtain the same effects.  I recommend you do not focus on QIF further.

    b) My premise is Quicken reporting/graphing before running Validate is 100% correct.

    c)
    Validate completes normally and says in the log file that no errors
    were found.  Both behaviors are expected and correct.  However; the side
    effect of running Validate is some subtle, silent change of data in the
    Quicken file, which only causes certain, very specific reports/graphs
    to display incorrect numbers.  I provided two examples.  So much else in
    Quicken appears to be 100% correct before and after Validate.  For
    example, both the Checking and Brokerage Registers, and the Quicken
    Standard Reports, Investing, Investment Performance report, all look
    100% correct in every respect after Validate.

    d) Every time you
    run Validate, even after reentering the errant transactions, the same
    problem reoccurs with XIn, XOut, and BoughtX transactions.  Whatever you
    do to fix the problem will be undone by Validate.  It's deterministic. 
    Withdraw and Deposit transactions (albeit transfers) are not impacted
    (the test case shows this).

    e) I have to delete completely and
    reenter BoughtX transactions to restore correctness.  Any
    kind of editing I devised for BoughtX transactions did not restore the
    prior behavior.  I could, though, change XIn and XOut transactions in bulk
    using Find/Replace... to locate [Brokerage] Category transactions in
    the Checking account, replace the Category with something else (side
    effect to delete Investment transactions in Brokerage), and replace once
    again with [Brokerage] (side effect to recreate the same XIn/XOut
    transactions).

    f) I can find other reports that are impacted by
    this bug, such as those that itemize transfer details into/out of Investment
    accounts.  Another example is the Quicken Standard Reports, Banking,
    Transaction report.  Customize and select Brokerage Account only, and clear
    all Categories except for [Checking].  Run the report.  Notice all the
    zeros now (non-zero before Validate).  Oddly, notice the TOTAL IN/OUT
    FLOWS are correct!  (That is an interesting clue that points to reporting.)  Double-click on the 10/1 XIn $0.00 line on the
    report, and you will see the correct information ($1000.00) in a popup
    dialog window.

    g) If you want me to speculate, I would say this
    problem has to do with
    data migration, where redundant/historic/derived information, which exists
    in a transaction, is removed by Validate.  New transactions entered
    still store data in both the "old" and "new" places, and reports in some
    cases
    still reference (erroneously) the data from the "old" place. 
    If my speculation is correct, the details of a bug fix are with Reporting rather than with Validate.  This is especially true for the
    graph.  But I would fix Validate too, as defensive programming.

    h) I attached before and after graphs below. 
    Notice the second graph (after Validate) is not perfectly zero between
    3/12 and 7/30.  If you want to see something truly bazaar, keep using the
    Quicken file after Validate, add 0.0001 shares of CSCO to Brokerage
    account on 1/2/2016, and rerun the graph.  The "bad after validate
    graph" changes to look like the "good before validate graph."  The
    algorithm in the graph must take a different branch if the share balance
    does not reach zero between the two sets Cisco activity.  Furthermore,
    the algorithm failure only manifests after Validate.


    image


    image

    BTW this is how you give Quicken Inc the best chance to fix a bug.  Some people think that "their job" is just to "mention a bug", and for the developers to figure out the details.  And that is true, but the more time a developer has to take to find it, the less bugs they can fix, and if they can't find the problem in certain amount of time, they will be forced to go on to another bug.  Such a great report helps a lot.

    My only wish is that is great report was submitted in beta where it might get a bit more attention.

    Mind you I hope it will be seen here, and there is no telling what the priority would be and such no matter if it is submitted in a beta or not.
  • ta
    ta Member ✭✭
    edited October 2018

    I reported this same BUG to Quicken back in August 2014. I was using Home and Business 2014. I spent several hours sending emails back and forth with Quicken Support. I even sent them two very simple data files to test with and gave them step-by-step instructions on how to reproduce the issue. After a few emails, they dropped the issue and deleted the email address that I was using to email them. I never heard back from them. Today I'm investigating whether to upgrade to Quicken 2017 because Quicken 2016 keeps crashing every time I click on ANY menu link (a totally different issue). However, if I call Quicken support about the crashes the first thing that they will do is to ask me to "Validate and Repair" my data file. Since I know that THIS issue will come back if I validate my file I am investigating upgrading to 2017 instead. In short, I'm very disappointed that this problem has not been resolved since it is one of the tools that quicken support uses regularly to help us resolve OTHER quicken issues. I do have some "HOPE" left in me though. Quicken is now under new ownership and "hopefully" the new owners will be more responsive to customer issues!

    https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&u...

    http://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ua...

  • Unknown
    Unknown Member
    edited December 2016
    ta said:

    I reported this same BUG to Quicken back in August 2014. I was using Home and Business 2014. I spent several hours sending emails back and forth with Quicken Support. I even sent them two very simple data files to test with and gave them step-by-step instructions on how to reproduce the issue. After a few emails, they dropped the issue and deleted the email address that I was using to email them. I never heard back from them. Today I'm investigating whether to upgrade to Quicken 2017 because Quicken 2016 keeps crashing every time I click on ANY menu link (a totally different issue). However, if I call Quicken support about the crashes the first thing that they will do is to ask me to "Validate and Repair" my data file. Since I know that THIS issue will come back if I validate my file I am investigating upgrading to 2017 instead. In short, I'm very disappointed that this problem has not been resolved since it is one of the tools that quicken support uses regularly to help us resolve OTHER quicken issues. I do have some "HOPE" left in me though. Quicken is now under new ownership and "hopefully" the new owners will be more responsive to customer issues!

    https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&u...

    http://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ua...

    I seriously doubt that upgrading to Quicken 2017 would make a difference in your crashes.  The best advise (other than Validate, which won't fix everything and even can cause problems as you noted) is the QCleanUI procedure.  And make sure to get the couple of Intuit directories that they fail to mention at:
    C:\Users\USERNAME\AppData\Local
    http://quicken.intuit.com/support/help/downloading--installing--upgrading-and-converting/using-qcleanui-to-uninstall-quicken/GEN82227.html

    Note Quicken 2016 hasn't crashed for me in a very long time.
    Also I have found that the Quicken developers are the most likely to work on a bug, reported in the betas just when the start to announce the new release for the year.  And in general betas bug reports at least get reviewed by the beta team.  Which at least gives you some kind of status.  Like is it put in the system the developers use or not.

    But they have tons on their table and constantly adding to that with new features that always seem to need work after releasing.

    These days "beta" goes on pretty much all year for one release or another, with breaks waiting for the next release to test.  And is open for sign up all the time.
    https://quickenbeta.centercode.com/welcome/

    I will warn you though that the statement is that for "release" bugs you aren't suppose to submit them in the beta at this point.  Even though some people do.
    Other than that and Quicken support, the one other place that is suppose to be for submitting bugs is the text box in this survey.
    https://www.research.net/r/QuickenFeedback?sm=9cOc3rwodcapt1xKTYk0cf7SRSYdM1uCbxXTU%2fpPxQo%3d
  • ta
    ta Member ✭✭
    edited December 2016
    ta said:

    I reported this same BUG to Quicken back in August 2014. I was using Home and Business 2014. I spent several hours sending emails back and forth with Quicken Support. I even sent them two very simple data files to test with and gave them step-by-step instructions on how to reproduce the issue. After a few emails, they dropped the issue and deleted the email address that I was using to email them. I never heard back from them. Today I'm investigating whether to upgrade to Quicken 2017 because Quicken 2016 keeps crashing every time I click on ANY menu link (a totally different issue). However, if I call Quicken support about the crashes the first thing that they will do is to ask me to "Validate and Repair" my data file. Since I know that THIS issue will come back if I validate my file I am investigating upgrading to 2017 instead. In short, I'm very disappointed that this problem has not been resolved since it is one of the tools that quicken support uses regularly to help us resolve OTHER quicken issues. I do have some "HOPE" left in me though. Quicken is now under new ownership and "hopefully" the new owners will be more responsive to customer issues!

    https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&u...

    http://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ua...

    Hey. Thanks for the reply. I'll have to checkout some of these links. I suspect that you are using the US version of quicken though since you indicate that you are using R10. Here in Canada we don't get all of those upgrades for the "Home and Business" version that we get here. I'm running "the latest" version which is R2! I don't know why quicken treats us this way!

    Incidentally, my most recent crashes went away when I rebooted my windows 7 pc. I'm starting to think that my daily registry scrubbing that Norton does is screwing something up with Quicken. Maybe I'll turn off Norton for a while to see what happens.
  • Unknown
    Unknown Member
    edited December 2016
    ta said:

    I reported this same BUG to Quicken back in August 2014. I was using Home and Business 2014. I spent several hours sending emails back and forth with Quicken Support. I even sent them two very simple data files to test with and gave them step-by-step instructions on how to reproduce the issue. After a few emails, they dropped the issue and deleted the email address that I was using to email them. I never heard back from them. Today I'm investigating whether to upgrade to Quicken 2017 because Quicken 2016 keeps crashing every time I click on ANY menu link (a totally different issue). However, if I call Quicken support about the crashes the first thing that they will do is to ask me to "Validate and Repair" my data file. Since I know that THIS issue will come back if I validate my file I am investigating upgrading to 2017 instead. In short, I'm very disappointed that this problem has not been resolved since it is one of the tools that quicken support uses regularly to help us resolve OTHER quicken issues. I do have some "HOPE" left in me though. Quicken is now under new ownership and "hopefully" the new owners will be more responsive to customer issues!

    https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&u...

    http://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ua...

    Yes I'm using the US version, but Quicken Inc isn't totally leaving you out either.
    In someways the procedures for the Canadian version "shield" you from some problems too.

    The reason that the US version might have 10 releases and the Canadian only a couple is because the US version gets a new release about every month during the "update cycle".  What they do for the Canadian version on the other hand is because they have merge the changes from the US branch to the Canadian version they wait and combine multiple US release into one Canadian version.

    For instance Quicken 2017 US came out in October, but the Canadian version has yet to be released.  When it does it will probably be at the equivalent of the US version's R3 or maybe R4.  After that they will probably wait until the end of April when the US patching usually ends before they will put out another Canadian version.
  • ta
    ta Member ✭✭
    edited December 2016
    ta said:

    I reported this same BUG to Quicken back in August 2014. I was using Home and Business 2014. I spent several hours sending emails back and forth with Quicken Support. I even sent them two very simple data files to test with and gave them step-by-step instructions on how to reproduce the issue. After a few emails, they dropped the issue and deleted the email address that I was using to email them. I never heard back from them. Today I'm investigating whether to upgrade to Quicken 2017 because Quicken 2016 keeps crashing every time I click on ANY menu link (a totally different issue). However, if I call Quicken support about the crashes the first thing that they will do is to ask me to "Validate and Repair" my data file. Since I know that THIS issue will come back if I validate my file I am investigating upgrading to 2017 instead. In short, I'm very disappointed that this problem has not been resolved since it is one of the tools that quicken support uses regularly to help us resolve OTHER quicken issues. I do have some "HOPE" left in me though. Quicken is now under new ownership and "hopefully" the new owners will be more responsive to customer issues!

    https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&u...

    http://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ua...

    Good to know. Thanks.
This discussion has been closed.