Register balance value incorrect after R39.21 Update

charb

Hi Fellow users

Got an issue: Case # 9292281
Windows subscription (Premium); 64 bit Win10 OS build (27.1.39.21)

3/6/2022: No problems with Quicken, accounts, register, download etc.; last time used
3/9/2022: Received the push R39.21 update; installed and launched Quicken

Issue presentation:
Working checking and saving accounts now exhibit the following in the register view

1) Online balance and End balance appears accurate
2) Checking register balance is (-$45K); Saving register balance is +$131K

Have Quicken data probably back to 2000 (20K transactions in checking account). Going back in the checking register I see the balance started going negative in 2007. Need to confirm but is could coincide with the start of the use of paycheck split function (which drives 401K, FSA sub accounts via paycheck splits).

Attempted Resolution with Quicken support: 3/9/2022
Restore 3/6/2022 data file; issue still present.

Observations:
All was working before push update.
Problem transcends current data file and historical working data file; suggesting a issue with the update code.

Crawled the web noting issue related to loss of paycheck split in R39.21. Quicken support (3/11/2022) suggest data file validation and check for loss of split data in register entries. Referenced solution: roll back to R38.30 and use know good data file (secondary copy of 3/6/2022 data file on hand)

Anyone else seeing this issue presentation?

NOTE: I have witnessed in the past a similar presentation when I would search for a dollar transaction but once cleared the on line / ending and register balance would be in close dollar synch if there were outstanding charges - but never negative by $10K

Thanks for your time; rework pending tonight.

charb

lrem

https://community.quicken.com/discussion/comment/20252574#Comment_20252574
My comment from a different discussion but similar issue of beginning balance stealthily changed!

charb

Spend the last 3 hours on a Saturday (just what I wanted to do...) attempting to bring clarity to this issue presentation and have the following to add to my post.

The paycheck splits - which drive my secondary accounts like 403B, 401K and FSA - appear to be the item impacting deposit and registry balances in the target checking and saving accounts.

The basic signature is the deposit amount in the register is retained (matches my paper bank statement) but when the split is opened (paycheck "view") the "salary" total (a defined sub category in my paycheck split) comes no where to what is needed to offset the listed deductions (i.e., medical, dental, vision, federal, state, medicare, 401K, FSA, etc).

There is also evidence in the saving account the deposited paycheck amount now does not match the paper statement. Meaning... say the savings paper statement list $3500 as the deposit; now the deposit amount in the saving register reflects say, $1370.

So I am beginning to suspect the patch perhaps created a problem with the individual splits "logic" and whatever logic is under the cover to calculate the running account balance. For me, it is a question as to why it affected a reconciled transaction in the register ten plus years ago. (I would have hoped it was locked for rework)

I ran a validation check of what I am classifying as the "broken" data file (this being the one isolated and used for testing) and there are hundreds of references to:

"....the following transactions involving transfers appear to be damaged. You should delete them and recreate as appropriate."

uh... really?

These references reflect dates as far back at 2008 and target 401K, 403b, 401K Loan and FSA splits/ accounts; not a simple process to "recreate".

So my initial conclusion is the patch blew up something in the way paycheck splits are managed and "tied" to the target sub accounts they feed as well as the logic used for summation of account balances

I have been working without an intranet connection to prevent download of the "correction" patch that was referenced to be a release in a 3/11 Quicken because - frankly - I am gun shy on the automatic update process. (Seems necessary to modify my UAC settings to not allow this unless fully vetted).

I am contemplating my next moved.

I see the need to revert to the prior release and hope that my preserved backup file (3/6/2022 or 3/4/2022) will restore some level of sanity as this is a real mess.

I've used Quicken for twenty years and have largely measured other programs against the solid nature of this product. However, this is the biggest mess I have had to deal with - and this is my finances and yes they are important.. When I called for an update on the case, it was pretty clear support shunts caller to the Quicken Community; giving me the impression there is limited support for individual case management. Sorry to say I'm not feeling the Quicken love right now.. seems I am left to "figure it out" on my own time. If this is a patch / coding issue how about a little acknowledgement and support for those user who count on this product to manage bills, investments and their overall financial health?

I will post an update once I take the plunge and revert back to R38.30 and retest

charb

Issue was fixed by reverting back to R38.30 and restoring a backup from a prior to the R39.21 patch