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.
Showing page 9 out of 10. View the first page
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
241 Posted by tonyblunt on 17 May, 2010 03:15 AM
There seem to be some people who have problems with the new downloaded data, but just to balance things, since you proably don't hear from happy customers as much, let me say I find it to be very accurate and fast. My downloaded transactions are invariably matched perfectly to my manually entered transactions, with accurate categorization suggested when I have not entered the transaction. The whole process is slick and fast, and I see no need to change and no opportunity for improvement.
I wonder if there are preferences set incorrectly that may be causing unwanted or unexpected results for some people?
242 Posted by -Kevin N. on 17 May, 2010 03:34 AM
I have to say, I'm with Tony on this one.
The matching process lately has been flawless. The only time I end up with duplicate txns. is when I make a mistake entering the data manually. Then it's just a matter of correcting the error and Moneydance offers up a 'Merge' option.
The wildly mismatched txns that others are experiencing has to, as Tony pondered, have something to do with the way they have thier preferenses set.
-Kevin N.
243 Posted by Gray Maddry on 17 May, 2010 04:20 AM
Yes. Some of are having problems. I am glad you aren't. As for the settings, let me check the 2010 doc. Oh I got it 5/12, about 3 months after I started trying to use the new process. On and please tell me what preference I can set so it will not match my previous month's homeowner dues with this month's.
I follow the manual to update a transaction before matching. I press enter and am back in match mode, but I have to select the original trans or I will lose my edit. I could go on but it is late and I am tired and frustrated. Looks like I will haved to do as others have done and go back to 2008 and wait and wait and wait for 2010 to be fixed.
244 Posted by Shawn Willden on 17 May, 2010 12:57 PM
@Gray
As far as I can tell (without decompiling to examine the algorithm), in order to get a false match, two things have to be true about the earlier transaction:
The transaction must not have already been matched. If it has a little "i" on it in the right side of the description field, it has already been matched against a downloaded transaction and as far as I can see MD will NOT offer to merge any new transactions with an already-downloaded one.
The transaction must either be inside your "Payment Date Restriction" window, or else you must have that feature disabled (File->Preferences->Network->Observe Online Payment Date Restriction).
My only problem with MD's transaction download is that sometimes I get duplicates. I enter a transaction manually, download it and merge it, but then when I download again the next day, it downloads again. It only happens on my Discover card, so I suspect it's because Discover does something weird, like putting a different transaction ID on it or something. The best solution I've found so far is to delete the original txn and use the newly-downloaded one. That's a pain if it's a split, but otherwise MD will just keep downloading it every day.
245 Posted by Shawn Willden on 17 May, 2010 01:01 PM
@Gray
Oh, one more idea: Is MD offering to MERGE this month's HOA dues with last month's or is it offering to CATEGORIZE this month's dues the same as last month's?
I find the way categorize works a little annoying sometimes because it pulls ALL of the other fields, and on monthly bills I sometimes want to put the month in the description field. In those cases, I just manually set the category and description and then use "ACCEPT" rather than "CATEGORIZE".
246 Posted by -Kevin N. on 17 May, 2010 01:03 PM
Hi Greg Maddry,
On the bottom of the Network tab in Preferences try reducing the number of days apart of matched txns.
Clear (green check mark) last months txns. The way I understand it is that MD won't try to match cleared txns.
HTH -Kevin N
247 Posted by Randy on 17 May, 2010 01:06 PM
Gray, in a previous post you say "please tell me what preference I can set so it will not match my previous month's homeowner dues with this month's."
I use memorized transactions for things like that, one reason is so I can project my future cash flow, the other is so I can avoid the situation you describe.
If I set the memorized transaction to record only a day or two before the date of the transaction, their aren't two months of transactions in the register for the matching program to use, since it only uses the register, not memorized transactions. When it finds (and merges with) the correct one, I set it to cleared, so it won't use that one again.
I also download transactions often (more than once a week), so that I don't get too far behind. I don't wait until I see a paper statement to mark them cleared, that occurs right after a match. Reconcile (to me at least) no longer has anything to do with a paper statement, my definition is that the cleared balance and the ledger balance in MD are the same. I reconcile almost every time I download.
I think a lot of us are waiting to see what Sean's next move is concerning accepting and reconciling transactions, but I have found a way to manage that situation.
248 Posted by patrick on 17 May, 2010 02:37 PM
Ben, re your May 13 request, I'll certainly do that.
I've downloaded several more transactions since that one hiccup and all have merged or been categorized perfectly. Now if you could only get your guys to improve the method for allowing manual updating of security prices per my suggestion in the other thread, I'd not only throw away Quicken but get all my friends to convert to Moneydance!
249 Posted by Ben Spencer on 17 May, 2010 03:26 PM
Gray,
With regard to preventing Moneydance from matching this months payment with last months in the register select File->Preferences->Network. You will see an option called "Only match downloaded transactions when they are at most [N] days apart]" change the N to less the 28 and you will not get a match with last month.
Ben Spencer
250 Posted by Noname on 17 May, 2010 03:31 PM
Ben, can you shed any light on my query in post 226 of this thread regarding what shows in the register as opposed to what MD is actually suggesting to confirm?
Thanks.
251 Posted by Ben Spencer on 17 May, 2010 03:58 PM
Hi jbnyt
When Moneydance creates the list of transactions in the accept list the one that it thinks is the best match is highlighted in light grey. All others are in dark grey. If you do not manually select one of the options in the list the one in light grey will be applied when you click the accept button. see the first screenshot-1. In this screenshot moneydance has found a potential merge for the unconfirmed transaction (dated 12/5/2009) with the existing transaction (dated 12/7/2009). This merge is Moneydance's best match and so it is highlighted in light grey. Clicking the accept button merges the two transactions. With a merge the description is taken from the transaction that was already in the register.
If you manually select a transaction in the accept list the selection is highlighted in blue. See screenshot-2. In this screenshot I manually selected the categorize option instead. The blue selection will be applied when the accept button is clicked.
In summary: The light grey transaction will be applied when you click the accept button if you have not made a manual selection. If you make a manual selection the blue selection will be applied when you click the accept button. Perhaps it would be simpler if the one being applied was always blue. I'll check in with Sean about changing this to be more consistent.
Ben
252 Posted by Noname on 17 May, 2010 04:12 PM
Yes, I understand the matching issue (and would agree it would be helpful to have a more distinct color define the suggested match) but my question here is that in the register the description displayed is NOT the suggested match. In your example the register says ATM under the category and shows a message in the memo field. The suggested match wants to use the category "bank charge" and merge it with another transaction which has no memo. I was assuming that the way the transaction was displayed in the top of the register (i.e. with the blue dot) was the suggested MD match. But this doesn't seem to be the case.
Therefore, it seems that I am required to review every transaction at the bottom of the register (many times having to scroll through the choices to find the right match) when it is already displayed correctly in the register. I guess what I am saying is that I would like the description in the register to reflect the suggested match MD is offering rather than my having to go search for it every time.
Hope I explained this clearly. If not, let me know and I'll take another stab at it.
Edit: Actually, what I really would like is to be able to Accept the transaction as displayed in the register (at the top with blue dot) as is (even if it is not the suggested match from MD). For some reason I find that the transaction is just as I want it when it is downloaded but MD occasionally wants to change it. (Your screen shot is a perfect example of this. You may want to accept what is in the register but if you do it will be changed to MD's suggested match instead.) I want to be able to look at the register entry and just Accept it if it is what I want. If I do that now (without scrolling at bottom to confirm that this is the MD suggested match) it can get changed and I need to start over. (I probably really confused you with this addendum... sorry!)
253 Posted by avp2 on 17 May, 2010 04:42 PM
Saying what I think jbnt means in another way, it may be an improvement if clicking "accept" were to change only the date and amount (if either is different than what is in the suggested register match) rather than what category or memo or description comes in the downloaded transaction. If someone has already entered a transaction in their register, it is probably much more likely to be correct in this regard than is the whatever the bank puts in.
In fact, sometimes even the user entered date is more correct than what might be downloaded, because of a user is usually more interested in when they make a payment than when the payment "clears".
How about adding a "delete" button next to the "accept" button. It would be more convenient than having to accept then delete to get rid of bum downloaded transactions.
254 Posted by Ben Spencer on 17 May, 2010 05:47 PM
Hi jbnyt
You are correct the entry in the register with the blue dot is not the suggested match. It is the currently selected unconfirmed transaction that you are about to accept. Clicking the accept button will potentially change the fields blue dot entry in the register.
If you accept it with a MERGE option, the unconfirmed transaction (aka the one with the blue dot) will be merged with the matched transaction. The date, description, memo and category in the resulting merge will be from the transaction that you merged the unconfirmed transaction with. i.e. the one that was already in the register. Modifications made to an unconfirmed transaction that is then merged with an existing transaction will be lost. The assumption is that the transaction you had already entered into the register manually before the download has the date, description, memo and category that you want.
If you accept it with a CATEGORIZE option, the category of the unconfirmed transaction with change to the category of the transaction selected in the accept list. The description will also change to be exactly the same as the description as the transaction that was a CATEGORIZE match. The other fields do not change.
However if you accept it with the ORIGINAL option the fields in the unconfirmed transaction will not be modified by the accept function. This option allows you to change the fields in the unconfirmed transaction as shown in screenshot-3 and then accept the transaction keeping the changes you just made. (see screenshot 4).
Ben
255 Posted by Roger Kellett on 17 May, 2010 06:41 PM
Am I missing something? It seems that once I have accepted the transaction
one way or another it should also show as ³cleared². Can¹t seem to get it
to do that yet
256 Posted by Ben Spencer on 17 May, 2010 06:48 PM
Accepting an unconfirmed transaction is not the same thing as clearing it. Clearing is related to the reconciliation process. In moneydance you have to mark a transaction as cleared either by isng the reconciliation tool from Account->Reconcile. Or manually mark the transactions as cleared by right clicking on it and selecting mark as cleared.
Ben
257 Posted by -Kevin N. on 17 May, 2010 06:58 PM
Roger,
I agree, once the user has examined a txn, matched it, and 'Accepted' it, the user should have the option of having that txn automatically marked as cleared. Possibly thru 'Preferences'
I created Trac ticket 2446 for this enhancement. As of 5/17/2010 it has 16 up votes.
http://moneydance.com/trac/ticket/2446
-Kevin N.
258 Posted by Noname on 17 May, 2010 08:35 PM
Ben, going back to my original point, I just want to suggest that I think it would be more efficient to have the option to Accept the transaction as displayed with the blue dot in the register without having to go down to the bottom of the screen to search out what the MD suggested match is. By so doing I believe the work flow would be more efficient and less prone to error. It has been my experience that MD has been able to display the correct version of the transaction that I want to use, but doesn't always suggest that as the first match.
259 Posted by Ben Spencer on 17 May, 2010 08:46 PM
jbnyt
Sean is working on a new design for the transaction matching merging interface. from the sketches he sent me it looks closer to what you are describing.
Ben
260 Posted by Ben Spencer on 17 May, 2010 08:48 PM
Hi kevin
I have raised the priority to major on ticket http://moneydance.com/trac/ticket/2446
I have also brought the issue up with the developers. Hopefully we will get it added in the near future.
Ben
261 Posted by Noname on 17 May, 2010 08:50 PM
Great Ben, thanks!
262 Posted by -Kevin N. on 17 May, 2010 10:27 PM
Thanks Ben
Anyone who has dealt with Intuit or Microsoft certainly has to be impressed with the responsiveness of the Moneydance team.
The improvements and enhancements made to MD in the last few months alone is unprecedented.
Thanks again,
Kevin N.
263 Posted by Jim Weber on 18 May, 2010 12:09 AM
On May 17, 2010, at 6:29 PM, kmnugent wrote:
> // Add your reply above here
> ==================================================
> From: kmnugent
> Subject: Matching downloaded transactions in MD 2010
>
> Thanks Ben
> Anyone who has dealt with Intuit or Microsoft certainly has to be impressed with the responsiveness of the Moneydance team.
> The improvements and enhancements made to MD in the last few months alone is unprecedented.
> Thanks again,
> Kevin N.
>
> View this Discussion online: http://help.infinitekind.com/discussions/problems/497-matching-downloaded-transactions-in-md-2010
> --
> Reply with #ignore to stop receiving notifications for this discussion.
264 Posted by Gray Maddry on 18 May, 2010 12:39 AM
Merge. Often categorize matches even worse than merge.
265 Posted by Gray Maddry on 18 May, 2010 12:42 AM
I found that and I had it set to 60 days. Choices are limited. I can't set
28 days. I have to choose 30 or 21. 21 means told the end of the month when
I am matching a credit card QIF, I will miss merges that should happen.
266 Posted by Gray Maddry on 18 May, 2010 12:49 AM
This was a memorized transaction. The download from the bank wasn't matching
the memorized entry. Look I have been using MD since Oct 2004. Before that I
used Quicken and Money. I started about 1990 with MYM in a DOS box. I have
never had this much trouble with a finance program.
It doesn't do me any good to download from my major credit card as I have to
use a QIF file and I down load all transactions from the previous close.
267 Posted by Gray Maddry on 18 May, 2010 12:51 AM
Ben,
As I previously replied. A choice between 21 and 30 helps some but doesn't
solve the problem. What I don't under stand is why I don't remember having
this problem in MD 2008.
268 Posted by Jerry Clement on 19 May, 2010 05:23 AM
--- On Tue, 5/18/10, Wren Hunter <[email blocked]> wrote:
269 Posted by Gray Maddry on 22 May, 2010 04:48 PM
I just went back to MD 2008. I had forgotten how easy the matches were in the old version. If a transaction was matched it was highlighted in the registry and if no match you could edit before accepting. I will try 2010 when the new download process is implemented, but until then I will be happy with 2008
270 Posted by patrick on 02 Jun, 2010 03:57 PM
Ben:
You asked me to send details the next time I had a problem with merging/categorizing. This time MD refused to categorize a downloaded transaction even though it had chosen the correct similar transaction to use for categorizing. When I accepted the Categorize suggestion it did not categorize the new transaction. I hope the attached files make this clear.
Patrick