(Canadian

Interesting. Can I confirm that I'm understanding the issue correctly. 1) You reconciled an account. 2) You then turned off the "Use posted date for matched transactions". 3) This then changed the dates on your reconciled transactions and reconcile history detected these as changes and there is no way for you to fix these in the re-reconcile screen. Is that correct? Let me message you directly and would you be willing to share some screenshots with me so that we can get a better understanding of the issue you're seeing?Jon said:In the Connected Services preferences, I have unchecked "Use posted date for matched transactions", and this seems to be throwing off the Reconciliation History.
I made a credit card purchase this month which didn't post until the day after the end date on the monthly statement. The date I entered for the purchase was the day before the end date on the statement. So my Quicken balance on the statement end date doesn't match the statement balance I reconciled to because of this transaction that had not posted yet. Reconciliation History shows the mismatch but there doesn't seem to be anything I can do other than change the date on the transaction to the posted date. The re-reconciliation screen doesn't show the "missing" transaction, it only shows the transactions that were already marked as reconciled.
I guess I expect Quicken to identify transactions that straddle the statement end date and make an adjustment for them. Without that, the reconciliation history is going to be full of mismatches that it thinks are errors but really aren't.
Jon, thanks for posting this issue. We figured out what was going wrong in your specific situation and have decided to fix it by simply not including uncleared transactions that overlap reconciliation sessions in our determination as to whether there is a discrepancy. Our original thinking was we wanted to expose transactions that were accidentally added in the past that conflicted with already reconciled transactions. However, we've decided that these types of errors will be easily discovered when you do a normal reconcile since all uncleared transactions appear in every reconcile session. This is the primary reason we don't include a start date. We're going to focus the Re-Reconcile feature on just those situations where previously reconciled transactions are changed in some way or are deleted. This also solves the problem of showing a discrepancy in the Reconciliation History even when there really isn't a discrepancy just because you downloaded new transactions. It's sort of the situation you're in where your previous reconcile session is still correct. It's really not in error. However, we're showing it in error because a newly downloaded transaction just happens to be dated earlier than your reconcile session. In any case, the issue you ran into will be solved. Thanks again for reporting it and for providing the screenshots to me in a direct messageJon said:@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.
Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.
That's really interesting. Thanks. I'll file a ticket. Sometimes it's these small little things that make all the difference.[email protected] said:@Quicken Marcus I really love the new Reconciliation History and the consistency with how reports are saved. One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version. This is standard macOS behavior and clues a user in even before they go to close a report that they will be prompted to save the changes, as there have been modifications that have occurred. Here's an example from Pages. After editing a saved document, the little black dot appears in the red close button to indicate that the file has been modified and that the user will be prompted to save or not save when closing the document.
Obviously this is a picky refinement and doesn't affect the functionality of reports in Quicken, but it would be a nice touch that would bring Quicken's interface behavior in line with standard macOS behavior.
Thanks again for all your hard work improving Quicken Mac. It's greatly appreciated!
Quicken Marcus said:Jon, thanks for posting this issue. We figured out what was going wrong in your specific situation and have decided to fix it by simply not including uncleared transactions that overlap reconciliation sessions in our determination as to whether there is a discrepancy. Our original thinking was we wanted to expose transactions that were accidentally added in the past that conflicted with already reconciled transactions. However, we've decided that these types of errors will be easily discovered when you do a normal reconcile since all uncleared transactions appear in every reconcile session. This is the primary reason we don't include a start date. We're going to focus the Re-Reconcile feature on just those situations where previously reconciled transactions are changed in some way or are deleted. This also solves the problem of showing a discrepancy in the Reconciliation History even when there really isn't a discrepancy just because you downloaded new transactions. It's sort of the situation you're in where your previous reconcile session is still correct. It's really not in error. However, we're showing it in error because a newly downloaded transaction just happens to be dated earlier than your reconcile session. In any case, the issue you ran into will be solved. Thanks again for reporting it and for providing the screenshots to me in a direct messageJon said:@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.
Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.
That is the issue I am raising... that is why I highlighted that section of his statement.
The date! to maintain context of the entry, both in the register and in reports, but is only determined after the fact.jacobs said:I got that. But I was also questioning why it really matters. A zero-dollar transaction doesn't affect any reconciliation, so why would it matter what reconciliation it's included in?
Yes. Click on the green reconciled check mark. You get this warning dialog:smayer97 said:RE: Reconciliation HistoryCan someone confirm if it is possible to unreconcile a transaction in the window? If so, how?
To the best of my knowledge, no. But you could always go to the register itself, Shift-click or Command-click multiple transactions, and change the status to Not Cleared. (I don't want to test how that affect the reconciliations, because I've already gotten my test file into a messed-up state doing multiple re-reconciles and bumping into the issue Jon wrote about and Marcus acknowledged above. I will wait until their next dot release to experiment with this further.)smayer97 said:What about unreconciling multiple transactions at one time within the window? If so, how?
Thanks for these comments. We took them to heart. We also observed other problems with excluding the cleared transactions while tweaking the behavior such as adding an adjustment would immediately disappear because it wasn't a reconciled transaction, etc. The change we've implemented in 6.1.1 which we'll be shipping shortly is that cleared transactions will continue to appear in the re-reconcile screen just like regular reconcile but they will not be counted as a discrepancy on the History screen since they were not part of the original reconciliation session. The original issue where some cleared transactions weren't appearing in the re-reconcile screen but were impacting the discrepancy calculation has also been fixed. The calculation at the top of the reconcile screen will include only the transactions that appear in that screen. The bug that was in 6.1 was that the calculation was using a subtly different set of transactions that could be different based on posted date and entered date. We think these changes will make this work a lot better for most people in 6.1.1 but we also expect to continue to refine this new feature in future updates to make it better. As always, thanks for the great feedback.smayer97 said:Quicken Marcus said:Jon, thanks for posting this issue. We figured out what was going wrong in your specific situation and have decided to fix it by simply not including uncleared transactions that overlap reconciliation sessions in our determination as to whether there is a discrepancy. Our original thinking was we wanted to expose transactions that were accidentally added in the past that conflicted with already reconciled transactions. However, we've decided that these types of errors will be easily discovered when you do a normal reconcile since all uncleared transactions appear in every reconcile session. This is the primary reason we don't include a start date. We're going to focus the Re-Reconcile feature on just those situations where previously reconciled transactions are changed in some way or are deleted. This also solves the problem of showing a discrepancy in the Reconciliation History even when there really isn't a discrepancy just because you downloaded new transactions. It's sort of the situation you're in where your previous reconcile session is still correct. It's really not in error. However, we're showing it in error because a newly downloaded transaction just happens to be dated earlier than your reconcile session. In any case, the issue you ran into will be solved. Thanks again for reporting it and for providing the screenshots to me in a direct messageJon said:@jacobs, it sounds like your understanding is basically correct. I'm pretty sure Quicken automatically matched the transaction in question, I rarely have to manually match them up with drag & drop. I'm also certain that the transaction was already entered in the register before I reconciled. I should probably also mention that although I'm regularly downloading transactions from the bank, I only reconcile the account once a month using the statement balance.
Quicken has never had a reconciliation problem with these kind of transactions before, it's only showing up as an issue in the new Reconciliation History window. It seems as though it is looking at the register balance on the reconciliation date and expecting that the balance I reconciled to should match that. It isn't checking to see if the register balance includes transactions that hadn't posted yet on that date.@Quicken Marcus I see a real problem with this approach... it misses one key use case of re-reconciling... that is when you reconciled but then need to actually add one or more transactions that was/were not included in the first reconciliation.
So, if you exclude transactions that were not part of the original, you are missing an important use case and make it impossible to re-reconcile with additional transactions. BTW, this is how QM2007 works, for good reason ... and it has always been flawless.
Great suggestion. Is the idea that you would want to clear all transactions and sort of start from scratch? Should we add a Clear All Reconciled Transactions button? Or do you think the most common use case would be to un-reconciled a group of transactions? Can you tell me more about why you would want to do this so we have a better understanding of the goal?smayer97 said:@jacobs thanks for confirming both these things. That is what I suspected.@Quicken Marcus so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same... allow selecting multiple transactions in the re-reconciliation window and be able to unreconcile them in one step, just like in the register.I'd also suggest that there be a CANCEL button to the entire re-reconcile window to revert ALL changes and be able to exit, and therefore the "are you sure" confirmation dialogue box when unreconciling an individual transaction be removed, as it would become redundant since the whole purpose of the Re-Reconciliation window is to adjust any entry in the list. This is how QM2007 works so you can abort any changes. It is a much safer approach.
So just to be clear so we are on the same page... the thought behind the CANCEL button is NOT to undo the entire reconciliation but rather if one starts a re-reconcile and part way through realize you just want to undo any and all changes, the button would revert back to the last reconciled state and simply not apply any of the changes, so really just a REVERT ALL and EXIT.Quicken Marcus said:Great suggestion. Is the idea that you would want to clear all transactions and sort of start from scratch? Should we add a Clear All Reconciled Transactions button? Or do you think the most common use case would be to un-reconciled a group of transactions? Can you tell me more about why you would want to do this so we have a better understanding of the goal?smayer97 said:@jacobs thanks for confirming both these things. That is what I suspected.@Quicken Marcus so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same... allow selecting multiple transactions in the re-reconciliation window and be able to unreconcile them in one step, just like in the register.I'd also suggest that there be a CANCEL button to the entire re-reconcile window to revert ALL changes and be able to exit, and therefore the "are you sure" confirmation dialogue box when unreconciling an individual transaction be removed, as it would become redundant since the whole purpose of the Re-Reconciliation window is to adjust any entry in the list. This is how QM2007 works so you can abort any changes. It is a much safer approach.
Thank you. This helps me better understand the ask.smayer97 said:So just to be clear so we are on the same page... the thought behind the CANCEL button is NOT to undo the entire reconciliation but rather if one starts a re-reconcile and part way through realize you just want to undo any and all changes, the button would revert back to the last reconciled state and simply not apply any of the changes, so really just a REVERT ALL and EXIT.Quicken Marcus said:Great suggestion.smayer97 said:@Quicken Marcus so there appears an inconsistency between the register and the re-conciliation window in handling unreconciling transactions. I suggest that at a minimum, they work the same...
Austin, our report software developer agreed with you 100% and it was easy to do so you'll see your suggestion in the v6.1.1. release that we just shipped.[email protected] said:One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version.
Thanks @Quicken Marcus. Much appreciated!Quicken Marcus said:Austin, our report software developer agreed with you 100% and it was easy to do so you'll see your suggestion in the v6.1.1. release that we just shipped.[email protected] said:One small refinement that would improve what happens when reports are edited would be to have the red "close" button in the top left corner of the report window display a dot when the report has been modified from the saved version.