I wonder what they changed in the "matching formula"

Chris_QPW

I remarked on this at the time but would bet most people didn't pick up on it.

Do folks remember when the first few financial institutions went from Direct Connect to Express Web Connect +?

The process really surprised me. Here there was a change over and I was very much aware of the fact that the unique Ids changed between the two. The surprising part was that people weren't getting duplicate transactions. There were a few outliners, but for the most part, it was as if the unique Ids hadn't changed.

Clearly something changed that prevented Quicken from considering them duplicates.

I watched that process, and the old unique Ids in the register didn't change, just new transactions started coming in with the new unique Ids (different format).

Clearly something was doing some kind of compare before the transactions ever got to Quicken (the program) to prevent duplicate transactions.

That process seems to have been changed and is now identifying transactions as duplicates when they in fact, aren't.

QuickUserPSP

@Chris_QPW it could be that some of their lines of code may be out of order - looking at amount before unique transaction ID.

Or it could be simply that transactions are missing the unique transaction IDs and then filtering on amounts only.

Or it could be that there are duplicate unique fund IDs and then only able to filter on amount.

If it was just a matter of missing unique fund IDs, I would think it could be fixed easily. If it was a coding issue, then the programmers would need to scrutinize thousands of lines of codes.

It could be a combination of all of the above. It is a process of elimination.

That is why it is easy to think you have something fixed, but really don't because you didn't fix every piece of the issue. Also, it is very easy to fix something but break something else.

I remember working with BASIC, FORTRAN, and COBOL using punch cards. (Most who are reading this are probably wondering what "punch cards" are). You would submit your program (stack of punch cards) and pray that your program completes successfully. Even when it completes successfully that didn't mean the program produced the results that you needed. I remember it was countless hours of debugging.

Chris_QPW

Oh, I have spent countless hours on trying to track down bugs, but the thing is that the problem didn't exist before the beginning of the year. So, something was changed, the problem is that they most likely will not want to roll back the software because it will have other changes in it that they need (at least I hope they have the ability to roll it back).

But here is the ironic part of this, and this isn't the first time this has happened. If they had "done nothing", then when people switched from Direct Connect to Express Web Connect + they would have gotten a flood of duplicate transactions. But it would have been a onetime deal. If this was just say, the SuperUsers, it would have been hardly worth mentioning. But dealing with the average customer I see how they couldn't go with that.

So, one has to understand that they aren't using unique Ids. Let me be clear, the change I'm talking about is on the server, not Quicken. Quicken still uses unique Ids. But it is the server that is doing "transaction compares" ignoring the unique Ids. And I think they don't trust the date to be exact.

Maybe that was even the kind of change they made at the start of the year, to stop trusting the date as being exact to try to match some transactions that were getting down to Quicken and were actually duplicates. But given the old behavior and the new one, I would certainly have picked the old one.

I have done a lot of "conversions" between different systems and one thing most people don't get is that there isn't always a one-to-one match, and then you have to do the best you can.

The unique Ids are useless because you are dealing with two systems that generate them differently. The next step then is to try to match the transactions up between the two systems. Basically, the best way to do that is generate your own unique Id based on what is in each transaction.

And one of the most important would be the date. But what if the two systems don't guarantee to use the exact same date? You just lost a very important separator, especially when you consider the fact that if a person is in the habit of buying the same thing every day, then the only thing different is going to be the date. And note that the same transaction can happen on the same date.

Intuit has always generated the unique Id for Express Web Connect wrong when there are two identical transactions on the same date (they didn't take this into account and generated the same unique Id for both transactions). The other problem in their generation system was that it used a "seed number", and that number changed if you reset the account or disable the online account and then reconnected.

When I think of this problem, I think what I would have done is make the "use new generated unique Id" only a temporary change over process, instead of what is clearly a change of the system for all processing. I say that because Chase/BOA/… changed over long ago, and they were working, so this is a change for all "caching/syncing", which is to say, Express Web Connect +, Quicken Connect, and even Express Web Connect.

QuickUserPSP

When I was working, no matter what organization I was with, "rolling back" was never an option. Even if the new system upgrade had documented defects and the old system was proven better. There were too many resources invested to go back. Too many moving parts - different system interfaces, vender agreements, and mostly the cost would be prohibitive. So, we always had to learn to live with it.

I think they should have left the process alone then if doing nothing causes duplicates. In my opinion duplicates are easier to deal with than missing transactions. But again, there are some vocal Quicken users that can't handle duplicate transactions. It is indeed ironic that in order to appease these users, they created a worse problem.

If the unique transaction IDs are not consistently uniform or used, maybe attempts were made to use a mapping mechanism to match them? Maybe they are ignoring the unique transaction IDs because they are trying to work out a process for pending transactions? Who knows. But again, if you say is true about duplicate transactions, then they should have left it alone.

You are absolutely correct; system interfaces and conversions are complicated because there is rarely a one-to-one connection between them. You try to find the best mapping between them and then try to create a connection. Even then, if anything changes with any of the parties involved, it inevitably breaks the interface. Once that happens, it's almost like starting over again. If each of the parties are allowed to do what they want, it comes to the point where each interface program is custom and there are no templates to follow. It's almost like each time there is a change, you need to create a new program.