Matching downloaded transactions in MD 2010
When MD 2010 thinks a downloaded transaction is a match it doesn't give me a way to override. I tried each of the selections it offered and none of them let me include the new downloaded transaction as a new transaction (it finds the earlier dated transaction and doesn't even show the new transaction date). This, of course, throws my balances off tremendously and now my accounts are out of balance as they are missing transactions.
Thanks.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by James on 10 Dec, 2009 09:03 PM
I'm having the same problem. Transactions download and don't give me anyway to match them to the correct entry. I liked the old way better. Is there a way to turn that back on?
James
2 Posted by Andrew on 10 Dec, 2009 09:59 PM
Same problem here
Developers: please address this issue ASAP as it has made moneydance completely unusable for me
3 Posted by -Kevin N. on 10 Dec, 2009 10:18 PM
File > Preferences... On the Network tab, try lowering the number in the "Only match downloaded transactions when they are at most "X" days apart" setting. I have mine set to 7.
HTH -Kevin N.
4 Posted by Noname on 10 Dec, 2009 10:32 PM
Just tried Kevin's idea and that worked for me! Thanks.
5 Posted by Brian on 10 Dec, 2009 11:07 PM
That doesn't fix the broken operation. MD2010 matches new transactions to already reconciled one. Once a transaction is reconciled, it should be considered closed.
6 Posted by Mike on 11 Dec, 2009 01:13 AM
I am also really bothered by this. Changing the match tolerance to 7 days will help, but I still want to have the ability to override and force a new transaction.
7 Posted by Douglas Kingham on 11 Dec, 2009 09:13 PM
I agree with Mike. We need the ability to override and force a new transaction.
8 Posted by Randy on 11 Dec, 2009 09:34 PM
If MD matched a downloaded transaction to a manually entered one incorrectly, it has a "revert" option on the dropdown next to the "accept" button.
Unfortunately, in build 723 that choice causes the program to lock up, so I am not advocating its use until that is fixed.
But after it is fixed, I believe the intention is to revert the downloaded transaction to the description coming in from the bank (and probably the default category for the account). I hope it also "unmatches" the manual transaction.
As a workaround for now, you can delete the incorrectly matched transaction (you MUST do this before accepting while the blue circle is visible), then make any corrections, and download again, and it would "rematch" based on your corrections.
9 Posted by Brian on 11 Dec, 2009 10:34 PM
again, MD should NEVER match a new transaction it just downloaded to a cleared and/ or reconciled transaction. that is a bug, not just incorrect behavior.
10 Posted by Randy on 12 Dec, 2009 12:03 AM
I agree. Has anyone entered a bug report in Trac?
11 Posted by Jim Weber on 12 Dec, 2009 12:47 AM
Bug - Having problems downloading .qfx and .qif files from banks. Most, but not all, names come in wrong. Cannot figure out the pattern.
12 Posted by sgodfrey2000 on 12 Dec, 2009 04:49 AM
Folks,
due to this I'm going back to 2008.. Can't have Moneydabce mess with my transactions like this. I already opened a file updated by 2010 in 2008 without any issue.
13 Posted by Nick Porter on 12 Dec, 2009 01:13 PM
I have used Moneydance for the last 5 years and have been happy with all the improvements over the years; however I have just upgraded from 2008 to 2010 and have found the download matching process much more long-winded. The application also froze a couple of times requiring a force quit, something that has never happened previously. Reluctantly I have reverted to 2008. I think this upgrade has been poorly conceived.
14 Posted by Randy on 12 Dec, 2009 03:09 PM
Brian, in the post above, you said "MD2010 matches new transactions to already reconciled one".
By matched, do you mean it COMBINED the incoming transaction with the reconciled one, or do you mean it copied the category and description from a reconciled one to the new one? If it COMBINED a newly downloaded transaction with a reconciled one, then you have a net loss of one transaction.
I am not happy with it either, but I haven't seen it lose transactions in this manner. I have seen it make up to 6 guesses of what the category and description should be and put them in the accept dropdown. If you have experienced it losing transactions, please enter a bug in their but Trac system at:
http://moneydance.com/trac/wiki/WikiStart
You have to create a separate id and password from this forum to be able to create tickets and to vote on tickets. Moneydance claims to be a "somewhat democratic" organization, and I think they look at that to figure out what to fix next.
I WANT TO ENCOURAGE EVERYONE TO GO TO THE TRAC SYSTEM AND VOTE ON THE TICKETS THAT HAVE BEEN ENTERED ABOUT THESE ISSUES.
I found 3 tickets related to these issues (2351,2017,2299), and voted for all of them, but you need to know there are others there with twice the votes of these. If we don't vote on the ones of our choice, it may not get the priority we want it to.
15 Posted by Bob on 12 Dec, 2009 08:41 PM
Yeah, remind me to try the beta first. This new way of matching is awful.
16 Posted by sgodfrey2000 on 12 Dec, 2009 08:45 PM
Randy,
Not sure if this is the appropriate place for this question. But how do you cast a vote in trac? I looked everywhere and am missing it. Please help.
17 Posted by Brian on 12 Dec, 2009 09:31 PM
@Randy: it loses transactions. or more accurately, if a transaction has the same amount and description, it will match it even if it is reconciled/cleared. I end up having to go back to my online banking site, figuring out the right date for the transaction, and then entering it manually to keep the register in balance.
18 Posted by Randy on 12 Dec, 2009 09:48 PM
you can vote on a ticket by first opening the ticket in trac, then right below the words "View Tickets" there should be an up arrow and a number then a down arrow. Click on the up arrow. The number indicates the number of votes. for ticket 2351 it was 3 the last time I checked. The ticket with the most votes I saw was 17, but that was a very old ticket that has probably been fixed or superceded by now.
Brian, let us know when you put a ticket in Trac and we will vote for it.
19 Posted by Randy on 12 Dec, 2009 09:52 PM
Over on the mailing list, it was stated that "different file format" that had been talked about between MD2008 and MD2010 wasn't actually implemented until build 725. So, if you are now using 725 and don't have some type of backup of your old MD2008 file, it appears you will run into trouble going back to MD2008.
20 Posted by Noname on 13 Dec, 2009 02:59 AM
Randy, I just voted for 2351 and added some additional information to the description. I guess I was surprised to see it was given a "minor" priority. I'm also a disappointed that none of the support folks have weighed in on this issue yet.
21 Posted by Jeff Y. on 13 Dec, 2009 04:04 AM
I agree with the concerns mentioned.
FYI,
I think the "Download All Accounts" is a great feature that needs some tweaking. I really like how it works in the background to keep things up to date. But, I'm frustrated with how MD2010 matches transactions (i.e. it's not date sensitive, so it makes a bad match on repeat transactions to the same payee for the same dollar amount).
Here's the feature enhancements I'd like:
I'm optimistic that this issue will be resolved soon. MD2010 is a great alternative to the big player(s) that has its
own set of nuances.
22 Posted by jwc on 13 Dec, 2009 07:19 AM
I have been using MD for years now. I have always moved to new versions without question.
I am very glad I read this thread first. I will not be upgrading until this issue is fixed. The program is unusable to like this.
23 Posted by John Selden on 13 Dec, 2009 05:48 PM
I'm also a bit baffled by the new transaction matching in MD2010, but maybe it is because I don't understand it yet.
(1) If MD did not properly identify a match for a downloaded transaction, is there a way to force match it to a manually entered transaction already in the register?
(2) If MD improperly identified a transaction as a match, is there a way to tell it the match is incorrect and have the downloaded transaction either revert to a separate one or be matched to a different transaction?
(3) The way downloaded transactions jump into the register seems really problematic to me. Because MD sometimes renames the payees (which is fine in theory), I can't tell whether the downloaded transaction has been matched to something else or not. I'm ending up with duplicate transactions where a match is accidentally missed.
(4) In MD2008, if I incorrectly entered a transaction, causing the match to a downloaded transaction to fail, I could correct the manual transaction and MD would automatically find the match. In MD2010, it doesn't seem to pick up the match after fixing an entry error. If that's the case, that's a step back.
24 Posted by Brian on 13 Dec, 2009 08:03 PM
Ticket #2366
When downloading transactions from my online banking provider, MD2010
automatically "matches" transactions to entries in the register. MD2010
will match new transactions to already cleared/reconciled transactions
with the same amount/payment information. This is incorrect behavior.
Cleared/Reconciled transactions should never be matched to newly
downloaded transactions.
25 Posted by Randy on 13 Dec, 2009 10:38 PM
I voted for 2366, hopefully we have made enough noise about this that the developer will give it top priority.
Jeff Y., in build 725, the "Accept" button turns into "Accept All" if you select more than one transaction with a blue circle. However, none of the rest of your list is there, the best I can tell.
26 Posted by Randy on 13 Dec, 2009 10:51 PM
John, the short answer to question 1 above is no in build 725. Vote for enhancement 2299 or 2017 (or both),
the short answer to question 2 is no, vote for ticket 2351 and ticket 2366.
27 Posted by John Selden on 13 Dec, 2009 11:57 PM
Thanks Randy and Brian, I voted for ticket numbers 2299, 2017, 2351, and 2366. I'm really disappointed with the new transaction matching algorithm in MD2010 and hope it gets fixed. For now, I'll have to stay with MD2008. Maybe we should start a separate thread telling everyone to vote for those tickets.
28 Posted by jwc on 14 Dec, 2009 02:59 AM
[Edit: what follows is an example of high-horsedness that only gets worse in a subsequent post. I'm leaving both posts up "as is," rather than try and make myself look better by deleting them. Instead, I've gone and apologized in a third post as well.]
I've got to say this voting system is the worst possible way to choose what to fix. Asking people to paricipate in it means expecting a level of technical sophistication that is exactly the kind of thing that drives users away.
Plus it's also sounding suspiciously like a fob off: oh, we'd love to fix this issue, there just aren't enough votes. Right.
No, I will not be using your voting system. I expect you to recognize the seriousness of this and act on it all on your own.
29 Posted by Mike on 14 Dec, 2009 03:55 AM
Frankly, I'm astounded that a problem of this magnitude made it past testing. Either that or we're all missing something. Which I doubt. MD2008 seemed to handle this fine.
If only QIF export were fixed...
Though I agree with jwc, I voted anyway, in the hopes that it might produce the hope-for response.
30 Posted by Mike on 14 Dec, 2009 03:55 AM
Frankly, I'm astounded that a problem of this magnitude made it past testing. Either that or we're all missing something. Which I doubt. MD2008 seemed to handle this fine.
If only QIF export were fixed...
Though I agree with jwc, I voted anyway, in the hopes that it might produce the hope-for response.